Go跨平台需显式指定GOOS和GOARCH，关闭cgo（CGO_ENABLED=0）适配Alpine/Distroless镜像，避免硬编码路径与系统命令，全链路验证目标平台行为。
Go 编译时指定 GOOS 和 GOARCH 才能真正跨平台
Go 本身支持交叉编译，但默认只构建当前系统可运行的二进制。不显式设置 GOOS 和 GOARCH，go build 就不会生成目标平台的可执行文件——哪怕你在 macOS 上写服务，想部署到 Linux 服务器，也必须手动指定。
-
GOOS=linux GOARCH=amd64 go build -o service-linux main.go（生成标准 Linux x86_64 二进制） -
GOOS=linux GOARCH=arm64 go build -o service-arm64 main.go（适配 AWS Graviton 或树莓派） -
GOOS=windows GOARCH=amd64 go build -o service.exe main.go（注意 Windows 下后缀建议保留.exe）
遗漏 CGO_ENABLED=0 是常见坑：一旦项目依赖 cgo（比如用 net 包做 DNS 解析，或引入 SQLite、OpenSSL 等），默认会链接系统 libc，在无 glibc 的 Alpine 容器里直接报 no such file or directory。稳妥做法是加 CGO_ENABLED=0 关闭 cgo，除非你明确需要它。
微服务容器镜像选 Alpine 还是 Distroless？关键看是否启用 cgo
Alpine 镜像小、攻击面低，但自带 musl libc；Distroless（如 gcr.io/distroless/base）更干净，但完全不含 shell 和调试工具。两者都不含 glibc，所以只要用了 cgo，默认就跑不起来。
- 若已设
CGO_ENABLED=0：优先选gcr.io/distroless/static，体积最小（≈2MB），启动最快 - 若必须用 cgo（例如调用硬件加速库）：用
alpine:latest+ 手动apk add ca-certificates，否则 HTTPS 请求会因缺少根证书失败 - 别用
scratch镜像直接塞二进制：它连/etc/ssl/certs都没有，HTTP 客户端会报x509: certificate signed by unknown authority
os/exec 和文件路径硬编码是跨平台最大隐形陷阱
微服务常需调用外部命令（如 curl、jq）或读写配置文件。这些操作在不同 OS 行为差异极大，且容易被本地开发环境掩盖。
Destoon B2B网站管理系统是一套完善的B2B(电子商务)行业门户解决方案。系统基于PHP+MySQL开发，采用B/S架构，模板与程序分离，源码开放。模型化的开发思路，可扩展或删除任何功能；创新的缓存技术与数据库设计，可负载千万级别数据容量及访问。 系统特性1、跨平台。支持Linux/Unix/Windows服务器，支持Apache/IIS/Zeus等2、跨浏览器。基于最新Web标准构建，在
立即学习“go语言免费学习笔记（深入）”；
-
exec.Command("ls", "-l")在 Windows 上直接失败——应改用 Go 原生filepath.WalkDir或抽象为接口 -
os.Open("/etc/myapp/config.yaml")在 Windows 容器里路径不存在；改用filepath.Join(os.Getenv("APP_HOME"), "config.yaml")并通过环境变量注入 - Windows 路径分隔符是
\，但 Go 的filepath包自动处理；唯一要注意的是字符串字面量里别写死"C:\config"（反斜杠转义），要用`C:\config`或"C:\\config"
测试阶段必须在目标平台真实运行，不能只靠构建成功
交叉编译通过 ≠ 服务能跑。DNS 解析、时区、信号处理、文件锁等行为都依赖 OS 内核和 C 库实现。
- CI 中至少跑一次
docker run --platform linux/arm64启动服务并curl http://localhost:8080/health - 本地开发用 Docker Desktop 时，
docker buildx build --platform linux/amd64,linux/arm64可一次性产出多架构镜像 - 别忽略时区：Alpine 默认 UTC，但业务日志可能依赖本地时区。启动容器时加
-e TZ=Asia/Shanghai并在代码中用time.LoadLocation("Asia/Shanghai")显式指定
跨平台不是编译选项开关，而是从构建、镜像、路径、系统调用到测试全链路对 OS 差异的显式认知和控制。最容易被跳过的，是那个在 macOS 上跑得好好的 exec.Command("kill") —— 到 Linux 容器里才发现信号名不一致，到 Windows 里直接 panic。
