go环境真正就绪的标志是30秒内完成docker依赖环境拉起、带外部依赖的go test通过、vs code中任意handler可断点调试并检查request结构体。
go version 能跑，不等于环境 ready
很多开发者执行 go version 成功就以为万事大吉，结果一写测试连 go test 都报错找不到依赖，或者 go run 提示 module not found。根本原因在于：Go 1.11+ 默认启用 Go Modules，但没初始化模块、没设好 GOPROXY、没装调试器，就不是“可开发”状态。
- 必须在项目根目录执行
go mod init your-module-name，否则go test会拒绝运行（哪怕只是单个文件） - 国内用户不配
GOPROXY，go mod tidy极大概率卡死或超时；推荐设为https://goproxy.cn,direct -
go test -v ./...会递归扫描所有子包，但若某子包含build tag或未声明package test，它会静默跳过——不是成功，是被忽略
Docker 容器才是本地集成测试的默认路径
本地跑 MySQL/Redis/NATS 不是“可选”，而是 Go 集成测试的硬性前提。你在宿主机上手动启服务，端口冲突、版本混用、清理残留，三天两头崩一次。Docker 是唯一能保证每次 go test 前后环境干净、配置一致的方式。
- 别手写
docker run命令启依赖——用docker-compose.yml管理，例如 Redis 启动只需三行：redis:、image: redis:7-alpine、ports: ["6379:6379"] - Go 测试代码里不能写死
localhost:6379；应读取环境变量，比如os.Getenv("REDIS_ADDR")，然后在docker-compose up时通过environment注入 - 启动容器后要等服务 ready，直接
time.Sleep(2 * time.Second)是错的；用testcontainers-go的WaitForListeningPort或自己写连接重试逻辑
dlv 调试器不是“装了就行”，得进 PATH 且匹配 Go 版本
VS Code 点 F5 报 “Failed to launch: could not find dlv”，十有八九是 dlv 没装、装错位置、或版本与当前 Go 不兼容。Delve 不像 go 命令那样自带，它是独立二进制，必须显式安装并确保 shell 能找到。
- 安装命令必须带版本号：
go install github.com/go-delve/delve/cmd/dlv@latest；不加@latest可能拉到旧版，不支持 Go 1.23+ 的 runtime 机制 - 装完检查：
which dlv输出路径是否在$PATH中；常见错误是装到了$HOME/go/bin/dlv，但该路径没加进 shell 配置（如~/.zshrc） - VS Code 的
launch.json里不用指定dlv路径，只要它在 PATH 里；但如果用远程调试或 WSL，就得确认dlv在目标环境也存在
微服务项目起步前，protoc 和 goctl 缺一不可
如果你的项目用 go-zero、kratos 或其他 RPC 框架，光有 Go 和 dlv 还不够。第一次运行 goctl api go 就失败，不是代码问题，是工具链断在最底层。
-
protoc必须可执行：Linux/macOS 用brew install protobuf，Windows 下载 zip 包解压后把protoc.exe放进 PATH；验证用protoc --version - 两个插件必须用
go install装：protoc-gen-go和protoc-gen-go-grpc；go get已废弃，装了也不生效 -
goctl版本必须和项目go.mod中的go-zero版本一致；比如github.com/zeromicro/go-zero v1.7.5，就得go install github.com/zeromicro/go-zero/tools/goctl@v1.7.5
环境真正 ready 的标志不是“能跑 Hello World”，而是你能在 30 秒内：拉起一套含 DB + Cache + Registry 的 Docker 环境、跑通带外部依赖的 go test、在 VS Code 里对任意 handler 打断点并 inspect request 结构体——这三件事缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
