go工作区（go.work）不实现物理依赖隔离，仅协调开发时模块解析与编辑体验；依赖仍全局共享于$gomodcache，各模块实际加载路径由自身go.mod中的replace等指令决定。
go work init 后依赖下载仍全局共享，不是项目级隔离
Go 工作区（go.work）本身不创建独立的模块缓存目录，所有加入工作区的模块仍共用同一份 $GOMODCACHE（通常是 $HOME/go/pkg/mod）。所谓“隔离”仅体现在开发时的模块解析路径和编辑体验（如 VS Code 跨模块跳转），而非缓存物理分离。你执行 go mod download 或构建任一模块，下载的包都会进同一个缓存池。
真正影响依赖行为的是 go.mod + replace，不是工作区结构
工作区不会改变每个模块自身的 go.mod 解析逻辑。如果你在 service-a 的 go.mod 里写了 replace github.com/xxx/log => ./internal/log，那 service-a 构建时就绕过远程下载，直接用本地路径；而 service-b 没写这条 replace，它依然会去拉远程版本——这个差异由各自 go.mod 决定，跟 go.work 无关。
-
go.work只协调go list -m all、go mod tidy等命令的模块可见范围，不影响go build时实际加载的源码位置 - 想让某模块强制用本地代码？必须在它自己的
go.mod里加replace，不能只靠go work use - 工作区里两个模块引用同一第三方库的不同版本（比如 v1.2.0 和 v1.3.0），Go 会按最小版本选择（MVS）统一选一个，除非用
require显式锁定
缓存污染或版本冲突时，别只 clean -modcache
单纯运行 go clean -modcache 会清空所有模块缓存，但无法解决工作区下因 replace 或 exclude 导致的解析不一致问题。更常见的坑是：
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 某个模块的
go.sum被手动改过，而工作区其他模块依赖它——go mod download会卡在 checksum mismatch，且错误提示不指明是哪个模块出问题 - 本地
replace指向的路径里有未提交的修改，CI 构建时因路径不存在直接失败 - 执行
go work use ./a ./b后，又在./a目录下单独跑go mod tidy，可能把工作区外的依赖写进a/go.mod，破坏一致性
排查时优先用 go list -m -u all 查版本冲突，再用 go mod graph | grep xxx 定位具体模块来源。
离线构建前必须验证：go mod download all 是否真覆盖全部
工作区场景下，go mod download all 仍只基于当前工作区根目录执行，它会下载 go.work 中所有模块的 go.list -m all 输出项。但容易漏掉：
- 被
replace到私有 Git 地址（如git.company.com/internal/lib）的模块，若没配GOPROXY=direct，下载会失败 - cgo 依赖的 C 头文件或静态库不在 Go 模块体系内，
go mod download完全不感知 - 某些 build tag 分支下的间接依赖（比如
// +build linux）可能不会出现在go list -m all结果里
最稳妥的做法：进每个模块子目录，分别跑 go mod download，再统一打包 $GOMODCACHE。工作区省的是编辑体验，不是缓存管理逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
