最稳妥的Go开发环境是使用官方golang:1.22（Debian基）镜像，避免Alpine因cgo和DNS问题导致调试异常；需匹配宿主机架构，合理利用go.mod/go.sum缓存加速构建；调试用dlv exec并暴露2345端口；权限问题应通过--user或Dockerfile中USER指令解决。
用官方 golang 镜像做开发环境最稳妥
直接拉取 golang:1.22（或最新稳定版）镜像，它已预装 go、git、curl 和基础编译工具，省去手动装依赖的麻烦。别用 alpine 版本做开发环境——虽然体积小，但 cgo 支持不全，net 包 DNS 解析可能出问题，调试时容易卡在 lookup 上。
常见错误现象：go run main.go 报 exec format error（宿主机是 macOS M1，却用了 amd64 镜像）；或 go build 失败提示 cannot find package "C"（缺少 gcc 和 musl-dev，这是 Alpine 的典型坑）。
- 开发阶段优先用
golang:1.22（默认debianbase） - 确认架构匹配：运行
docker info | grep "Architecture"，再选对应平台镜像（如golang:1.22-bookworm或带-arm64后缀的） - 如果必须用 Alpine，加装
apk add --no-cache git gcc musl-dev，且禁用cgo（CGO_ENABLED=0 go build）
go mod 依赖缓存怎么在容器里复用不重复下载
Docker 构建时每次重装 go mod download 极慢，尤其在国内。关键不是“挂载本地 pkg 目录”，而是利用 go mod download 的缓存机制 + 多阶段构建的 layer 复用。
真正有效的做法是：把 go.mod 和 go.sum 单独 COPY 到镜像中，再执行 go mod download，这样只要依赖没变，后续构建就直接命中缓存层。
立即学习“go语言免费学习笔记（深入）”；
- 不要在
WORKDIR之后才COPY . .，否则整个源码变动都会让go mod download层失效 - 顺序必须是：
COPY go.mod go.sum ./→RUN go mod download→COPY . . - 若用 Docker Compose 开发，可额外挂载
~/.cache/go-build到容器内/root/.cache/go-build，加速go build编译缓存
Docker 容器里调试 main.go 要开什么端口、配什么参数
Go 程序本身不监听调试端口，得靠 dlv（Delve）。直接在容器里跑 dlv 需要额外安装，且默认只绑定 127.0.0.1:2345，宿主机连不上。
正确启动方式：dlv exec --headless --continue --api-version=2 --accept-multiclient --addr=:2345 ./your-binary，注意 --addr=:2345（不是 127.0.0.1:2345），并确保 Docker 运行时加了 -p 2345:2345。
- 调试镜像需包含
dlv：在Dockerfile中加RUN go install github.com/go-delve/delve/cmd/dlv@latest - 避免用
dlv debug（会重新编译，触发go mod下载）；改用dlv exec调试已构建好的二进制 - VS Code 的
launch.json中port填2345，host填localhost（Docker Desktop for Mac/Windows 自动转发）
为什么 go run 在容器里报 permission denied 却 go build 没事
这通常不是 Go 的问题，而是容器内文件系统挂载权限导致的。比如用 docker run -v $(pwd):/app 挂载代码目录，宿主机文件属主是普通用户（UID 1000），但容器内默认以 root 启动，而某些发行版镜像（如 Debian Bookworm）对 /proc/sys/kernel/unprivileged_userns_clone 限制变严，导致 go run 尝试创建临时子进程失败。
- 临时解法：加
--user $(id -u):$(id -g)让容器以当前用户身份运行 - 根本解法：在
Dockerfile中用USER 1001创建非 root 用户，并chown -R 1001:1001 /app - 别忽略
go run是先编译再执行，它会在/tmp写临时文件；挂载卷时若宿主机/tmp权限受限，也会触发此错
复杂点在于：同一份 Dockerfile，在 Ubuntu 宿主机上跑没问题，换到 CentOS 或新版 WSL2 就失败——本质是内核参数和 user namespace 的兼容性差异，容易被当成 Go 问题排查半天。
