回答问题
Go 的链接器通过一种可达性分析算法执行死代码消除，该算法从程序的入口点：main.main 和所有包 init 函数开始构建依赖图。它遍历调用图，标记每个静态引用的函数和全局变量，然后在写入最终二进制文件之前丢弃未标记的符号。这个过程是保守的；如果一个函数的地址被获取并存储在一个接口中，通过 reflect.Value.Call 传递，或通过汇编代码或 //go:linkname 指令引用，则链接器必须保留它，因为它无法证明该函数在运行时不会被调用。此外，CGO 导出的函数和为基于反射的解码注册的方法（例如 json.Unmarshal 到一个动态调度到具体类型的 interface{}）可能强制保留本来不可达的代码路径。该优化默认启用并跨包操作，这意味着如果应用程序的可达代码没有引用，则可以消除第三方依赖中的未使用代码。
生活中的情况
一个平台团队注意到，在引入支持多个遥测后端（Jaeger，Zipkin，Prometheus）的全面可观察性库后，他们的 CLI 工具膨胀到了 47MB，尽管该服务仅导出了 Prometheus 指标。问题源于该库的单体架构，其中导入包会初始化所有后端的全局注册，拉入如 Kafka 客户端和 gRPC 库（用于 Zipkin）等昂贵的依赖，而它们实际上是未被使用的。
考虑的第一个解决方案是手动维护一个移除未使用后端的库的分支。虽然这可以保证消除死代码，但它会造成不可接受的维护负担，要求手动安全补丁和解决与上游的合并冲突。
测试的第二种方法是对二进制文件应用 UPX 压缩，将大小减少到 13MB。然而，这引入了显著的启动延迟，因为运行时解压缩并在企业防病毒扫描器中触发了误报，使其不适合生产环境。
第三种选择是使用 ldflags="-s -w" 来剥离调试信息和符号表。这仅减少了 3MB，而没有解决实际的机器代码膨胀，因为未使用的后端实现仍然保留在二进制文件中。
团队选择重构代码以避免有问题的导入。他们在核心应用中定义了一个最小的度量接口，然后将具体的 Prometheus 实现移到一个仅由 main 导入的子包中。这确保未使用的 Zipkin 和 Jaeger 代码路径没有被任何可从 main.main 或 init 函数可达的符号引用。他们还进行了审计，以检查任何可能意外保留后端构造函数的 reflect.Type 方法查找。这一架构变化使得 Go 的链接器能够进行激进的树摇动。
结果是减小到 9MB，没有外部压缩，CI 构件上传更快，容器启动时间减少，同时保留了在不打补丁的情况下升级可观察性库的能力。
候选人常常错过的内容
为什么链接器保留仅在编译时常量 false 条件（如 if false）保护的代码块内部引用的函数？
Go 的链接器在符号依赖级别操作，而不是在函数内的基本块级别。虽然编译器的 SSA（静态单一赋值）优化可能消除像 if false 这样的死分支，但如果包含该分支的函数本身是可达的，任何它直接调用的函数（而不是通过条件逻辑）在目标文件中创建一个引用边。因此，如果一个包被导入，它的 init 函数无条件被视为可达性图的根。因此，由 init 函数调用的任何函数都被保留，不管该包的公共 API 是否在应用程序中使用。开发人员常常认为未使用的导入是无害的，但如果这些导入进行了繁重的初始化，它们会显著增加二进制文件的大小。
通过 &fn 获取函数地址如何影响死代码消除，与直接调用相比，为什么这可能导致回调注册中的意外二进制大小增加？
当一个函数的地址在包初始化时被获取并存储在全局变量或数据结构中（例如，var defaultHandler = &unusedFunction），链接器必须将 unusedFunction 标记为可达，因为该赋值创建了一个静态数据引用，链接器无法将其与动态使用区分开来。与可以在调用函数自身变为不可达时被消除的直接函数调用不同，获取地址会在二进制文件的数据段中创建一个持久的引用。这通常会让在使用包级 map[string]func() 变量实现插件系统或 HTTP 处理程序注册的开发人员感到惊讶，因为添加到映射中的每个函数即使映射从未被访问也会在死代码消除中存活。
//go:linkname 指令与标准导出函数在符号保留上的影响有何区别，为什么链接到内部标准库函数可能会阻止整个包的消除？
//go:linkname 指令允许包 A 使用链接器的符号名称引用包 B 中的符号，而不是使用语言的导出机制。当某个符号是来自构建中任何包的 //go:linkname 指令的目标时，链接器将其视为可达性图的根，类似于 main.main。这是因为该指令经常被 runtime 和标准库用来跨包边界访问未导出函数（例如 runtime 调用 syscall 内部）。与普通导出函数不同，普通导出函数只有在存在从 main 或 init 的传递调用路径时才会被保留，linkname 目标即使在应用程序从未导入包含该指令的包的情况下也会存活。因此，链接到内部标准库符号的用户代码可能无意中迫使链接器保留 runtime 或 syscall 包的大部分本来会被消除的内容。