Bazel中正确配置Go需显式加载rules_go、注册匹配版本的toolchain、每个规则指定importpath；cgo需声明、gazelle需配置vendor/testdata支持；项目根须有BUILD.bazel设构建边界；交叉编译须用--platforms而非环境变量。
Go规则在Bazel里怎么写才不报错
Bazel对Go的支持靠rules_go，不是原生的——这意味着你得显式加载、声明依赖、匹配SDK版本。常见错误是直接抄示例却忽略go_sdk路径或 gazelle生成规则不更新。
-
WORKSPACE里必须用go_register_toolchains()注册工具链，且版本要和本地go version输出一致（比如go1.22.0就得配go_version = "1.22.0"） - 每个
go_library或go_binary都得显式写importpath，不能靠目录推断；它对应Go的import语句，拼错就找不到包 - 如果项目有
cgo，得额外加cgo = True，否则编译时静默跳过C部分，运行时报undefined reference
gazelle自动生成BUILD文件总漏掉vendor或testdata
gazelle默认只扫.go文件，vendor目录被忽略是设计行为，不是bug；testdata同理——它认为测试数据不属于构建图。
- 运行
gazelle update -from_root=.前，先在WORKSPACE里给gazelle加配置：gazelle_dependencies()+gazelle_config规则，指定build_file_name = ["BUILD.bazel", "BUILD"] - 要包含
vendor/，得在gazelle命令后加-external vendored，并确保go mod vendor已执行 -
testdata/这类目录若含.go文件（比如内嵌测试用的fake server），需手动在对应BUILD.bazel里加go_library(srcs = ["testdata/xxx.go"])，gazelle不会自动处理
为什么bazel build //...会编译整个GOPATH而不是当前模块
Bazel不认go.mod的作用域，它只看BUILD.bazel文件分布。如果你没在项目根目录放BUILD.bazel，或者子目录里缺规则，Bazel就会向上递归找，直到/，结果把系统级GOPATH下的东西也拉进来。
- 必须在项目最外层
go.mod所在目录放一个空的BUILD.bazel（内容可仅为load("@io_bazel_rules_go//go:def.bzl", "go_library")），作为构建边界 - 所有子包都要有
BUILD.bazel，哪怕只是go_library(name = "go_default_library", srcs = glob(["*.go"]))；没有就等于“这个目录不参与构建”，Bazel会继续往外找 - 用
bazel query //...先确认实际纳入构建的包范围，比盲目build更安全
交叉编译GOOS/GOARCH失效或产出二进制无法运行
Bazel的Go交叉编译靠toolchain切换，不是改环境变量。设GOOS=linux GOARCH=arm64 bazel build完全没用，Bazel根本不读这些。
- 正确做法是用
--platforms=//platforms:linux_arm64，其中//platforms:linux_arm64是自定义平台定义，需提前在platforms/BUILD.bazel里声明constraint_value和platform - 必须配合
rules_go的go_toolchain支持对应平台，否则报错No matching toolchain found；检查go_register_toolchains(go_version = "...")是否启用了多平台 - 生成的二进制默认是静态链接，但若用了
net包且cgo开启，仍可能动态依赖libc——这时要在go_binary里加gc_linkopts = ["-linkmode=external", "-extldflags=-static"]
Go的importpath和Bazel的包路径容易错位，尤其当项目从go get迁移到Bazel时；别信IDE自动补全的路径，用bazel query 'kind(go_library, //...)' --output=build看Bazel实际解析出的导入名。
