应使用 go work 而非单个 go.mod 的场景是本地多模块协同开发，如 SDK 与服务联调、单体拆分、开源子模块贡献；需先 go work init 创建空 go.work，再用 go work use 显式添加含 go.mod 的模块路径。
什么时候该用 go work 而不是单个 go.mod
当你同时开发多个相互依赖的 Go 模块，且这些模块尚未发布到公开仓库（比如还在本地迭代、内部灰度、或跨团队联调），go work 就是唯一能绕过「必须推送到远程 + replace 临时覆盖」的干净方案。它不是为单项目服务的，而是为「本地多模块协同验证」而生。
- 你正在写一个 SDK（
github.com/myorg/sdk），同时在另一个服务（github.com/myorg/service）里试用它，但 SDK 还没发 v1.0，也不希望每次改完都go mod tidy && git push - 你在重构一个大单体，正把功能逐步拆成独立模块，需要让它们在本地共存、互相 import、一起
go test - 你参与开源项目贡献，需同时修改主仓库和它依赖的某个子模块（如
golang.org/x/net的某个分支），且要确保主仓库跑得通
go work init 和 go work use 的实际执行顺序
工作区不是靠配置文件驱动的，而是靠命令显式声明哪些模块参与。工作区根目录下生成的 go.work 文件只是记录结果，不能手写维护。
- 先在空目录运行
go work init—— 它只创建空的go.work，不自动发现模块 - 再逐个运行
go work use ./module-a ./module-b—— 它会检查每个路径下是否有go.mod，有才加入；没有就报错 - 如果某个模块后来删了
go.mod，下次go build会直接失败，不会静默忽略
go work init go work use ./sdk ./service ./cli
工作区对 go build 和 go test 的影响范围
启用工作区后，所有 Go 命令默认以工作区为上下文：模块路径解析、依赖版本选择、replace 规则都会被重定向。但它**不改变 GOPATH 或 GOROOT**，也不影响非工作区目录下的命令行为。
- 在工作区根目录或任意子模块内执行
go build，都会统一使用go.work中声明的模块版本，即使某个模块的go.mod里写了require example.com/foo v1.2.3，只要go.work里use了本地./foo，就一定用本地代码 -
go test ./...会跨模块执行测试，但注意：如果模块 A 测试里 import 了模块 B 的私有包（比如github.com/myorg/b/internal），而模块 B 没有导出该路径（即没在go.mod的module行声明），则编译失败 —— 工作区不绕过 Go 的包可见性规则 - 工作区不会自动同步
go.sum；每个模块仍保留自己的go.sum，go work不生成全局校验和文件
容易被忽略的限制和陷阱
工作区不是万能胶。它的设计目标很窄：解决「本地多模块开发时的依赖解析一致性」。超出这个范围，就会遇到边界问题。
立即学习“go语言免费学习笔记（深入）”；
- 无法嵌套工作区：
go work use不接受另一个工作区路径；如果子模块本身也有go.work，会被忽略 - IDE 支持不一致：VS Code Go 插件默认识别工作区，但某些老版本或自定义构建脚本可能仍按单模块逻辑处理，导致跳转/补全错乱
-
go install默认不走工作区：除非显式指定-workfile参数，否则安装命令仍基于当前模块的go.mod - CI 环境通常禁用工作区：因为
go.work是本地开发产物，不应提交到仓库；CI 应该用标准go mod流程验证最终发布状态
replace + 频繁 git commit 的泥潭里解放出来。但它要求你始终清楚：哪些模块被 use 了、哪些路径实际可 import、以及工作区生命周期是否该随 PR 结束而销毁。 
