GoLand中RPC微服务断点失效主因是调试配置错误：Package path须填./cmd/xxx（不可省略./或写main.go），Run kind选Package时需确保唯一main()，dlv必须加--continue和--accept-multiclient参数，条件断点仅支持len()等有限表达式，且需先验证请求是否真正抵达服务端。
GoLand 里对微服务（尤其是 RPC 类型）打的断点进不去，大概率不是代码问题，而是调试模式没对上、dlv 启动参数漏了关键项，或者服务入口路径填错了。
Run Configuration 的 Package path 必须指向含 main() 的包
微服务项目通常按 cmd/xxx 拆分，比如 cmd/openim-api 或 cmd/openim-rpc。GoLand 不认 main.go 文件路径，也不接受空值或 ./ 这种模糊写法。
- 正确填法是：
./cmd/openim-api（注意开头的./，不能少） - 如果填成
cmd/openim-api/main.go，GoLand 会静默降级为 Run 模式，断点完全不生效 - 选 Run kind 为
Package时，必须确保该包下有且仅有一个func main()；若目录下有多个main包（比如同时存在api和rpc），会报错或行为异常
RPC 服务远程调试必须带 --continue 参数
RPC 服务（如基于 net/rpc 或 gRPC 的微服务）启动后需立即监听端口并接受连接。如果用 dlv debug 启动但没加 --continue，dlv 会在入口函数第一行暂停，服务根本没起来，自然收不到任何调用，断点也永远等不到触发。
- 容器内正确命令示例：
dlv debug --headless --listen=:40000 --api-version=2 --accept-multiclient --continue - 漏掉
--continue：服务卡在main()开头，HTTP/gRPC 端口不监听，客户端请求超时 -
--accept-multiclient也关键：否则 GoLand 连一次就断，第二次调试直接失败
条件断点别写 len() 或方法调用
RPC 请求体常是结构体指针（如 *Args），想按字段过滤断点时，Delve 表达式引擎限制很死。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 能用：
args.A > 100、req.Method == "Arith.Divide"、len(req.Header) > 0（len是少数被支持的内置函数） - 不能用：
strings.Contains(req.Method, "Divide")（不支持标准库函数）、req.String()（不支持方法调用）、user.ID := 123（不支持短变量声明） - 验证是否生效：右键断点 → Edit breakpoint → 勾选
Log message to console+Remove once hit；只要控制台打出日志，说明条件已解析成功
RPC 客户端调用不到服务端？先确认端口和协议是否对得上
常见“断点不动”其实是请求压根没发到服务端。RPC 不像 HTTP 有明确 URL，很容易因地址、协议、服务名拼错导致静默失败。
- 检查服务端监听地址：是
0.0.0.0:3000还是127.0.0.1:3000？容器内用后者会导致外部客户端连不上 - gRPC 客户端 Dial 地址要带
http://或https://前缀吗？不带；但必须匹配服务端开启的协议（如insecure模式下用127.0.0.1:50051，不能写成localhost:50051——DNS 解析可能失败） - 服务注册名是否大小写敏感？
rpc.RegisterName("Arith", new(Arith))和客户端调用"arith.Divide"就不匹配
微服务调试最耗时间的地方，往往不在断点本身，而在「请求到底有没有真正抵达服务进程」。建议先用 telnet 或 grpcurl 直连服务端端口确认可通，再开调试；否则容易在错误假设上浪费半小时。
