go.work不该直接提交到Git，因其含个人路径易致协作失败；应提供setup-workspace.sh等脚本生成，且所有use路径须为./开头的相对路径。
go.work 文件本身不参与 Git 协作同步，但模块路径和 replace 规则必须团队对齐，否则本地构建会失败。
go.work 该不该提交到 Git？
不该直接提交原始 go.work，但需提供可复现的生成方式。它不是配置文件，而是开发时态的“工作快照”——路径可能含个人绝对路径（比如 ~/dev/myproj/core），硬提交会导致别人 go work init 失败或静默跳过模块。
- 推荐做法：在项目根目录放一个
setup-workspace.sh或Makefile，内容为go work init ./api ./core ./cli && go work use ./api ./core ./cli - CI/CD 脚本里禁止依赖
go.work—— 构建应退回到单模块模式，用go build -mod=mod+ 显式GO111MODULE=on - 如果必须提交
go.work，确保所有use路径是相对路径（如./api），且不含~或/home/xxx
团队成员执行 go work use 后，为什么别人 go run 还报 missing module？
因为 go work use 只改当前机器的 go.work，不自动同步到他人环境，也不触发 go.mod 更新。更关键的是：即使路径一致，go run 在子目录下执行时根本不会加载 go.work。
- 必须统一在 workspace 根目录运行命令，例如
go run ./api/cmd/server，而不是进./api后执行go run main.go - 检查
go env GO111MODULE输出是否为on；若为auto或off，go.work完全无效 - 运行
go work edit -print确认当前目录下能读到go.work内容，否则说明不在 workspace 根目录
replace 指令在 go.work 里写错路径，会有什么后果？
会直接导致 go build 报错 replace directive must not be absolute，且错误信息里不提示哪一行出问题 —— Go 工具链只校验语法，不校验路径是否存在。
立即学习“go语言免费学习笔记（深入）”；
-
replace的路径必须以./开头，且相对于go.work所在目录，例如replace example.com/core => ./core - 不能写成
replace example.com/core => /Users/you/project/core或replace example.com/core => ../core - 如果被替换的模块还没加进
use列表，go build仍会尝试拉远程版本，报missing module——use和replace是两套独立机制，缺一不可
最易被忽略的一点：IDE（如 VS Code）默认不重载 go.work，改完后必须手动点击 “Reload Window” 或执行 gopls restart，否则代码跳转、补全、诊断全按旧规则走。
