go work init 必须在统一管理所有模块的父目录执行，而非子模块内；否则生成的go.work仅对该子模块生效，无法联动其他模块。
go work init 必须在项目根目录执行
工作区模式不是全局开关，而是以 go.work 文件所在目录为作用域。如果你在子模块里运行 go work init，生成的文件只对该子模块生效，无法联动其他模块。
- 正确做法：cd 到你希望统一管理所有模块的父目录（比如
my-monorepo/），再执行go work init ./service-a ./lib-b ./pkg/util -
go.work文件一旦生成，就不要手动移动或复制——它的路径是相对基准，移动后use路径全部失效 - IDE（如 GoLand）会自动识别
go.work，但 VS Code 需要确保打开的是该目录，而不是某个子模块目录
go build 报 “module xxx is not in main module” 怎么修
这不是 bug，是 Go 工具链严格区分「模块上下文」和「工作区上下文」的结果。错误发生在你在子模块目录里执行了 go build，此时 Go 只读取该模块自身的 go.mod，完全无视 go.work。
- 必须回到
go.work所在目录执行构建命令：go build ./service-a/cmd/...或go run ./service-a/cmd/main.go - 检查
go.work里的use路径是否拼错，比如写成use ./service_a（下划线）但实际目录是service-a（短横线） - 如果某个子模块的
go.mod里还留着replace example.com/lib => ./../lib，删掉它——go work use和replace冲突时，replace优先，工作区直接被绕过
本地模块互相引用时 replace 和 use 到底选哪个
开发阶段一律用 go work use，不用 replace。两者不是互补，而是互斥；且 use 是工作区级、静态路径、一次声明全量生效，replace 是模块级、易漂移、维护成本高。
-
replace写在go.mod里，只影响当前模块；改一个路径，所有引用它的模块都要同步改go.mod -
go work use ./lib是相对于go.work的固定路径，只要目录结构不变，A 改了代码，B 就能立刻看到，无需任何额外操作 -
go work use不支持./libs/*这类通配符，每个模块必须显式列出，看似麻烦，实则是防止隐式依赖蔓延
CI/CD 流水线里能不能直接用 go work
不能。标准 Go 工具链（包括 go test、go list、golangci-lint）在非工作区上下文中完全忽略 go.work 文件。CI 环境默认不激活工作区模式。
- CI 中应还原为传统模块模式：删除
go.work，用replace指向本地路径，或提前发布版本并require正式 tag - 可在 CI 前加校验脚本：grep -q "replace.*=>" **/go.mod && echo "ERROR: local replace found" && exit 1，防误提交
- 真正需要多模块协同测试的场景，建议用
go test ./...在工作区根目录跑，但仅限本地验证，CI 仍走单模块发布流程
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
