Go在Cygwin/MinGW下build失败主因是cgo与工具链不兼容，应禁用cgo（CGO_ENABLED=0）或改用MinGW-w64 gcc；需显式设GOOS=windows、GOARCH=amd64；避免Cygwin路径抽象干扰，测试时指定TEST_TMPDIR。
Go build 在 Cygwin/MinGW 下报 exec: "gcc": executable file not found in $PATH
Go 默认启用 cgo，而 Cygwin/MinGW 的 gcc 路径、ABI 和 Go 期望的原生 Windows 工具链不兼容。这不是 Go 安装问题，是环境混用导致的链接阶段失败。
- 最直接的解法是禁用 cgo：
CGO_ENABLED=0 go build（Cygwin/MinGW 中必须显式设置，不能依赖默认值） - 若必须用 cgo（比如调 C 库），不要用 Cygwin 的
gcc；改用 MinGW-w64 的x86_64-w64-mingw32-gcc，并确保CC环境变量指向它：CC=x86_64-w64-mingw32-gcc go build - Cygwin 的
/usr/bin/gcc生成的是 Cygwin DLL 依赖（cygwin1.dll），Go 编译出的二进制无法加载——这不是警告，是运行时直接崩溃
交叉编译出来的二进制在 Windows 原生 cmd.exe 里闪退或报错 failed to load DLL
根本原因是：Cygwin/MinGW 环境下未设对 GOOS 和 GOARCH，Go 默认按宿主环境生成目标，而 Cygwin 的 GOOS=linux（错）、MinGW 的 GOOS=windows 但 CGO_ENABLED=1 时仍会偷偷链接 MinGW runtime。
- 明确指定目标平台：
GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -o app.exe main.go - 别信
go env GOOS的输出——Cygwin 下它常返回linux，这是误导；MinGW 下可能返回darwin或空，必须手动覆盖 - 生成的
.exe文件需在 Windows 原生命令行测试，不要在 Cygwin bash 里用./app.exe验证，那会走 Cygwin 层，掩盖 DLL 加载失败问题
使用 os/exec 调用系统命令（如 git、make）行为异常
Cygwin/MinGW 的 PATH 里混着 Unix 风格路径（/usr/bin）和 Windows 风格路径（C:\tools\git\bin），Go 的 exec.Command 在 Windows 模式下只认 .exe 后缀，且不自动扩展 PATHEXT，更不会把 /usr/bin/make 映射成可执行文件。
- 优先用绝对路径调用：比如
exec.Command("C:/Program Files/Git/mingw64/bin/git.exe", "status") - 避免依赖
os.LookPath查找 Cygwin 工具——它返回的/usr/bin/git在 Go 原生 Windows 运行时无法执行 - 若必须用 Cygwin 工具链，启动子进程时显式调用
bash -c "git status"，但注意这会让错误码、信号传递变得不可靠
go test 中 os.TempDir() 返回路径含 Cygwin 挂载点（如 /tmp）导致测试失败
Go 运行时在 Cygwin 下会把 /tmp 当作合法临时目录，但 Windows 原生程序（包括 Go 测试中启动的子进程）无法访问 /tmp 对应的真实路径（如 C:\cygwin64\tmp），造成文件创建失败或权限拒绝。
- 强制指定临时目录：
TEST_TMPDIR=C:/temp go test，并确保该路径存在且无空格、无中文 - 在测试代码里别硬编码
/tmp，改用os.MkdirTemp("", "test-")，它会绕过os.TempDir()的 Cygwin 路径逻辑 - MinGW 下同样存在此问题，尤其当测试调用
exec.Command("cmd", "/c", "echo", "test")时，cmd根本不认识/tmp
真正麻烦的从来不是“能不能跑”，而是“跑的时候以为自己在 Windows，其实被 Cygwin 的路径抽象悄悄劫持了”。哪怕只用了一次 os.Getwd() 或 filepath.Join()，都可能把 /cygdrive/c 塞进参数里传给原生 Windows 工具——这种问题不会报错，只会静默失败。
