Go无服务函数冷启动延迟与部署包体积强相关，体积大头是go.mod中层层嵌套的间接依赖；需从依赖源头精简（优先标准库、查清引入路径、替换“全家桶”框架）、执行go mod tidy清理冗余、编译时禁用CGO并加-ldflags="-s -w"、容器用distroless镜像且对二进制UPX压缩。
Go 无服务函数（如 AWS Lambda、阿里云 FC、腾讯云 SCF）的冷启动延迟和部署包体积强相关，而体积大头往往不是业务代码，而是 go.mod 里层层嵌套的间接依赖。控制不住依赖，压缩再狠也白搭。
go mod tidy 不等于依赖干净
很多人执行完 go mod tidy 就以为依赖已精简，但实际仍可能残留大量未使用模块——尤其当项目曾引入测试工具、CI 脚本依赖或临时 replace 后忘记清理时。
-
go mod tidy只删掉「未被 import 的直接依赖」，对间接依赖（// indirect标记）不做判断，哪怕某个 v0.3.1 的日志库只被一个已删除的 mock 工具拉进来，它仍会留在go.mod中 - 运行
go list -m all | grep -v 'std\|golang.org' | wc -l查总依赖数，若超 50 个，大概率存在冗余 - 对可疑包逐个执行
go mod why 包名，重点看输出中是否含test、example、mock或已弃用模块路径 - 手动检查
go.mod里的replace和exclude，长期存在的 replace 往往是旧版兼容补丁，反而阻碍依赖收敛
编译时禁用 CGO + strip 符号表是硬性前提
无服务环境不提供 libc，启用 CGO 不仅引入动态链接风险，还会把整个 cgo 工具链依赖打包进二进制，体积暴增 2–5MB 是常态。
- 必须设置
CGO_ENABLED=0，否则net、os/user等包会悄悄拉入系统级依赖 - 构建命令固定为：
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w" -o main main.go -
-s去除符号表，-w去除 DWARF 调试信息，二者合用通常减小 25%–30% 体积；漏掉任一，UPX 压缩效果也会打折扣 - 注意：若用了 SQLite、OpenSSL 等必须 CGO 的库，得换纯 Go 实现（如
mattn/go-sqlite3→tinygo/sqlite或改用远程 DB）
容器镜像层与二进制分离压缩更有效
很多团队在 Dockerfile 里对整个 /app 目录 UPX，结果发现体积没降多少——因为 distroless 镜像本身已极简，真正可压的是二进制文件本身，且 UPX 对 Go 二进制的压缩率远高于对镜像层的二次打包。
立即学习“go语言免费学习笔记（深入）”；
- 多阶段构建中，仅在 builder 阶段安装 UPX：
RUN apt-get update && apt-get install -y upx-ucl - 最终 stage 只 COPY 编译好的二进制：
COPY --from=builder /workspace/main /bin/main - UPX 命令用
upx --best --lzma /bin/main，比默认参数再小 10%–15%；但注意部分云厂商安全扫描会将 UPX 打包标记为可疑，需提前报备 - 避免用
scratch镜像：它不含证书信任链，http.Client访问 HTTPS 会因 CA 证书缺失失败；改用gcr.io/distroless/static:nonroot更稳妥
标准库能覆盖的场景，别碰第三方包
无服务函数生命周期短、逻辑简单，90% 的「功能需求」其实在标准库已有轻量实现，引入第三方包纯粹是为开发习惯让步，代价却是体积翻倍和冷启动延长。
- 路由：不用
gin或echo，net/http+http.ServeMux足够支撑 10+ 接口，体积差 3MB+ - JSON：
encoding/json性能足够，json-iterator或easyjson在无服务场景下几乎无收益，反而增加依赖树深度 - 配置：不要
viper，函数计算平台通常通过环境变量注入配置，os.Getenv直接取值即可 - 日志：
log或zerolog（非logrus），后者无 UI/颜色/钩子等无用特性，体积比前者小 60%
真正卡住体积的从来不是单个大包，而是「每个小包都带一套自己的 context、errors、sync 实现」——Go 模块没有全局去重机制，相同功能的工具包被不同依赖各自 vendor，链接期也无法合并。所以清理动作必须前置到依赖引入源头，而不是等打包时硬压。
