Go构建最终二进制时是否移除未引用包？为何仍能检测到？

针对你遇到的问题，核心原因可以从Go的模块依赖追踪、链接器死代码消除规则两个层面来解释：

1. go version -m显示的是模块依赖，不是二进制实际包含的代码 #

go version -m <二进制文件>输出的是项目go.mod中声明的模块依赖关系，只要你的sub包导入了github.com/containerd/containerd，不管该包的代码有没有被实际用到，这个模块依赖都会被记录并显示。这是模块层面的依赖追踪，和二进制里是否包含对应代码没有直接关联。

2. 链接器的死代码消除并非绝对“激进” #

Go的链接器确实会尝试移除未被引用的代码，但存在以下几种情况会导致看似未使用的代码被保留：

• 包初始化代码：只要你导入了sub包，sub包及其依赖的containerd包中的init()函数都会被执行。这些初始化代码（以及它们依赖的变量、函数）会被强制包含进二进制，哪怕你只用到了sub包的常量。
• 无法判定的间接引用：如果sub包的Func函数虽然没被主包调用，但sub包内部有其他逻辑（比如init函数、其他被引用的函数）间接引用了它，或者Func中用到的containerd类型/函数涉及接口实现、反射等场景，链接器可能无法判定这些代码为“死代码”，从而保留它们。
• 跨包代码的消除限制：链接器在处理跨包依赖时，有时会因为包级别的符号引用规则，保留一些看似未使用的代码片段，尤其是当依赖包的结构比较复杂时（比如containerd这类大型项目）。

3. 调用Func后二进制仅略有增大的原因 #

当你在主包调用Func时，只是增加了对该函数的直接引用，但Func本身已经因为上述原因被包含在二进制中了，所以二进制大小只会略有增加（比如增加函数调用的跳转指令等极小的代码量）。

验证建议 #

• 用go tool nm <二进制文件>查看二进制中的符号，筛选containerd相关的符号，确认哪些代码真的被包含。
• 尝试用go build -gcflags="-l -s"构建，开启更激进的优化（-l关闭内联，-s去掉符号表），看是否能减少二进制中未使用代码的占比。

内容的提问来源于stack exchange，提问作者deitch