GoLand调试gRPC服务必须启用go mod且GOPROXY可用；断点不生效或报错找不到包，主因是模块代理异常、本地缓存污染或源码路径映射错误，需确认GO111MODULE=on、配置可靠GOPROXY、清理go.sum与GOMODCACHE、确保proto生成代码在项目内且路径匹配，并严格校验远程调试时的源码路径映射。
GoLand 调试 gRPC 服务必须启用 go mod 且 GOPROXY 可用
如果你的 go.mod 文件存在但调试时断点不生效、go run 报错找不到包，大概率是模块代理或本地缓存出问题。GoLand 在调试时会调用 go build 或 go run，它不走 GOPATH 模式，也不自动 fallback 到 vendor —— 即使你有 vendor 目录，只要 GO111MODULE=on（默认），它就只认 go.mod 和 GOPROXY。
常见错误现象：could not import xxx (cannot find package)、断点灰掉、Variables 面板空、调试器启动后立刻退出。
- 确认
GO111MODULE是on（不是auto）：终端执行go env GO111MODULE - 设置可靠代理：在 GoLand 的
Settings > Go > Go Modules中填入https://goproxy.cn或https://proxy.golang.org，勾选Enable Go modules integration - 删掉
go.sum和$GOMODCACHE下对应模块的缓存目录（如google.golang.org/grpc@v1.60.0），再执行go mod tidy - 确保
protoc-gen-go和protoc-gen-go-grpc已安装在$GOPATH/bin，且该路径在系统PATH中（GoLand 终端和调试器都依赖它）
proto 编译生成的 .pb.go 和 _grpc.pb.go 必须在项目内可读
GoLand 调试器不会解析 import "google.golang.org/grpc" 这类远程路径下的源码；它只对当前项目打开的文件（即你在编辑器里能点开的那些）做符号映射。所以如果你把 hello_grpc.pb.go 放在 $GOPATH/src/... 里，而项目根目录下没 link 或 copy 过来，断点打不进服务方法内部。
正确做法是：所有 .proto 文件放在项目内（如 ./api/），然后用 protoc 命令生成代码到项目子目录（如 ./pb/），并在 go.mod 中声明 replace（如果需要覆盖官方版本）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 生成命令示例：
protoc --go_out=./pb --go-grpc_out=./pb ./api/hello.proto -
option go_package = "example.com/myapp/pb";必须与生成路径一致，否则go build会报import path mismatch - 不要用
go get google.golang.org/grpc直接拉 master 分支——它可能和你本地 protoc 插件版本不兼容，导致_grpc.pb.go里缺失UnimplementedXXXServer方法，调试时 panic
GoLand 远程调试 gRPC 服务需暴露 dlv 并严格匹配源码路径
本地直接 run/main.go 调试没问题，但微服务常以 daemon 方式运行（比如 nohup ./server &），这时必须用 dlv headless 模式 + GoLand Remote Debug 配置，否则无法 attach。
关键坑点：容器或远程机器上的源码路径和你本地打开的项目路径必须完全一致，否则断点加载失败（即使文件名一样也不行）。
- 启动服务时加
dlv：例如dlv --listen=:40000 --headless --api-version=2 --accept-multiclient exec ./server - GoLand 新建
Go Remote配置：Host 填localhost（如果是 Docker 则填宿主机 IP），Port 填40000 - Path Mapping 必须精确：左边填你本地项目根路径（如
/Users/me/mygrpc），右边填容器内或远程机器上对应的绝对路径（如/app）——注意不是/app/src或/app/cmd/server - 如果用了
go mod vendor，vendor 目录也得一并挂载或同步过去，否则第三方包里的断点无效（比如grpc.Server.Serve内部）
调试 gRPC 客户端请求时别忽略 context 和超时设置
很多初学者调试客户端卡在 conn, err := grpc.Dial(...) 或 c.SayHello(ctx, req) 不返回，不是网络问题，而是 context 被 cancel 或 timeout 太短，导致请求还没发出去就被终止。
GoLand 的调试器能看到 ctx.Deadline() 和 ctx.Err()，但容易忽略它们是在哪一层被设的。
- 客户端调试时，在
grpc.Dial后加一行log.Printf("conn state: %v", conn.GetState())，确认是否为READY - 检查
context.WithTimeout的 duration 是否合理（比如设了100 * time.Millisecond，但服务端处理要 200ms） - 在服务端
SayHello方法第一行打个断点，如果根本进不去，说明请求没到达 server —— 此时重点查 client 端 dial 参数（WithTransportCredentials(insecure.NewCredentials())忘加会导致 TLS handshake timeout） - 用
grpc.WithBlock()强制阻塞等待连接建立，方便调试连接阶段问题（上线前记得删掉）
调试 gRPC 微服务最麻烦的从来不是语法或配置，而是路径映射、模块缓存、context 生命周期这三处看不见的“隐性依赖”——它们不出错时一切正常，一出错就表现成断点无效、变量为空、连接卡死，且错误信息极其模糊。动手前先确认这三项是否干净，比反复重启 IDE 有效得多。
