交叉编译必须禁用CGO以生成真正静态二进制，否则因动态链接libc.so.6导致exec format error；验证需file命令确认statically linked；tar.gz与zip格式不可混用，打包时须严格按顺序Close，ZIP必须调用Close()写入EOCD，大文件须流式处理。
交叉编译必须禁用 CGO，否则生成的二进制不是真正静态的
GOOS=linux GOARCH=arm64 go build 产出的文件在 ARM64 Linux 上运行报 exec format error 或 cannot execute binary file，大概率是因为没关 CGO_ENABLED。Go 默认启用 cgo，一旦调用系统 libc（比如 DNS 解析、用户组查询），就会动态链接 libc.so.6，导致二进制无法脱离宿主环境运行。
正确做法是显式关闭：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o diminutio-linux main.goCGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o diminutio.exe main.goCGO_ENABLED=0 GOOS=darwin GOARCH=arm64 go build -o diminutio-macos main.go
验证是否成功：用 file diminutio-linux 检查输出，应为 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked —— 关键是 statically linked，不能出现 dynamically linked。
打包压缩要分清 tar.gz 和 zip，别混用 archive/tar 和 archive/zip
tar.gz 是归档 + 压缩两层结构，zip 是单层归档格式；目标平台决定选哪个：Linux/macOS 用户习惯 .tar.gz，Windows 用户更认 .zip。两者实现逻辑完全不同，不能靠改后缀糊弄。
生成 .tar.gz 的关键顺序：
- 先
os.Create("app.tar.gz") - 再
gzip.NewWriter(file) - 再
tar.NewWriter(gzipWriter) - 写完所有文件后，必须按相反顺序 Close：
tarWriter.Close()→gzipWriter.Close()→file.Close()，漏任一环节都会导致解压时校验失败
生成 .zip 的关键点：
- 每个
zip.FileHeader.Name必须是 Unix 风格相对路径，含..或以/开头会触发 Zip Slip - 路径统一用
filepath.ToSlash()转斜杠，Windows 下"sub\file.txt"直接传进去，部分解压工具会跳过 - 中文名需设
header.SetUTF8(true)（Go ≥ 1.22）或header.Flags = 1（旧版）
自动打包脚本里最容易漏掉 zip.Writer.Close()，导致 ZIP 打开失败
浏览器下载的 ZIP 双击无反应、7-Zip 提示“无法打开存档”、macOS 归档工具静默失败——90% 是因为没调 zipWriter.Close()。ZIP 格式末尾必须有 EOCD（End of Central Directory）记录，只有 Close() 才会写入它。Flush() 不行，它只刷缓冲区，不写 EOCD。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见错误写法：defer zipWriter.Close() 看似稳妥，但 HTTP handler 中一旦 panic 或提前 return，defer 就不会执行，客户端已收到部分数据，解压器拿到的就是非法 ZIP。
安全做法：
- 所有
io.Copy()完成后，立即显式调用zipWriter.Close() - 若用 defer，必须确保函数内无未捕获 panic，或搭配
recover()使用 - 用
file.Stat().Size()检查最终文件大小是否合理（比如空 ZIP 应 ≈ 22 字节）
大文件打包必须流式处理，别把整个文件读进内存
对几个 GB 的日志或视频文件，直接 os.ReadFile() 再 zipWriter.Write()，Go 进程很快 OOM。这不是 ZIP 库的问题，而是没利用好 Go 的流式 I/O 模型。
正确链路始终是：打开源文件 → 创建 header → io.Copy(dstWriter, srcFile) → 关闭 writer。
注意细节：
- 小文件或已压缩类型（
.jpg、.mp4、.gz）建议设header.Method = zip.Store，跳过 deflate 节省 CPU - 用
mime.TypeByExtension(ext)判断 MIME 类型比单纯看扩展名更可靠 - 避免并发写同一个
zip.Writer，标准库不支持，会 panic 或损坏 ZIP
路径越界、EOCD 缺失、动态链接残留——这三个点只要漏一个，生成的包在目标机器上就大概率跑不起来或打不开。自动化脚本里最该加检查的不是构建成功与否，而是 file 命令输出、解压命令返回码、以及目标路径是否真的落在允许范围内。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
