Go项目构建是否会打包lib模块中未使用的外部依赖？

未被使用的外部依赖是否会被打包进项目二进制文件？ #

这个结果完全取决于你使用的构建工具、语言特性以及依赖的引入方式，以下是几种常见技术栈的情况：

• Java/Kotlin 生态（Gradle/Maven）：
  • 默认用shadowJar（Gradle）或maven-shade-plugin打包时，Lib声明的所有依赖都会被打包，不管项目有没有用到。
  • 但如果开启了R8/ProGuard混淆压缩，或是用Java模块化（JPMS）配置了精确的模块依赖，未被func B用到的外部依赖类会被自动剔除。
  • 要是Lib本身按功能拆分了子模块（比如lib-b单独依赖ext-dependency B，lib-a依赖ext-dependency A），项目只引入lib-b的话，ext-dependency A根本不会被拉取，自然不会出现在打包产物里。
• 前端生态（Webpack/Vite）：
  • 若使用ES模块（import/export）格式的Lib，构建工具的Tree Shaking会自动剔除未被使用的代码和依赖——前提是Lib没有被副作用代码干扰。
  • 要是Lib是CommonJS模块（require）格式，Tree Shaking基本无效，未使用的依赖很大概率会被打包进去。
• Go 语言：
  • go build默认会做死代码消除，只有被func B直接或间接引用的依赖才会被打包进二进制，未使用的外部依赖会被完全忽略。
• Rust 语言：
  • Cargo的cargo build默认开启dead_code消除，未被func B用到的外部依赖代码不会被编译进最终二进制。

如何测试打包行为？ #

可以通过以下几种方式验证：

• 直接查看打包产物内容：
  • Java：用jar tf your-project.jar列出Jar内所有文件，检查是否存在ext-dependency A的类文件；或者用JD-GUI打开Jar包，搜索依赖类名。
  • 前端：用webpack-bundle-analyzer或rollup-plugin-visualizer生成打包产物的可视化分析图，查看是否包含未使用的依赖模块；也可以直接查看打包后的JS文件，搜索依赖库名称。
  • Go：用go tool nm your-project-bin | grep "ext-dependency-symbol"，无输出则说明未被打包；或者用upx压缩后对比体积变化，间接验证。
  • Rust：用cargo-bloat分析二进制体积占比，查看是否包含未使用的依赖代码；或者用objdump -t your-project-bin | grep "dependency-func"检查符号是否存在。
• 编写最小测试项目：
  • 创建仅依赖Lib中func B的空项目，构建后对比产物体积（和引入Lib全部功能时的体积对比），如果体积明显更小，说明未使用的依赖被剔除了。
  • 运行测试项目，通过日志或调试工具确认未加载未使用的依赖（比如Java中用ClassLoader.getResource("ext-dependency-A-class.class")检查是否存在）。
• 查看构建工具日志：
  • 开启构建工具的详细日志，比如Gradle的--info、Webpack的--stats detailed，日志会列出被打包的依赖模块，检查是否包含未使用的ext-dependency A。

内容的提问来源于stack exchange，提问作者Luis.at.code