缩小可执行文件的大小
约 1402 字大约 5 分钟
2025-03-03
Go 的二进制一向有个很现实的特点：
好部署，但不一定小。
在服务数量不多的时候，这件事感受并不明显。
但当系统进入多服务部署阶段，二进制体积会直接影响：
- 镜像体积
- 分发速度
- 启动成本
- 内存占用
尤其是在微服务场景里，一个服务多几十兆，看起来不大，乘上服务数量以后就会变得很具体。
联犀当前对二进制优化的思路很务实：
不追求极限压榨，而是优先做收益明确、风险可控的优化。
先明确一个原则
优化二进制大小，不只是编译参数问题。
它通常分成三层：
- 去掉不必要的调试信息
- 裁掉不需要的依赖分支
- 从代码组织上避免把大包整体带进来
联犀当前主要也是按这个顺序做。
第一层：发布构建先裁调试信息
对发布二进制来说，最稳定、最直接的一步仍然是：
go build -ldflags "-s -w"它的含义很简单：
-s：去掉符号信息-w：去掉 DWARF 调试信息
这通常不是“微优化”，而是第一步就能拿到比较明显收益的动作。
当然，这一步也有前提：
- 它更适合发布构建
- 如果你当前正在强依赖本地二进制调试，就不要把所有调试信息无脑去掉
所以正确姿势不是“所有构建一律这样”，而是把它当作发布构建默认项。
第二层：不用的依赖就不要带进来
很多 Go 项目的体积问题，并不是业务代码本身太大，而是某些框架为了兼容更多场景，把大量依赖一起带了进来。
在联犀当前的场景里，一个比较典型的点就是 Kubernetes 相关依赖。
如果当前部署形态并不依赖这部分能力，那么继续把整套依赖编进来，收益很低，代价却很真实。
所以当前可以使用：
go build -ldflags "-s -w" -tags no_k8s这个思路背后的重点不是某个具体标签，而是：
如果某类能力当前根本不会在部署环境里使用，就应该尽量避免让它成为所有服务的默认负担。
第三层：按需拆包比调参数更重要
如果只靠编译参数，优化空间很快就会到头。
真正更长期的做法，是从包边界上控制依赖传播。
Go 的一个特点是：
只要引入了某个包，这个包里的相关实现就有可能整体进入最终二进制。
所以如果一个公共包做得过于庞大、过于杂糅，就会出现很典型的问题：
- 某个服务只想要其中一个能力
- 结果整包相关逻辑都被带进来了
联犀当前在公共层比较重视按职责拆包，例如把不同客户端、不同基础能力拆成更独立的包，而不是做成一个“什么都能干”的超级工具包。
这类优化表面上不如编译参数直接，但它通常更健康。
因为它会顺便改善：
- 模块边界
- 依赖方向
- 可维护性
什么时候不该为了小而小
二进制优化很容易走向另一个极端：
为了再省几 MB，把代码结构搞得更复杂。
这通常不值得。
下面几类做法就不太推荐：
1. 为了体积强行拆散本来就该放一起的能力
如果拆包导致理解成本显著上升，长期收益往往不划算。
2. 调试环境也一律做极限裁剪
发布环境和开发调试环境的目标不同。
不能因为发布要瘦身，就让所有本地排障都变得更困难。
3. 忽略部署模式差异
并不是所有服务都面临同样的体积压力。
有些服务更在意冷启动，有些服务更在意依赖完整性，有些服务只是内部工具。
所以体积优化也应该按场景来，而不是一刀切。
联犀当前的实践结论
回到工程现实，联犀当前对二进制优化的口径其实很清楚：
- 发布构建先默认裁掉调试信息。
- 对不用的框架依赖，尽量通过编译标签或条件引入裁掉。
- 公共能力从包边界上持续做按需拆分。
这三步里，真正最值得长期坚持的其实是第三步。
因为前两步更多是构建期收益，第三步则会反过来促进整个系统的依赖结构变得更健康。
总结
缩小可执行文件大小这件事，看起来像部署细节，实际上和架构设计关系很深。
如果系统本身依赖边界混乱、公共包过大，那么编译参数能做的只是表面优化。
真正稳妥的做法，仍然是把二进制优化当成架构治理的一部分：
- 构建参数只带需要的东西
- 框架能力按部署模式裁剪
- 公共代码按职责拆分
当这些事情一起做时，二进制变小只是结果，依赖结构更清晰才是更有价值的收益。
更新日志
2026/5/18 10:48
查看所有更新日志
43ef3-docs(blog): 新增后端与架构系列技术博客 18 篇，更新原有 7 篇于d4fa0-doc: 更换皮肤到最新版于f4017-doc: 完善文档于90f49-feat: 完善项目`于8794f-feat: 完善项目`于
