bazel与goland集成需确保workspace存在、importpath与模块路径严格对齐、go_register_toolchains版本匹配go.mod，否则ide索引与构建结果失联。
Bazel不是GoLand的默认构建后端，强行配置容易卡在“找不到BUILD文件”或“go_library importpath不匹配”上，尤其当项目已有go.mod且混用vendor时——GoLand本身不校验Bazel规则语义，只做路径映射，出错后IDE里看不到真实错误源头。
GoLand识别Bazel项目的关键检查点
GoLand不会自动扫描WORKSPACE或解析BUILD.bazel内容。它依赖你手动指定Bazel工作区根目录，并要求该目录下存在合法的WORKSPACE文件（哪怕内容为空）和至少一个BUILD.bazel或BUILD文件。
- 必须把项目根目录设为Bazel workspace root：File → Project Structure → Project Settings → Project → Project SDK → 点击“New…” → 选择“Bazel SDK”，再指定包含
WORKSPACE的目录 - GoLand会尝试读取
go_register_toolchains(version = "...")中的版本，但不会校验它是否与go.mod中声明的go 1.22一致——这个不一致会导致编译通过、运行时panic - 如果项目含多个
go_library，GoLand仅能索引到importpath字段声明的包路径；若该值写成"foo/bar"而实际代码里写import "example.com/foo/bar"，IDE里会标红“unresolved reference”，但Bazel build却可能成功
go_library的importpath必须和模块路径对齐
这是GoLand+Bazel协作中最隐蔽的断点。GoLand靠importpath建立符号跳转链，Bazel靠它做依赖解析，两者不一致就直接失联。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
importpath不是别名，是唯一标识：若模块路径是github.com/myorg/myproject，所有go_library的importpath必须以该前缀开头，例如"github.com/myorg/myproject/internal/db" - 不能省略模块名写成
"internal/db"，否则GoLand无法定位到对应源码，Bazel也不会把该target加入依赖图 - 子模块（如
github.com/myorg/myproject/v2）需显式声明importpath = "github.com/myorg/myproject/v2"，且go.mod中必须有对应module github.com/myorg/myproject/v2
Bazel缓存与GoLand索引冲突的典型表现
GoLand的“Rebuild project”本质是调用bazel build //...并解析输出，但它的索引缓存不感知Bazel的沙箱路径（如bazel-out/k8-fastbuild/bin/...），导致“跳转到定义”失效或显示过期代码。
- 执行
bazel clean --expunge后，必须在GoLand中触发“File → Reload project from disk”，否则IDE仍用旧索引 - 修改
go_library的srcs列表后，GoLand不会自动触发Bazel rebuild——需手动右键目标→“Bazel → Build Target”，否则跳转仍指向被删掉的文件 - 启用
--remote_http_cache时，GoLand无法获取远程缓存中的源码映射关系，此时“Find Usages”可能漏掉跨workspace的引用
真正麻烦的从来不是配置步骤，而是当go_binary能跑通、GoLand里却标红一堆import时，你得同时盯住WORKSPACE里的go_repository声明、BUILD.bazel里的importpath、go.mod的module行、以及GoLand的Project SDK设置——四者只要有一处脱节，问题就藏在最深的那层抽象之下。
