Docker不是Go项目必备工具，但绝大多数云原生Go项目实际运行在Docker容器中；不配置好Docker环境，CI/CD、本地调试和镜像发布将受阻，尤其难以复现生产环境行为。
直接说结论：不是“必备”，但绝大多数云原生 Go 项目实际运行在 Docker 容器里，不搭好这个环境，CI/CD、本地调试、镜像发布都会卡住——尤其当你需要复现生产环境行为时。
为什么不能直接用 go build 生成的二进制丢进空容器？
Go 静态编译确实能省掉 libc 依赖，但现实里常踩三个坑：
-
CGO_ENABLED=0关闭后，net包默认用纯 Go DNS 解析，可能绕过/etc/resolv.conf或忽略ndots设置，导致 k8s 内部服务发现失败 - 某些库（如
sqlite3、cgo调用的系统调用）强制依赖 libc，关 CGO 就编译不过 - 没加
-ldflags="-w -s"的二进制体积大 2–3 倍，拉镜像慢，还暴露符号表
选 golang:alpine 还是 golang:slim？
别无脑选 Alpine —— 它用 musl libc，和主流 Linux 发行版（glibc）ABI 不兼容。只要你的 Go 代码或依赖里有任何 cgo 调用（比如 os/user 查用户、net 用系统 resolver），Alpine 就会 panic 或静默失败。
实操建议：
- 开发阶段用
golang:1.23-slim（基于 Debian，glibc 兼容性好，体积比latest小 40%） - 构建阶段用多阶段：第一阶段用
golang:1.23-slim编译，第二阶段用debian:slim或scratch运行（前提是确认没 cgo） - 真要用 Alpine？加
GOOS=linux GOARCH=amd64 CGO_ENABLED=1，且必须安装apk add --no-cache git ca-certificates
Dockerfile 里 COPY . . 为什么总让镜像变大？
因为没忽略 go mod download 缓存、vendor 目录、测试数据、IDE 配置文件——这些全被 COPY 进镜像层，且无法被后续 RUN go clean -modcache 清掉（COPY 是只读层）。
关键操作：
- 在
COPY前加.dockerignore，至少包含：node_modules/、vendor/、**/*.md、.git/、testdata/ - 多阶段构建中，把
go mod download单独提成一层（利用 layer cache），再COPY go.mod go.sum .，最后COPY . . - 避免
RUN go build后不清理：用RUN go build -o /app/main . && rm -rf $GOPATH不够，要显式go clean -cache -modcache
本地调试时 go run 和容器内行为不一致？
根本原因不是 Go 版本差异，而是环境变量、挂载路径、DNS 策略三者错位。比如：
-
go run读的是宿主机/etc/hosts，容器默认走 bridge 网络的 DNS，查不到你host.docker.internal映射的服务 -
os.Getwd()在容器里返回/或/app，但本地可能是/home/user/project，硬编码相对路径就炸 - 时间不同步：Docker Desktop for Mac 默认不共享宿主机时区，
time.Now()比 UTC 快 8 小时但没设TZ，日志时间戳全乱
解决办法很简单：启动容器时加 -v $(pwd):/app -w /app -e TZ=Asia/Shanghai --add-host=host.docker.internal:host-gateway，再配合 go run -mod=mod 强制模块模式，就能逼近容器内行为。
真正麻烦的从来不是写 Dockerfile，而是搞清哪一行命令在哪个上下文里执行、谁在读哪个文件、环境变量到底被谁覆盖了——这些细节不会报错，只会让程序在某个环境里“差不多能跑”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
