Go在Windows上默认禁用CGO_ENABLED=0是安全策略，需同时满足PATH含gcc且ABI匹配（如MSYS2选对mingw64/ucrt64 shell）、用pacman安装Go而非官方msi、正确配置GOROOT/GOPATH及#cgo CFLAGS/LDFLAGS路径，才能正常编译cgo程序。
为什么 go env 显示 CGO_ENABLED=0？
这不是错误，而是 Go 在 Windows 上的默认安全策略——它假设你不需要调用 C 代码，所以主动禁用 CGO_ENABLED。一旦你写 import "C" 或用 // #include，构建就会失败，报错 exec: "gcc": executable file not found in %PATH%。
真正生效的前提有两个：一是系统 PATH 中能查到 gcc，二是 Go 工具链能匹配该 gcc 的 ABI（比如 UCRT vs MinGW-w64）。MSYS2 提供多个子环境（mingw64、ucrt64、clang64），选错 shell 就会导致链接器不兼容。
- 确认当前终端是
mingw64.exe或ucrt64.exe（不是msys2.exe），否则gcc虽存在但 ABI 不匹配 - 运行
where gcc（Windows 命令）或which gcc（MSYS2 内），输出应为C:\msys64\mingw64\bin\gcc.exe或类似路径 - 执行
go env -w CGO_ENABLED=1，再验证go env CGO_ENABLED返回1
用 pacman 安装 Go 还是用官方 .msi？
必须用 pacman -S mingw-w64-x86_64-go，不能用官网下载的 Windows 版 go1.22.3.windows-amd64.msi。
官方安装包把 GOROOT 设在 C:\Program Files\Go，路径含空格且使用 Windows 原生路径语义；而 MSYS2 的 /mingw64/lib/go/src 是 POSIX 路径结构，Go 工具链会按此查找 fmt、net/http 等标准库。混用会导致 unrecognized import path "crypto/tls" 这类错误。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 安装命令只在
mingw64或ucrt64终端中执行，不要在msysshell 下运行 - 安装后立即设置
export GOROOT=/mingw64/lib/go，否则go version可能正常但go build找不到标准库源码 -
GOPATH推荐设为/mingw64（即export GOPATH=/mingw64），这样go install产出的二进制自动落入/mingw64/bin，已包含在 PATH 中
编译含 CGO 的项目时找不到头文件或库
常见现象是 fatal error: openssl/ssl.h: No such file or directory 或 undefined reference to SSL_new。这不是 Go 的问题，而是 #cgo 指令没告诉编译器去哪里找头文件和静态库。
MSYS2 中所有第三方 C 库（如 openssl、openslide、sqlite3）都通过 pacman 安装，头文件统一放在 /mingw64/include，库文件在 /mingw64/lib。你需要显式告知 cgo：
- 在 Go 源文件顶部添加：
// #cgo CFLAGS: -I/mingw64/include和// #cgo LDFLAGS: -L/mingw64/lib -lssl -lcrypto - 如果用
go mod，避免在$GOPATH/src下初始化项目——Go 1.16+ 默认 module 模式，go build会忽略GOPATH，但#cgo指令仍依赖环境变量和路径硬编码 - 动态库（DLL）运行时需确保对应
.dll在PATH中，例如openssl的libssl-1_1.dll位于/mingw64/bin，把它加进 Windows PATH 或复制到可执行文件同目录
为什么 Fyne 或 SQLite 链接失败？
典型错误如 undefined reference to __imp_glfwInit 或 cannot find -lsqlite3，根本原因是链接器找不到符号定义，而非缺失源码。
MinGW-w64 的链接器（ld）对库名敏感：-lsqlite3 会去找 libsqlite3.dll.a（导入库）或 libsqlite3.a（静态库），而不是 sqlite3.dll。MSYS2 的 pacman 默认只装 DLL 和头文件，静态库需额外安装（如 mingw-w64-x86_64-sqlite 包含 .dll.a，但 mingw-w64-x86_64-sqlite-static 才含 .a）。
- 优先用
pacman -S mingw-w64-x86_64-glfw mingw-w64-x86_64-sqlite，确保安装的是对应子环境（mingw64或ucrt64）的包 - 检查
/mingw64/lib/libsqlite3.dll.a是否存在，不存在则说明没装对包，或装到了别的子环境目录（如/ucrt64/lib） - 若坚持静态链接，加
// #cgo LDFLAGS: -static-libgcc -static-libstdc++，但注意多数 MSYS2 C 库不提供完整静态版本，强行启用易报错
最易被忽略的一点：PATH 中若有多个 MinGW 版本（比如旧版 TDM-GCC 和 MSYS2 的 mingw64），gcc 可能调用了 A 版本，而 go build 却链接了 B 版本的库——结果就是符号找不到。务必清空非 MSYS2 的 GCC 相关 PATH 条目。
