go.work 是显式声明的本地开发上下文，需置于所有模块最近公共父目录，use 路径须为相对路径且不能重叠，命令须在根目录执行或指定 -workfile，子模块 replace 会覆盖工作区配置，CI/CD 不启用工作区。
超大型 Golang 单体工程撑不住了，别硬扛——它本质不是“大”，而是“散”；分布式编译集群不是银弹，但能切掉 70% 的重复构建等待时间。
go.work 怎么组织才能让几十个子模块不互相污染
单体工程一旦超过 20+ 子模块，go mod 默认的单模块模式就会频繁报 cannot load 或 ambiguous import。根本原因是 Go 工具链在单模块视角下无法同时解析多个 go.mod 的依赖冲突。
-
go.work不是“替代go.mod”，而是提供一个工作区视图：每个子模块必须自带合法go.mod（含正确module声明和go版本），go.work只负责把它们拉进同一上下文 -
use指令只接受目录路径，不支持通配符；路径不能重叠（比如use ./pkg和use ./pkg/auth会冲突） - 运行
go run或go test时，当前工作目录若在某个子模块内，且该模块不在go.work的use列表中，Go 会退回到单模块模式——本地修改不生效，CI 构建结果和本地不一致 - 验证是否生效：执行
go list -m all -work，输出应包含所有use目录下的模块，而非仅当前目录的
分布式编译集群用 Bazel 还是自研？
Go 官方不提供分布式编译原生支持，Bazel 是目前唯一成熟、可落地的选择；自研成本高、维护难，且容易在增量构建和 cache 失效上翻车。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Bazel 的
remote_cache+remote_execution能把go build的中间对象（如.a文件）和最终二进制分发到多节点并行编译，实测 50+ 包的项目，冷构建从 6 分钟降到 1.8 分钟 - 关键配置项：
--remote_cache=grpc://build-cache.example.com必须启用 TLS；--remote_executor=grpc://build-executor.example.com的 executor 需预装完全一致的 Go 版本（包括 patch 版本，如go1.21.6） - 禁止在
WORKSPACE里用http_archive直接拉 Go SDK；改用rules_go的go_register_toolchains+go_download_sdk，否则不同节点 Go 版本微小差异会导致 cache miss - Go 的
//:go_default_library规则对internal/路径敏感，跨模块引用时需显式声明visibility，否则 Bazel 会静默跳过编译
vendor 目录在超大单体里要不要开
开 vendor 是反模式，尤其在 go.work 环境下——它制造虚假隔离，反而放大模块间依赖版本不一致的风险。
立即学习“go语言免费学习笔记（深入）”；
- 每个子模块的
go.mod应显式require共享依赖的统一版本（如golang.org/x/net v0.23.0），由go.work统一解析，而非各自go mod vendor - CI 流水线里禁用
go build -mod=vendor；改为go build -mod=readonly，强制校验go.sum，避免本地go mod vendor后忘记提交导致构建漂移 - 真正需要 vendor 的场景极少：仅限离线构建环境，且必须配合
go mod verify在流水线末尾校验所有vendor/内容与go.sum严格一致
为什么 go list -m all 在 CI 里总漏模块
因为默认不读 go.work——这是最常被忽略的点。CI 脚本里写 go list -m all，实际只看到当前目录的 go.mod，而 go.work 下其他模块全被忽略。
- 必须加
-work标志：go list -m all -work才能列出完整工作区视图 - GitLab CI 或 GitHub Actions 中，确保
go.work文件被检出且路径正确；如果用actions/checkout@v4，默认已支持 - 输出结果中，模块路径带
// indirect后缀的，说明它未被任何use目录直接require，只是传递依赖——这类模块在重构时最容易成为“幽灵依赖”，建议定期清理
