结论：用go work管理多模块项目需靠go.work文件统一声明本地模块，执行go work use ./module-a ./module-b并确保在go.work根目录运行命令，否则go run仍按单模块规则解析依赖。
直接说结论：用 go work 管理多个本地模块项目，不是靠改 go.mod 或硬塞 replace，而是靠一个 go.work 文件统一声明哪些模块参与协同开发。
go work init 后 go run 找不到本地模块？
这是最常踩的坑：执行了 go work init ./module-a ./module-b，但 go run main.go 仍报错找不到 module-b 的包。
- 根本原因：
go work只影响 Go 工具链的模块解析逻辑，它不自动修改任何go.mod文件，也不自动把 import 路径映射到本地目录 - 必须手动运行
go work use ./module-a ./module-b（路径必须是含go.mod的目录） - 确认当前目录下生成了
go.work文件，且内容里有对应use行 - 别在子模块目录里单独
go run—— 必须在go.work所在的根目录下执行命令，否则 Workspace 模式根本不生效 - 检查
GOFLAGS是否设了-mod=readonly，它会阻止go自动更新依赖，导致 workspace 里的模块无法被识别
什么时候该写 replace，什么时候只用 use？
use 是声明“我正在本地开发这些模块”，replace 是强制重定向某个 import 路径。两者用途不同，混用容易出问题。
- 如果模块 A 的
go.mod里压根没require模块 B，只是代码里写了import "example.com/b"，那仅go work use ./b就够了 —— Go 会自动把该 import 解析到 workspace 中的./b - 如果模块 A 的
go.mod已require example.com/b v0.1.0，但你本地改的是./b，就得在go.work里加replace example.com/b => ./b -
go.work里的replace优先级高于模块自身go.mod里的replace，所以别在两个地方重复写 - 多数日常开发场景只需
use；replace仅用于“已有远程依赖声明但尚未发布”的过渡阶段
go build 报 “main module does not contain package” 怎么办？
这不是代码问题，是 workspace 路径错位导致的典型错误。
立即学习“go语言免费学习笔记（深入）”；
- 先运行
go work edit -print，如果报no work file found，说明你不在 workspace 根目录，或者当前目录下没有go.work文件 - Go 不会向上递归找
go.work，只认当前工作目录下的文件 —— 切换到go.work所在目录再执行命令 - 别用
go build ./批量构建多个模块 —— workspace 不支持跨模块通配符构建；要么进每个模块目录分别go build，要么用go run启动主入口 - CI/CD 脚本里不要假设 workspace 存在；上线构建应退回到单模块模式，用
go build -mod=mod或go mod vendor
真正容易被忽略的是：workspace 是“运行时上下文”，不是项目结构约束。同一个 go.work 可以随时增删 use 目录，也可以临时注释掉某行来隔离调试，但它对 IDE、linter、test 工具的支持程度不一 —— 比如某些老版本 VS Code Go 插件可能不识别 go.work，得手动 reload window 或升级插件。
