go交叉编译windows程序需显式设置goos=windows和goarch，确保main.go存在且含func main()；启用cgo_enabled=0可避免dll依赖；加-ldflags "-s -w"减小体积；exe不可在linux/macos直接运行。
GOOS=windows 编译失败：找不到 main 包
Go 不能跨平台编译默认可执行文件，必须显式指定目标操作系统和架构。没设 GOOS 或 GOARCH 时，它只会用当前环境的配置（比如你在 macOS 上跑 go build，结果是 macOS 的二进制）。
常见错误现象：build failed: no Go files in 或 cannot find package "main"，其实不是代码问题，而是工作目录不对或 main.go 不在当前路径下。
- 确保当前目录包含
main.go且该文件里有func main() - 运行前先确认：
go list -f '{{.Name}}' .输出应为main - Windows 编译命令必须带环境变量：
GOOS=windows GOARCH=amd64 go build -o app.exe（Linux/macOS 下） - Windows 用户在 PowerShell 里要写成：
$env:GOOS="windows"; $env:GOARCH="amd64"; go build -o app.exe
生成的 exe 在 Windows 上双击闪退
Go 默认静态链接，但如果你用了 cgo（比如调了 SQLite、OpenSSL、某些 syscall 封装），就可能依赖系统 DLL，而目标机器没装 VC++ 运行库或缺少对应 DLL。
典型表现：双击无反应，或弹窗报错“VCRUNTIME140.dll 丢失”“api-ms-win-crt-runtime-l1-1-0.dll 不可用”。
- 关闭 cgo 是最稳妥解法：
CGO_ENABLED=0 GOOS=windows go build -o app.exe - 如果必须用 cgo（如调 C 库），就得打包对应 Visual C++ Redistributable，或让构建机装好完整 VS 工具链再编译
- 检查是否引用了 Windows 特有路径或权限 API（比如
os.UserHomeDir()在旧版 Go 会出错，建议升级到 Go 1.12+）
exe 文件太大（动辄 5–10MB）
Go 默认把整个运行时和所有依赖都打进单个二进制，这是优点也是“缺点”——对分发友好，但体积直观。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实际项目中，用户只关心能不能双击运行、有没有额外依赖，不关心内部多大。但若真要压体积，得从链接阶段入手。
- 加
-ldflags "-s -w"：去掉符号表和调试信息，通常能减掉 1–3MB - 避免导入未使用的包（尤其是
net/http/pprof、expvar这类调试工具） - 不用
upx压缩：虽然能再压 30%，但部分杀软会误报，且 UPX 本身不被 Go 官方支持 - 注意：
-trimpath对体积影响极小，主要解决构建路径泄露，不是压缩手段
交叉编译时提示 “exec format error” 或 “cannot execute binary file”
这是 Linux/macOS 主机上编译 Windows 二进制后，又试图在本地直接运行导致的。Unix-like 系统无法执行 PE 格式（.exe）文件。
本质不是编译失败，而是你误把 Windows 产物当成本地程序跑了。
- 编译完立刻传到 Windows 虚拟机或物理机上测试，别在宿主机上
./app.exe - 可以用
file app.exe验证格式：输出应含PE32+ executable (console) x86-64 - 若在 GitHub Actions 或 CI 中构建，记得用
runs-on: windows-latest才能真正跑 Windows 测试，Linux runner 上只能做交叉编译
最容易被忽略的是 cgo 和构建环境的一致性——哪怕只是加了一行 #include <stdio.h></stdio.h>，整个链接行为就变了。别假设“我什么都没改，应该没问题”，交叉编译里，环境变量、C 编译器版本、甚至 shell 类型（bash/zsh/PowerShell）都可能悄悄改变结果。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
