go work init后go mod tidy不生效，因go work与go mod机制独立：go mod tidy仅作用于当前目录的go.mod，需进入各子模块目录分别执行；go work仅注册模块路径，不自动触发依赖同步。
go work init 之后为什么 go mod tidy 不生效
因为 go work 和 go mod 是两套独立但有优先级关系的机制：go work 定义的是「当前工作区包含哪些模块」，而 go mod tidy 只作用于当前目录下的单个模块（即它找到的最近的 go.mod）。如果你在工作区根目录执行 go mod tidy，它不会自动遍历所有 replace 进来的模块去拉依赖。
- 必须先进入某个子模块目录（比如
./user-service），再运行go mod tidy，它才会按该模块自己的go.mod处理依赖 -
go work use ./user-service ./auth-lib只是把路径注册进go.work，不触发任何依赖下载或校验 - 想批量同步所有模块的依赖，得写个小脚本循环进入每个路径执行
go mod tidy
本地 replace 被误提交到 Git 的坑怎么避开
以前靠手动改 go.mod 里的 replace，一不留神就 git add . 进去了。用 go work 后，replace 指令完全从 go.mod 中移除，全部挪到独立的 go.work 文件里——而这个文件默认**不被 Go 工具链上传或共享**，天然规避了污染仓库的问题。
-
go.work文件默认不纳入版本控制（就像.env），你可以在项目根目录加一行go.work到.gitignore - 团队协作时，让每个成员各自运行
go work use ./path/to/local/module，路径是本地相对路径，不会冲突 - CI 环境不需要
go.work，直接走go mod download拉远端 tag，行为一致
VSCode 中如何让多模块跳转和补全正常工作
VSCode 的 Go 插件（gopls）从 Go 1.18 起原生支持 go.work，但前提是它得“看到”这个文件。如果打开的是单个模块文件夹（比如只打开了 ./api），gopls 就不知道旁边还有 ./pkg 模块，跳转会失败。
- 必须用 VSCode 打开整个工作区根目录（即包含
go.work的那个文件夹），而不是某个子模块目录 - 确认状态栏右下角显示 “Go (workspace)” 而不是 “Go (module)”，否则说明
gopls没识别到工作区 - 如果仍不生效，重启
gopls：命令面板输入 “Go: Restart Language Server”
跨模块调试时 main 包找不到依赖怎么办
常见报错：cannot load github.com/your-org/pkg: module github.com/your-org/pkg@latest found, but does not contain package github.com/your-org/pkg。这不是路径问题，而是 Go 工具链没把工作区里的模块当成本地源码来编译。
- 确保
go.work文件里用的是相对路径（如./pkg），不是绝对路径（/home/user/project/pkg）——后者在别人机器上必然失效 - 运行调试前，先在终端里执行
go work use ./pkg，再用 VSCode 的 Debug 面板启动（不要直接点 ▶️ 运行单个.go文件） - VSCode 的
launch.json中，program字段要指向具体模块的main.go，且工作目录（cwd）设为该模块根目录
replace 的老路。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
