go.work文件必须显式use有效目录才生效：空文件、仅go work init、通配符或非目录路径均无效；use只接受相对目录路径（如./cmd/api），当前目录未被use时退回到单模块模式，CI中推荐用绝对路径。
go.work 文件必须显式 use 目录才生效
Go 工具链不会自动扫描子目录下的 go.mod，go.work 文件本身也不带“自动发现”能力。空文件、只写 go work init 后没加 use、或用了通配符，都会导致工作区静默失效。
-
go.work必须包含use指令，且只接受**目录路径**（如./cmd/api），不能是./cmd/*、example.com/cmd/api或文件路径 - 当前工作目录若不在任一
use目录内，Go 退回到单模块模式——此时import "example.com/pkg/storage"会报cannot load - CI 中建议用绝对路径生成
go.work，例如use /home/ci/project/pkg/storage，避免因cd路径差异导致解析失败 - 运行
go work use ./pkg/storage比手动编辑更可靠，它会自动校验目录是否含合法go.mod
子模块的 go.mod 必须声明正确 module path
每个子模块的 go.mod 里 module 行写的路径，必须和代码中实际 import 的路径完全一致。不匹配会导致跨模块引用失败，且错误信息模糊（常表现为找不到包或版本冲突）。
- 假设子模块在
./pkg/storage，其go.mod中必须写module example.com/pkg/storage，不能写module ./pkg/storage或留空 - 如果主模块 import 该包时写的是
import "example.com/pkg/storage"，而子模块go.mod声明的是module storage，Go 无法关联二者 -
go list -m all -work是验证工作区视图的唯一权威命令；不加-work仅显示当前模块，容易误判 - 子模块内部若有
replace，不会自动继承到工作区；主模块如需覆盖，必须在自身go.mod中显式require并replace
replace 和 go.work 共存时优先级容易误判
两者作用域不同：replace 是模块级依赖重定向，go.work 是工作区级模块发现机制。混用时，Go 优先走 go.work 的 use 路径，replace 会被忽略——但很多人以为 replace 还在生效。
- 若某模块既在
go.work的use列表里，又在主模块go.mod中被replace指向本地路径，Go 实际使用的是use路径下的代码 - CI 环境禁止用相对路径
replace（如replace example.com/lib => ./lib），因为执行路径不确定；应统一改用file:///abs/path/to/lib或直接删掉，靠go.work管理 - IDE（如 GoLand）默认不读
go.work，需手动开启 “Enable Go Workspaces”，否则跳转、补全、类型检查全部断连 -
go build本身不感知go.work，它只看当前目录的go.mod；真正触发跨模块构建的是go list -m all -work驱动的构建脚本
vendor 在 Monorepo 里基本没用，还可能引入隐患
Monorepo 天然要求各子模块共享依赖上下文，而 vendor 是按模块快照锁死依赖，反而破坏一致性。尤其当多个子模块 vendor 同一依赖的不同 commit 时，运行时行为可能不一致。
立即学习“go语言免费学习笔记（深入）”；
- 启用
go mod vendor后，go build -mod=vendor会绕过go.work，退回到单模块 vendor 视图，跨模块 import 失效 - 不同子模块对同一依赖的
require版本若存在微小差异（如v1.2.3vsv1.2.4），vendor会各自拉取，最终二进制里可能混入两份不兼容的代码 - 真正需要确定性构建的场景（如白盒交付），应靠
go.sum校验 + CI 中固定 Go 版本 +go.work统一解析，而非vendor - 若甲方强制要求离线构建，可导出完整依赖树为 tar 包，而不是每个模块各自
vendor
go.work 是“全局开关”，结果目录没 use、路径写错、或者 IDE 没开工作区支持，改了代码却始终不生效。 
