Go框架不提供容器化能力，环境一致性依赖Dockerfile与构建流程：必须用CGO_ENABLED=0 GOOS=linux构建，选scratch或alpine基础镜像，配置外置、非root运行，HTTPS需ca-certificates，时区须显式加载。
Go语言框架本身不提供容器化能力，环境一致性必须靠 Dockerfile + 构建流程约束来保障，而不是靠框架配置自动解决。
为什么不能依赖框架自带的“Docker支持”
很多 Go 框架（如 Gin、Echo、Gin-Web、GF）文档里提到“支持 Docker”，实际只是示例一个 Dockerfile，框架本身既不生成镜像，也不校验构建环境。真正决定环境一致性的，是你的 go build 参数、基础镜像选择、COPY 范围和运行时依赖（比如 CA 证书、时区、用户权限）。
-
go run在本地能跑 ≠go build出的二进制在 Alpine 上能发起 HTTPS 请求（缺ca-certificates） - 用
golang:1.22构建，却用ubuntu:22.04运行，可能因 GLIBC 版本不匹配直接exec format error - 框架日志写到
/var/log/app，但镜像里没创建该目录，容器启动就 panic
CGO_ENABLED=0 GOOS=linux go build 是生产构建的硬性前提
Go 默认开启 CGO，会链接宿主机的 libc 和 DNS 库；一旦你在 macOS 或 Windows 上构建，再扔进 Linux 容器，大概率崩溃或解析域名失败。必须显式关闭。
- 构建命令必须带
CGO_ENABLED=0 GOOS=linux，否则即使用了scratch镜像也会失败 - 如果项目真用到了
cgo（比如调用 SQLite、OpenSSL），就得改用golang:alpine构建，并在运行镜像中安装对应 so（如apk add sqlite-dev），复杂度陡增 -
go build -a -installsuffix cgo是旧写法，Go 1.20+ 已不推荐；-a强制重编译所有依赖，纯属冗余
多阶段构建中，scratch 镜像比 alpine 更安全但更难调试
scratch 是空镜像，体积最小、攻击面最少，但没 shell、没 strace、没 ls，容器一挂你就只能靠日志猜问题。
立即学习“go语言免费学习笔记（深入）”；
- 开发/测试阶段建议用
alpine:latest，加apk --no-cache add ca-certificates tzdata补齐基础能力 - 上线前切回
scratch，前提是已验证：HTTPS 调用正常、时区正确、静态文件路径可读 - 别在
scratch里硬编码/etc/timezone或/usr/share/zoneinfo——它根本不存在；改用time.LoadLocation("Asia/Shanghai")显式加载
框架配置文件（如 config.yaml）不能打进镜像
把 config.yaml COPY 进镜像，等于把数据库密码、API Key 编译进二进制——违反最小权限原则，也违背不可变基础设施理念。
- 配置必须通过环境变量或挂载卷注入：
docker run -e DB_URL=xxx -v ./config:/app/config - 框架读配置时，优先级应为：环境变量 > 挂载文件 > 内置默认值
- 若框架强制从
./config.yaml加载且不支持覆盖，就得在ENTRYPOINT脚本里先生成临时配置，再 exec 启动
最常被忽略的一点：容器内进程 UID 默认是 root，但框架监听端口时若没做非特权端口适配（比如硬写 :80），在以非 root 用户运行的镜像里会直接 bind 失败。别等上线才发现要改代码。
