go work init 初始化失败因目录无合法模块根；需先为子项目运行 go mod init，再在无 go.mod 的工作区根目录执行，路径含空格时加 ./ 前缀。
go work init 初始化失败：找不到模块或路径错误
执行 go work init 时提示 no modules found 或 invalid module path，不是因为你没写 go.mod，而是它只认当前目录下已存在的、合法的模块根目录（即含 go.mod 文件的目录）。它不会递归扫描子目录，也不会帮你生成 go.mod。
- 先确保每个子项目都已独立运行过
go mod init example.com/foo，生成自己的go.mod -
go work init必须在**工作区根目录**执行，且该目录下不能有go.mod（否则会被当成单模块项目） - 如果子模块路径含空格或特殊字符（如
my-project-v2），go work init ./my-project-v2要加./前缀，否则可能解析失败 - windows 下路径分隔符不用转义，但 PowerShell 里变量插值（如
$dir）要小心引号包裹，否则空格会导致参数截断
go work use 添加模块后 go build 不生效
运行 go work use ./backend ./frontend 成功，但 go build ./cmd/api 仍报错找不到本地依赖，说明工作区未被识别——根本原因是当前 shell 没加载 go.work 文件。
- 检查当前目录是否存在
go.work文件；不存在则go work init没成功，别跳过上一步 - 确认没在子模块目录里执行命令：工作区命令（如
go run、go test）必须在go.work所在目录或其子目录下运行 -
go env GOWORK应返回off或具体路径；若返回空，说明 Go 没启用工作区支持（低于 1.18 或环境异常） - ide（如 VS Code + Go extension）需重启才能感知新
go.work，否则代码跳转和自动补全仍走单模块逻辑
replace 指令在 go.work 和 go.mod 中冲突怎么办
当 go.mod 里写了 replace example.com/lib => ../lib，又在 go.work 里用 use ./lib，Go 会优先采用 go.work 的路径，replace 被忽略。这不是 bug，是设计行为：工作区层级高于模块层级。
- 多模块协作时，删掉各
go.mod中的replace，统一由go.work管理本地依赖关系 - 如果某个模块需临时覆盖（比如调试 fork 分支），改用
go work use /path/to/forked-lib，而非在go.mod写replace -
go list -m all可验证实际加载路径：本地模块应显示为example.com/lib v0.0.0-00010101000000-000000000000 => ./lib，箭头右边是相对路径 - CI 环境通常不启用工作区（
GOWORK=off），所以replace不能全删，建议保留但注释掉，并在 README 里说明工作区优先级
go work vendor 不可用：没有 vendor 命令
go work vendor 是无效命令，Go 工作区本身不支持集中 vendoring。每个模块仍需单独执行 go mod vendor，且 vendor/ 目录只对本模块生效。
- 工作区不改变模块的依赖解析逻辑，只是把多个
go.mod“并联”起来，vendor 仍是模块粒度的 - 如果想统一管理第三方依赖版本，用
go.work的use配合go mod edit -replace锁定版本，比 vendor 更轻量 - CI 构建时避免
go work，直接进各模块目录跑go build；否则 vendor 缓存可能错乱（尤其 GOPROXY 开启时） - 注意
go mod vendor不会拉取go.work中use的本地模块内容到vendor/，那些仍是源码链接
工作区不是“超级模块”，它不合并 go.mod，也不改变 Go 的模块加载本质。最容易被忽略的是：你得始终清楚自己在哪一层操作——是模块内、工作区内，还是完全脱离两者。跨层混用命令（比如在工作区根目录跑 go mod tidy）会静默失败，连错误都不报。