goland默认不索引外部依赖源码，需手动将vendor/或replace本地路径添加为content root并标记为sources才能支持跳转定义等功能。
GoLand 不会自动索引外部依赖的源码
默认情况下，GoLand 只索引你项目目录下的代码（./...），而 go.mod 中 require 的第三方模块（比如 github.com/gin-gonic/gin）是通过 $GOPATH/pkg/mod 缓存的二进制包或只读源码，IDE 默认不为其建立完整语义索引——这意味着跳转定义、查找引用、重命名等操作可能失效或延迟，尤其在离线、私有模块或 replace 本地路径后更明显。
强制 GoLand 索引 vendor/ 或本地 replace 模块
真正起作用的方式不是“重建全局索引”，而是让 IDE 明确知道哪些外部路径需要纳入索引范围。关键操作有两步：
- 确保依赖已落地为可读源码：若用了
go mod vendor，确认vendor/目录存在且非空；若用了replace指向本地路径（如replace github.com/user/lib => ../lib），确认../lib下有合法的go.mod文件 - 在 GoLand 设置中手动添加源码根目录：Settings → Directories → Add Content Root，然后选择
vendor/或你的本地 replace 路径（如../lib） - 添加后，GoLand 会将其标记为 “Sources”（而非 “Excluded”），随后触发增量索引；等待右下角提示 “Indexing completed” 即可
注意：go mod vendor 生成的 vendor/ 默认不被 GoLand 自动识别为源码根，必须手动添加；而 replace 的本地路径即使存在，IDE 也不会自动发现，必须显式加入 Content Root。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
为什么 go list -m all 正常但跳转仍失败
常见现象：命令行能查到模块版本（go list -m all | grep xxx），但在 GoLand 里 Ctrl+Click 却跳不到源码，或提示 “Cannot find declaration to go to”。这不是缓存问题，而是索引范围缺失：
- GoLand 的跳转依赖符号表（symbol table），而符号表只构建于被标记为 “Sources” 的目录内
-
$GOPATH/pkg/mod下的模块默认是 “Library” 类型，仅提供基础类型信息，不支持深度重构或跨文件引用分析 - 如果你用
replace指向本地路径但没加 Content Root，IDE 仍按原模块名去pkg/mod找，结果当然找不到——它根本没去看你本地的../lib - 验证是否生效：打开任意一个使用该依赖的
.go文件，把光标停在 import 名上，按 Ctrl+Click；若成功跳转到本地../lib中的文件，说明索引已生效
CI 构建和本地开发索引不一致怎么办
团队协作中容易忽略一点：GoLand 的 Content Root 是项目级配置（保存在 .idea/misc.xml），但不会随 go.mod 或 vendor/ 自动同步。这意味着：
- 别人 clone 项目后，即使有
vendor/，也不会自动索引——必须各自手动添加一次 - CI 流水线不依赖 GoLand 索引，所以不影响构建，但本地开发体验割裂
- 推荐做法：在项目根目录放一个简短的
SETUP.md，写明 “首次打开需在 Settings → Directories 中添加 vendor/ 为 Content Root” - 避免用绝对路径添加 Content Root（如
/home/you/project/vendor），否则提交后破坏他人环境
真正麻烦的不是怎么加，而是加完之后忘了删——尤其 replace 临时调试完切回远程版本时，Content Root 还留着旧路径，IDE 会持续尝试索引一个已不存在的目录，拖慢启动和编辑响应速度。
