应显式指定--headless --listen=:40000 --api-version=2 --accept-multiclient --continue，工作目录设为含go.mod的模块根目录，Program path填具体入口如cmd/api/main.go，避免端口冲突和路径解析错误。
运行配置里怎么填 dlv 启动参数才不卡住？
直接在 GoLand 的 Run Configuration 里填 dlv debug 常见失败：进程启动后立刻退出，或监听端口但 Goland 连不上。根本原因是 dlv debug 默认会 attach 到当前目录的 main.go，而微服务项目往往有多个 cmd/xxx/main.go 入口，且依赖 go.mod 路径解析。
正确做法是显式指定入口和工作目录：
- Program arguments 填：
--headless --listen=:40000 --api-version=2 --accept-multiclient --continue - Working directory 设为服务模块根目录（含
go.mod） - Go tool arguments 留空（别加
-gcflags等，会干扰 dlv 符号加载） - 如果入口不在
main.go，比如是cmd/api/main.go，就在 Program path 里填完整路径：cmd/api/main.go
多个微服务共用一个 dlv 端口会冲突吗？
会。Goland 默认用 :40000，但所有服务都绑这个端口会导致第二个启动失败，报错 listen tcp :40000: bind: address already in use。
解决方式不是“换端口”那么简单——端口只是表象，关键在于隔离调试上下文：
- 每个服务的 Run Configuration 必须设不同
--listen地址，例如--listen=:40001、--listen=:40002 - 对应 Goland 的 Remote Debug 配置里，Host 和 Port 也要同步改
- 更稳妥的做法：用
localhost:0让系统自动分配空闲端口（dlv支持），再从日志里复制实际端口连 Goland - 别在容器里复用同一 host 网络命名空间跑多个 dlv —— 容器间端口不冲突，但宿主机上 Goland 连的是 Docker host 映射端口，仍需区分
为什么改了代码，dlv debug 不生效？
常见现象：修改了 handler 函数，断点打进去还是旧逻辑。这不是 Goland 缓存问题，而是 dlv debug 模式默认不重建二进制，它直接编译并运行当前源码，但若项目用了 go.work 或多模块，dlv 可能读错了依赖版本。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
必须检查三处：
- Run Configuration 的 “Go modules” 设置是否勾选了
Enable Go modules integration—— 不勾选时dlv会忽略go.mod，走 GOPATH 模式 - 确认当前打开的项目根目录就是
go.mod所在目录，否则dlv解析replace或require会出错 - 如果用了
go.work，Goland 2025.2+ 才原生支持；旧版需手动在 Run Configuration 的 Environment variables 加GOWORK=../go.work
调试时 goroutine 泄漏，dlv 能看到哪些真实线索？
单纯看 Goroutines 标签页里的数量没用。真正有用的现场信息藏在 dlv 的交互命令里，而 Goland 默认不暴露这些。
在断点暂停后，打开 Goland 的 “Debug Tool Window” → “Console”，输入：
goroutines -u
这会列出所有用户代码启动的 goroutine（过滤掉 runtime 内部协程）。再配合：
-
goroutine <id> bt</id>查看某协程栈帧，确认是否卡在select{}或未关闭 channel -
ps看当前所有 goroutine 状态，重点关注chan receive和IO wait - 别依赖 “Break on panic” 自动触发——有些泄漏是静默增长，得主动查
微服务联调时 goroutine 数量波动大，重点不是总数，而是每次请求后是否残留新协程。这点容易被忽略，直到内存持续上涨才意识到问题。
