使用 gox 构建含 sqlite3 的 go 应用时，因 go 1.4+ 默认禁用 c 文件编译且 gox 未启用 cgo，导致 sqlite3.c 解析失败；需显式启用 cgo 并确保目标平台具备 c 工具链。
当你在项目中引入 github.com/mattn/go-sqlite3 并尝试通过 gox 进行跨平台交叉编译（如构建 linux/amd64、darwin/386 等）时，会遇到类似以下错误：
../../mattn/go-sqlite3/sqlite3.c:92 unknown #: if ../../mattn/go-sqlite3/sqlite3.c:94 6c: No such file or directory: mingw.h
这类报错的根本原因在于：go-sqlite3 是一个基于 CGO 的原生绑定库，其源码包含 .c 和 .h 文件，而 gox 默认以 CGO_ENABLED=0 模式运行 —— 这符合 Go 官方对纯静态二进制的默认偏好，但会直接禁止 C 编译器介入，导致 sqlite3.c 中的预处理指令（如 #if）和头文件引用（如 mingw.h）无法解析。
自 Go 1.4 起，go build 在 CGO_ENABLED=0 下已明确拒绝编译任何 C 源文件（Go 1.4 Release Notes），这是为未来移除内置 C 编译器（如 6c, 8c）所做的兼容性收紧。
✅ 正确解决方案是 显式启用 CGO，并确保构建环境安装了对应目标平台的 C 工具链：
1. 启用 CGO（必需）
在调用 gox 前，设置环境变量：
CGO_ENABLED=1 gox -os="linux darwin" -arch="amd64 386"
或更推荐的方式（避免污染全局环境）：
env CGO_ENABLED=1 gox -os="linux darwin" -arch="amd64 386"
⚠️ 注意：CGO_ENABLED=1 仅启用 CGO，不解决链接问题。若目标平台缺少对应 C 链接器（如 x86_64-linux-gnu-gcc），仍会链接失败。因此，gox 本身并不提供真正的交叉 C 工具链支持——它只是包装 go build，实际仍依赖宿主机或 Docker 环境中的交叉编译能力。
2. 推荐生产级实践：使用 Docker 构建
为规避本地工具链缺失问题，建议结合 docker + 多阶段构建，例如使用官方 golang:alpine 或 golang:bullseye 镜像，并安装对应 gcc 和 musl-dev / build-essential：
# 构建 linux/amd64 版本（静态链接 SQLite） FROM golang:1.22-bullseye RUN apt-get update && apt-get install -y gcc libc6-dev && rm -rf /var/lib/apt/lists/* WORKDIR /app COPY . . ENV CGO_ENABLED=1 ENV GOOS=linux GOARCH=amd64 RUN go build -ldflags="-s -w -extldflags '-static'" -o pravasan-linux-amd64 .
3. 替代方案：改用纯 Go SQLite 驱动（可选）
若无需 SQLite 原生性能或扩展功能，可考虑 modernc.org/sqlite —— 纯 Go 实现，完全兼容 database/sql，零 CGO 依赖，天然支持 gox 无配置构建：
go get modernc.org/sqlite # 替换 import _ "github.com/mattn/go-sqlite3" → import _ "modernc.org/sqlite"
总结
- gox 默认禁用 CGO，而 go-sqlite3 强依赖 CGO，必须显式设置 CGO_ENABLED=1；
- CGO_ENABLED=1 仅开启编译，不提供跨平台 C 工具链，Linux/macOS 构建 Windows 二进制仍不可行（因缺少 mingw）；
- 生产环境强烈建议使用 Docker 配置目标平台完整构建环境；
- 若场景允许，迁移到纯 Go SQLite 驱动可彻底规避 CGO 复杂性。
遵循以上任一路径，即可稳定生成含 SQLite 支持的多平台 Go 二进制。
