如何优化Go语言编写的AWS Lambda部署包（Zip包）大小？

我太懂这种从轻量的.NET老Lambda转到Go后，看到部署包体积从几百KB暴涨到9MB的错愕感了！先给你明确两个关键点：首先，部署包大小确实会影响Lambda的冷启动时间——包越大，Lambda服务下载和解压它的时间就越长，尤其是第一次触发或者长时间闲置后的启动；其次，Go的Lambda包优化空间很大，照着下面的方法来，轻松把体积压到接近你原来.NET包的水平！

给你分享几个亲测有效的优化技巧：

• 编译时加瘦身参数：Go编译默认会带符号表和调试信息，这些在生产环境完全没用。编译时加上-ldflags="-s -w"，-s能去掉符号表，-w会删掉DWARF调试信息，直接就能砍掉30%-40%的体积。另外一定要指定Lambda的目标环境架构，避免编译出冗余内容，完整的编译命令应该是这样的：

  GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o main main.go
  

  （如果你的Lambda用的是Graviton架构，把GOARCH=amd64换成GOARCH=arm64就行）

• 用UPX压缩可执行文件：UPX是个专门压缩可执行文件的工具，无损压缩，能把Go的二进制文件压得更小。比如用最高压缩比模式：

  upx --best main
  

  这里要提一句：压缩后的文件第一次运行会有极短的解压开销，但这点时间和包体积减小带来的冷启动提升比起来，几乎可以忽略，绝大多数场景下都是赚的。

• 只打包必要文件：别犯把整个项目目录（包括go.mod、源代码）都zip的低级错误！你只需要把编译好的main二进制文件单独打包成zip就行，命令很简单：

  zip lambda.zip main
  

  多余的文件只会徒增体积，完全没必要。

• 清理无用依赖：虽然你说已经删了多余依赖，但可以再用go mod tidy命令自动清理go.mod里没用到的间接依赖，确保编译时只有真正需要的代码被打包进去。aws-lambda-go这个库本身已经很轻量了，这一步主要是防止不小心引入了冗余的间接依赖。

关于冷启动的问题：优化后包体积变小，冷启动时间肯定会有明显改善。Go本身的二进制启动速度就很快，再配合小体积包，冷启动时间能降到几百毫秒甚至更低，完全能追上你原来.NET Lambda的表现。

内容来源于stack exchange