go.work文件必须放在所有协同模块的共同父目录下，如新建my-go-workspace文件夹，将各模块作为子目录放入，并在此目录执行go work init；不能置于单个module内、家目录或空文件夹中。
go.work 文件该放在哪一级目录
工作区根目录必须是所有要协同开发的模块的共同父目录，不能放在某个 module 内部，也不能放在用户家目录或任意空文件夹里。否则 go 命令压根不会识别它。
- 正确做法：新建一个空文件夹（比如
my-go-workspace），把多个模块作为子目录放进去，再在该空文件夹下执行go work init - 常见错误：在
~/projects/myapp下直接运行go work init，结果只绑定了这一个模块，其他模块不在同级就加不进来 - 路径层级影响
go run和go test的模块解析顺序——工作区启用后，go会优先从go.work列出的本地模块找依赖，而不是拉go.mod里写的版本
go work use 后为什么 go build 还报 missing module
go work use 只是把模块路径写进 go.work，但不会自动同步 replace 或修正已有模块的 require 版本。如果被依赖模块的 go.mod 里还写着旧版本号，go build 仍会尝试下载远程版本，导致失败。
- 必须手动检查并清理被依赖模块中的
require example.com/lib v1.2.0—— 如果你本地有lib模块，就删掉这行，或改成replace example.com/lib => ./lib（但用go work时这行 replace 实际上多余） - 运行
go work use ./lib后，立刻执行go mod tidy在主模块里，否则缓存可能没刷新 - 注意
go.work不影响GO111MODULE=off环境，务必确认当前 shell 是 module 模式（go env GO111MODULE输出on）
多模块间循环依赖时 go work 会静默失败
Go Workspaces 本身不检测或阻止循环引用。一旦模块 A require B，B 又 require A（哪怕通过间接依赖），go build 会卡住或报错 import cycle not allowed，但错误信息里完全不会提 go.work 的事，容易误判为代码问题。
- 排查方式：临时注释掉
go.work，改用replace手动绑定，看是否还报循环；如果不再报，说明是工作区让依赖图变复杂了 - 真实场景常见于工具库和 CLI 主程序互相引用命令定义、配置结构体——建议把共享类型抽成第三个独立模块，由 A/B 同时
require它 -
go list -deps ./...可视化依赖链，但要注意它默认只看当前模块，加-work参数才能纳入工作区全部模块
CI/CD 流水线里要不要提交 go.work
不要提交 go.work 到 Git。它本质是本地开发协调文件，内容含绝对路径（Windows/macOS/Linux 不兼容）、临时调试模块、甚至未 commit 的分支代码，CI 环境无法复现，且 Go 官方明确说它“not intended for version control”。
立即学习“go语言免费学习笔记（深入）”；
- CI 中应始终用
go mod download && go build走标准模块流程，靠go.mod锁死版本 - 如果 CI 需要同时构建多个模块，用脚本依次
cd进每个模块执行go build，比强塞工作区更稳定 - 团队内可通过文档约定工作区目录结构（如统一用
workspace/），但具体go.work由每人自建——这点和.gitignore类似，规则重要，文件本身不用共享
真正麻烦的是跨模块测试时的 init() 执行顺序和 flag.Parse() 冲突，这个得靠重构入口逻辑来解，go.work 帮不上忙。
