goland启动多个独立进程需为每个实例创建独立run configuration：复制配置并命名（如worker-01/02），在program arguments中传入不同--node-id参数，统一设置redis_addr环境变量，启动后可在services窗口观察并行进程、独立断点调试。
GoLand里怎么启动多个独立进程
GoLand本身不直接支持“一个进程fork出另一个进程”的调试跟踪，它面向的是每个main函数对应一个独立可执行入口。所谓“多进程调试”，实际是同时运行多个独立的 Go 程序实例（比如 worker-01、worker-02），它们各自有完整的进程 ID、内存空间和调试上下文。
关键不是写exec.Command或os.StartProcess，而是为每个进程建一份独立的 Run Configuration：
- 在
Run | Edit Configurations…中点击左上角+→ 选择Go Build - 给配置起名，如
worker-01；Run kind选Directory或指定具体main.go - 在
Program arguments里填入区分标识，例如--node-id=worker-01 - 确保所有配置共用同一套外部依赖地址，比如
REDIS_ADDR=localhost:6379（设在Environment variables） - 重复上述步骤，新建
worker-02配置，仅改--node-id和日志输出路径（可选）
这样启动后，Services 工具窗口会显示两个并列进程，各自可单独断点、暂停、终止，互不干扰。
为什么不能只靠 go run + flag 在单配置里切换
你可以在一个配置里传不同 --node-id 参数，但那只是“反复运行同一个二进制”，本质仍是单进程串行执行。分布式场景下真正要验证的是：两个进程是否同时持有锁、是否因时序竞争漏触发、Redis 分布式锁是否被正确争抢释放。
单配置反复运行完全无法暴露这些问题，因为：
- 前一次进程退出后，锁已被释放，后一次启动是干净状态
- 没有真实的时间交叠，channel 或 mutex 的竞态不会出现
- 日志混在同一个控制台，难以区分谁发了什么、谁收到了什么
- 无法观察两个进程对共享资源（如 Redis key TTL、Mongo 文档版本号）的实时读写冲突
所以必须让它们“活在一起”——同时 running，各自独立调试会话。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
Services窗口里看到多个进程但调试断点不生效
常见原因是 Delve 启动参数或构建方式导致调试符号缺失。尤其当你用 go run 调试时，默认编译参数可能跳过调试信息生成。
务必检查以下三点：
- Run Configuration 的
Run kind推荐选Package或显式指定main.go，避免用Directory导致自动识别错入口 - 在
Go tool arguments中加入-gcflags="-N -l"（注意是小写 L，不是数字 1），强制保留符号表和禁用内联 - 确认项目启用 Go Modules（Settings → Go → Go Modules → 勾选
Enable Go modules integration），否则go build可能走 GOPATH 模式，Delve 解析失败
如果仍不生效，右键 Services 中的进程 → Debug，而不是从编辑器侧边栏点 ▶️ —— 后者容易复用旧临时配置，忽略你刚改的参数。
调试中 goroutine 列表为空或只显示 runtime.main
这不是代码问题，是 GoLand UI 默认折叠了并发视图。必须手动开启 goroutine 监控：
- 进入 Debug 窗口，点击右上角
Show Goroutines按钮（图标是两个交错圆圈），或按快捷键Ctrl+Shift+G（Windows/Linux）/Cmd+Shift+G（Mac） - 开启后，左侧
Frames面板顶部会出现Goroutines标签页，列出所有活跃 goroutine - 若仍为空，检查 Delve 是否以 API v2 启动：在 Run Configuration 的
Go tool arguments加--api-version=2
特别注意：goroutine 名字不可靠，判断哪个是 worker 进程的关键，是看调用栈第二层函数名（第一层永远是 runtime.goexit），以及鼠标悬停时显示的启动位置（如 main.go:87）。
多进程调试真正的难点不在配置，而在于你得主动放弃“单机逻辑正确即全局正确”的直觉。两个进程之间没有共享内存，一切协调都靠外部存储的瞬时状态，而那个状态，在你单步调试时早已变化。所以别只盯着断点停在哪，多看 Variables 面板里的 Redis key 值、channel len、mutex.state 字段——它们才是分布式真相的唯一信源。
