减小go语言编译出的二进制文件体积的核心方法是先通过编译选项移除调试信息，再使用upx等工具进行压缩；具体可通过go build -ldflags="-s -w -trimpath"去除符号表、dwarf信息和路径信息，显著减小文件大小，随后使用upx对二进制文件进行二次压缩，可进一步大幅降低体积，尽管会带来杀毒软件误报、启动微小延迟、调试困难和签名失效等注意事项，但对部署在服务器或容器中的应用而言，整体收益通常大于代价，最终结合多阶段docker构建使用scratch或alpine镜像，可实现极致的发布包精简。
Go语言编译出的二进制文件，如果想有效减小其体积，核心策略就是两步：一是移除不必要的调试信息，二是利用外部工具进行二次压缩。这两种方法结合起来，效果往往非常显著，能让原本可能几兆甚至几十兆的文件瘦身不少。
解决方案
要减小Go语言编译出的二进制文件大小，最直接且有效的方法是结合使用Go自身的编译选项来移除调试信息，然后使用像UPX这样的外部工具进行二次压缩。
1. 移除调试信息： Go编译器在默认情况下会将大量的调试信息（如符号表、DWARF调试信息等）嵌入到编译后的二进制文件中，这对于调试来说非常有用，但对于最终发布的应用来说，这些信息通常是冗余的。通过在
go build命令中添加特定的
ldflags，我们可以指示链接器移除这些信息。
-s
: 移除符号表，这会阻止在运行时进行堆栈跟踪时显示函数名和行号。-w
: 移除DWARF调试信息，这使得调试器无法关联源代码行。
示例命令：
立即学习“go语言免费学习笔记（深入）”；
go build -ldflags="-s -w" -o your_application_name
执行这条命令后，你会发现生成的文件体积已经有了明显的下降。
2. 使用UPX压缩： UPX（Ultimate Packer for eXecutables）是一个开源的、可移植的、可扩展的、高性能的通用可执行文件压缩器。它通过将可执行文件进行压缩，并在运行时进行解压，从而减小了文件在磁盘上的占用空间。对于Go这种静态链接的二进制文件，UPX的压缩效果尤为显著。
首先，你需要安装UPX。在macOS或Linux上通常可以通过包管理器安装：
# macOS brew install upx # Debian/Ubuntu sudo apt-get install upx-ucl # Fedora sudo dnf install upx
Windows用户可以从UPX官方网站下载其可执行文件。
安装完成后，对你刚刚编译出来的二进制文件进行压缩：
upx your_application_name
UPX会显示压缩前后的文件大小对比，你会发现文件体积再次大幅度减小。
为什么Golang编译出的二进制文件通常比较大？
说实话，刚接触Go的时候，我也被它那动辄好几兆的二进制文件吓了一跳，毕竟很多时候我写的只是一个简单的HTTP服务或者命令行工具。这背后其实有几个核心原因，理解了这些，你就会明白这是Go设计哲学的一部分，而非简单的“效率低下”。
一个主要的原因是静态链接。Go的设计目标之一就是“部署简单”，所以它默认会将所有运行时依赖（包括垃圾回收器、调度器、标准库的大部分内容）都打包进最终的二进制文件里。这意味着你的Go程序在运行时几乎不需要依赖宿主系统安装的任何外部库（除了少数CGO场景），拿来就能跑。这和C/C++程序需要依赖各种动态链接库（如glibc）形成鲜明对比。这种“自给自足”的特性固然带来了部署上的极大便利，但也无可避免地增加了文件体积。
其次，Go的运行时和标准库本身并不小巧。虽然Go的语言特性看起来简洁，但它内建了并发模型（goroutines和channels）、高效的垃圾回收机制、以及一个功能丰富且高度优化的标准库。这些组件的实现代码，自然也需要占用一定的空间。
还有就是调试信息。就像前面提到的，默认情况下，Go编译器会把大量的符号表和调试信息嵌入到二进制文件中，这对于开发者在开发和调试阶段定位问题至关重要，但对于生产环境的发布包来说，这些就是纯粹的冗余了。我个人觉得，如果不是为了深度分析或者崩溃追踪，这些信息确实可以大胆地移除。
除了upx和strip，还有哪些方法可以优化Go二进制大小？
除了最常用的
strip和
UPX，其实还有一些方法可以从不同层面来优化Go二进制文件的大小，虽然它们可能不如前两者立竿见影，但在某些场景下也能起到作用，或者说是更“根本”的优化。
1. 减少不必要的依赖和代码： 这是最基础也最容易被忽视的一点。你的项目是否引入了太多不必要的第三方库？有些库可能只用到了其中一两个函数，却引入了整个库的依赖。Go的编译器会尽可能地移除未被引用的代码，但如果一个包被导入了，即使只使用了一小部分，也可能将整个包的依赖链带入。定期使用
go mod tidy来清理
go.mod文件，确保没有未使用的模块依赖。
2. 使用-trimpath
编译选项：
这个选项在Go 1.13之后变得非常有用。它会从二进制文件中移除所有文件路径信息，使得构建结果更具确定性（即在不同机器上相同代码编译出的二进制文件哈希值可能相同），同时也能稍微减小二进制体积。
go build -ldflags="-s -w -trimpath" -o your_application_name
虽然减小的幅度可能不如
-s -w那么大，但作为一种最佳实践，我个人习惯把它加到我的构建脚本里。
3. 避免CGO： 如果你的Go程序使用了CGO（即调用C代码），那么编译出的二进制文件通常会依赖宿主系统的C库（如
glibc）。这不仅可能导致二进制文件体积增大（因为它需要包含额外的CGO运行时代码），更重要的是，它会引入外部依赖，使得“一次编译，到处运行”的特性打了折扣。如果可能，尽量使用纯Go的实现来替代CGO。当然，我知道有些场景下CGO是不可避免的，比如需要与特定硬件交互或者使用现有C库。
4. 针对Docker容器优化： 如果你将Go应用部署在Docker容器中，那么使用极简的基础镜像（如
scratch或
alpine）可以显著减小最终的镜像大小。虽然这没有直接减小Go二进制文件本身的体积，但从部署的角度看，容器镜像的体积才是你真正关心的。
-
scratch
： 最极致的选择，完全空白的镜像，只包含你的Go二进制文件。 -
alpine
： 基于Alpine Linux，体积非常小，但包含了基本的Linux环境，对于需要shell或者其他工具的场景非常方便。
# 使用多阶段构建 FROM golang:1.22 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED=0 go build -ldflags="-s -w -trimpath" -o your_application_name . FROM scratch COPY --from=builder /app/your_application_name /your_application_name ENTRYPOINT ["/your_application_name"]
通过这种方式，即使你的Go二进制文件本身有几十兆，最终的Docker镜像可能也只有几十兆，而不是几百兆。
使用upx压缩二进制文件时需要注意什么？
UPX确实是减小Go二进制文件大小的一把利器，但它并非没有缺点，或者说，在使用时有一些“坑”需要注意。我自己在实践中就遇到过一些，所以这里想分享一下：
1. 杀毒软件的误报： 这是UPX最常见也最令人头疼的问题。由于UPX的工作原理是修改可执行文件的结构（在文件头添加解压代码，将原始程序数据压缩），这种行为与某些恶意软件的打包方式有相似之处。因此，很多杀毒软件会将UPX压缩过的文件误报为病毒或可疑程序。这对于发布给普通用户使用的桌面应用来说，是一个非常大的障碍。如果你是做后端服务或者内部工具，影响可能小一些，但依然需要有心理准备。
2. 性能开销： UPX压缩的文件在运行时需要先进行解压，然后才能执行。虽然这个解压过程通常非常快，对大多数应用程序来说几乎可以忽略不计，但对于启动时间极其敏感的应用，或者在资源受限的环境中，这可能会引入微小的启动延迟。在我的经验中，对于常规的Web服务或CLI工具，这种开销几乎可以忽略不计。
3. 调试困难： UPX压缩过的二进制文件会变得难以调试。因为文件内容被修改了，传统的调试器可能无法正确地加载符号信息或者设置断点。因此，通常建议只对最终发布的版本进行UPX压缩，开发和测试阶段还是使用未压缩的版本。
4. 数字签名失效： 如果你的Go二进制文件需要进行数字签名（例如，在Windows上为了避免SmartScreen警告），那么在签名之后再使用UPX压缩，会使原有的数字签名失效。你需要在UPX压缩之后，再重新对文件进行签名。这增加了一个额外的步骤，并且可能需要额外的签名成本。
5. UPX版本兼容性： 确保你使用的UPX版本与你的操作系统和CPU架构兼容。UPX是一个活跃的项目，不断有更新，但有时旧版本可能无法正确处理某些新的Go二进制文件格式，或者在特定的操作系统版本上出现问题。建议使用最新稳定版的UPX。
总的来说，UPX是一个强大的工具，但它更适合那些对文件大小有严格要求，且能够接受上述权衡的场景。对于大多数内部服务或命令行工具，其带来的体积优势通常会盖过这些潜在的问题。
