直接用官方golang:1.22镜像无法直接开发，因其精简设计仅含编译器和运行时，缺失ca-certificates、git、dlv、vim等开发必需组件，导致go mod download失败、调试不可用、编辑困难。
直接用 golang:1.22 镜像跑开发环境会卡在第一步：连 go mod download 都失败——缺 ca-certificates、没 git、dlv 找不到，更别说编辑和调试了。
为什么官方 golang 镜像不能直接用于开发
官方镜像（如 golang:1.22-alpine 或 golang:1.22-slim）只保留 Go 编译器和运行时，删掉了几乎所有开发依赖。这不是 bug，是设计选择：它面向构建而非交互式开发。
-
go mod download报x509: certificate signed by unknown authority→ 缺ca-certificates -
git clone报bash: git: command not found→ 镜像没装git -
dlv debug启动失败 →command not found: dlv，且默认用户是root，挂载宿主机代码时权限易冲突 - 想改个配置就得
docker exec -it xxx sh，进去发现连vim都没有
基于编译环境的开发镜像怎么写 Dockerfile
核心思路：以 golang:1.22 为基底，叠加「开发必需但不污染构建逻辑」的组件。不是堆功能，而是补断点。
- 基础工具链：Debian 系用
apt-get install -y git curl vim ca-certificates；Alpine 系用apk add --no-cache git curl vim ca-certificates - 调试支持：
go install github.com/go-delve/delve/cmd/dlv@latest（注意必须用go install，go get已弃用） - 非 root 用户：
useradd -u 1001 -m -d /workspace developer+USER developer，避免挂载源码时写入权限被拒 - 模块缓存持久化：
VOLUME ["/go/pkg/mod"]，否则每次重启容器都要重下所有依赖 - 工作目录统一设为
WORKDIR /workspace，和 VS Code Remote-Containers 默认路径对齐
docker-compose.yml 必须配对的关键项
本地开发不是“跑起来就行”，而是要让编辑、构建、调试流畅通。漏一项，VS Code 就连不上调试器或找不到模块。
-
volumes至少挂载两项：./src:/workspace/src（源码同步）和~/.cache/go-build:/go/cache（构建缓存复用） -
environment必设：GO111MODULE=on+GOPROXY=https://proxy.golang.org,direct（国内可换https://goproxy.cn） -
ports要暴露2345:2345（dlv默认端口），否则 VS Code 的forwardPorts没东西可转 -
command别写死sh，用tail -f /dev/null让容器常驻，再通过docker exec -it mygo sh进去操作
VS Code Remote-Containers 连接失败的硬伤点
90% 的连接失败不是镜像问题，是 devcontainer.json 配置漏项或路径错位。
- 必须显式声明
"features"：哪怕镜像里已装好dlv，也得加"ms-vscode.go"扩展支持，否则调试协议不激活 -
"forwardPorts": [2345]缺失 → VS Code 不自动开隧道，dlv监听端口对外不可达 -
"postCreateCommand"建议加一句go mod init example.com/project || true，防止首次打开项目时因无go.mod报错中断初始化 - Windows 用户注意：
"mounts"中路径必须用//c/Users/xxx格式，C:\Users\xxx会被忽略
最易被忽略的是 Go 模块缓存挂载和非 root 用户权限的组合——两者缺一，go mod download 就会反复失败，且错误提示极其隐蔽，只在 docker logs 里闪一下就消失。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
