必须在go.work所在目录执行命令，否则工作区不生效；go work init生成空go.work文件，go work use需用相对于go.work的路径（如./module_a），禁用../或绝对路径，且须在根目录运行go build/go run，子模块内执行将无视工作区。
必须在 go.work 所在目录执行命令，否则工作区不生效——这是 90% 的人踩坑的起点。
go work init 和 go work use 怎么用才对
初始化工作区只需一步：go work init，它会在当前目录生成空的 go.work 文件。但注意：它不会自动识别子模块，必须显式添加。
添加模块用 go work use ./module_a ./module_b，路径必须是相对于 go.work 文件的相对路径（不能含 ../，也不能是绝对路径）。常见错误包括：
- 执行
go work use ../lib→ 命令静默忽略，不报错也不生效 - 在子模块目录里运行
go work use→ 工具链找不到go.work，直接失败 - 路径拼错（比如少个
.）→go build仍报 “module xxx is not in main module”
为什么 go build 还报 “module is not in main module”
根本不是配置没写对，而是你没在正确位置执行命令。Go 工作区模式只在 go.work 所在目录及其子目录下生效，且仅当命令由该目录发起时，工具链才读取 go.work 中的 use 列表。
典型错误操作：
-
cd service_a && go run .→ 退回到单模块模式，go.work被无视 -
go run ./service_a（在工作区根目录执行）→ 正确，工具链能解析所有use路径
另外，检查每个子模块的 go.mod：只要存在 replace 指向本地路径，它就会优先于 go.work 生效，必须手动删掉。
go.work 文件结构和 replace 写法差异
go.work 是纯声明式配置，结构简单：
go 1.22
use (
./service_a
./utils
)
replace github.com/some/dep => ./local-dep
注意两点：
-
use只接受本地模块路径，不能写版本号；replace在go.work中用于覆盖远程依赖（比如调试第三方库），和go.mod里的replace语义一致，但作用域更高 - CI/CD 流水线完全不读
go.work，所以它只该存在于本地开发环境，不该提交到 git（除非团队明确约定共享工作区结构）
最易被忽略的一点：IDE（VS Code / GoLand）不会自动感知 go.work 变更，改完文件后必须重启 Go 扩展或整个编辑器，否则代码跳转、补全、诊断全失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
