go.work文件必须置于所有模块的共同父目录下，如myworkspace，并在该目录执行go work init；若放错位置或未运行go mod tidy，go run仍会报missing module或忽略本地修改。
go.work 文件不是“一建就灵”的配置，它只在你明确处于工作区根目录下、且所有模块路径都正确相对时才生效；否则 go run 仍会报 missing module 或直接忽略本地修改。
go.work 文件必须放在共同父目录下，不能放错位置
工作区不是全局开关，go 命令只会在当前目录或其任意上级目录中查找 go.work 文件，并且只认“第一个找到的”。如果你把 go.work 放在某个子模块内部（比如 ./service/go.work），它完全无效。
- 正确做法：新建空文件夹（如
myworkspace），把./service、./client、./shared全部作为同级子目录放进去，再在myworkspace/下运行go work init - 常见错误：在
~/projects/myapp目录下直接执行go work init ./service，结果go.work生成了，但./client不在同级，后续go work use ./client会失败或被忽略 - 验证是否生效：在
myworkspace/下执行go work use -r ./，然后看go.work里是否列出全部模块路径；再执行go list -m all，应看到所有本地模块而非远程版本号
go work use 后必须手动 tidy，否则依赖不会更新
go work use ./shared 只是把路径写进 go.work，它不改任何 go.mod，也不刷新模块缓存。如果你的 ./service/go.mod 里还写着 require example.com/shared v0.1.0，go build 依然会去拉远程 v0.1.0，而不是用你本地的 ./shared。
- 必须立刻在主模块（比如
./service）目录下运行go mod tidy，它会自动删掉那行require，并把本地路径识别为“已提供” - 如果 tidy 报错 “no required module provides package”，说明
./shared的go.mod模块路径（module example.com/shared）和./service中 import 的路径不一致，要统一 - 别依赖
replace：工作区模式下replace是冗余甚至冲突的，删掉go.mod里的所有replace行
vscode-go 依赖 gopls，需确认 workspace 状态栏显示正常
VS Code 里光有 go.work 不够，gopls 必须加载成功并识别到工作区，否则跳转、补全还是只认单个模块。
- 打开命令面板（
Ctrl+Shift+P），运行Go: Restart Language Server，强制重载 - 看 VS Code 窗口右下角状态栏：应显示类似
Workspace: service+shared (go1.21)，而不是Module: service - 如果显示 Module，说明
gopls没读到go.work—— 检查是否在myworkspace/根目录下打开整个文件夹（不是只打开./service子文件夹） -
.vscode/settings.json中无需额外配置，但确保没写"go.useLanguageServer": false
最容易被忽略的是：工作区对循环依赖完全静默——A 依赖 B，B 又依赖 A，go build 直接卡住或报 import cycle not allowed，但错误里绝不会提 go.work 一字。遇到构建挂起或奇怪 import 错误，先检查模块间是否形成了环路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
