goland识别多module项目需手动标记每个含go.mod的子目录为go module，启用“enable replace directives”并禁用自动检测，确保模块列表完整、路径映射一致。
GoLand 里怎么识别并加载多 module 项目
GoLand 默认只认当前目录下的 go.mod，如果项目是多 module 结构（比如每个 service 目录下都有自己的 go.mod），它不会自动发现子模块。你得手动告诉它哪些是有效 module。
操作很简单：打开项目根目录后，右键点击任意一个含 go.mod 的子目录（比如 service/user），选 “Mark Directory as → Go Module”。重复这个动作，把所有 service、pkg、shared 等独立 module 都标上。标完之后，GoLand 才会为每个 module 单独解析依赖、提供跳转和补全。
常见错误现象：cannot find package "myproject/shared" —— 这不是代码写错了，而是 GoLand 根本没把 shared 当成 module，所以不索引它的导出符号。
- 别在根目录建
go.mod，除非你真打算把它当主 module；否则容易污染子 module 的依赖解析 - 如果用了
go.work，GoLand 2024.3+ 版本能自动识别，但老版本仍需手动标记 module - 标记后检查 Project Tool Window 左上角的 “Go Modules” 标签页，确认所有 module 都列出来了
replace 指令在 GoLand 里为啥不生效
replace 是本地开发时绕过远程版本、直连本地路径的关键手段，但 GoLand 不会自动应用它——它只管索引，不管构建时的依赖替换逻辑。你得让 IDE 和 Go 工具链对齐。
确保两点：一是 go.mod 里写了 replace shared => ../shared；二是 GoLand 的 Go 设置里启用了 “Use GOPATH that is defined in system environment” 或明确设置了 GOPATH。更重要的是，在 Settings → Go → Build Tags & Vendoring 中勾选 “Enable replace directives”。
不勾这个选项，GoLand 就当 replace 不存在，依然按 require 声明的版本去索引，结果就是跳转到旧版代码、类型提示错乱、甚至单元测试跑不通。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
replace只在本地开发阶段有效，CI/CD 构建前必须删掉或注释掉，否则发布版本会出问题 - 多个
replace指向同一路径时，GoLand 可能只认第一个，建议保持一一对应 - 如果用
go.work，就不用写replace，但 GoLand 必须加载了工作区才能识别路径映射
团队成员打开同一个多 module 项目，为什么补全和跳转不一致
根本原因在于 GoLand 的 module 索引是本地缓存的，而不同人可能标记了不同的目录、用了不同 Go 版本、甚至开了不同插件。最典型的就是有人漏标 internal/utils 模块，导致别人能跳转的函数，在他机器上显示 “unresolved reference”。
解决办法不是靠口头约定，而是固化配置：
- 在项目根目录放一个
.idea/modules.xml（提交进 Git），里面记录了哪些目录被标记为 Go Module - 统一要求所有人开启
go.work支持（如果项目用了），并在 README 里写明初始化命令：go work init ./service/user ./service/order ./pkg/shared - 禁用 “Auto-detect modules from go.mod files” 选项，避免 IDE 自作主张覆盖团队约定
另外，internal 包的访问限制是编译器级的，但 GoLand 的静态分析有时会误报“imported and not used”，这不是 bug，而是它还没完全适配多 module 下的 visibility 规则 —— 遇到这种提示，先运行 go build 确认是否真报错，再决定是否忽略。
调试跨 service 调用时，断点进不去 remote module
比如你在 service/user 里调用 shared/auth 的函数，打了断点却跳过——大概率是因为 GoLand 没把 shared 的源码加进调试符号路径。
调试前必须做两件事：一是在 Run Configuration 的 “Go tool arguments” 里加上 -gcflags="all=-N -l" 关闭优化；二是在 “Working directory” 里设成当前 service 的根目录（比如 service/user），而不是项目根目录。否则 GoLand 会尝试从根路径找 shared 的源码，而实际它在上层目录。
- 如果
shared是通过replace引入的，确保它的路径是相对且可访问的（比如../shared，不是../../libs/shared） - GoLand 的 “Attach to Process” 模式对多 module 支持有限，优先用 “Run” 或 “Debug” 启动单个 service
- gRPC 调用链里的断点，需要在 client 和 server 两端都启用调试，且保证 proto 文件生成的 stub 在各自 module 里正确引用
多 module 项目的麻烦不在语法，而在工具链一致性。GoLand 能帮你省事，但前提是它知道你想要什么——不是靠猜，而是靠显式声明、统一配置、以及每次拉代码后花 30 秒检查 modules 列表是否完整。
