go work init 创建工作区时路径必须存在且含 go.mod：执行前 ./module-a 和 ./module-b 必须已存在且各自根目录下有有效 go.mod；否则静默跳过，导致 go run 仍拉远程版本而非本地代码。
go work init 创建工作区时路径必须存在且含 go.mod
执行 go work init ./module-a ./module-b 前，两个目录必须已存在，且各自根目录下要有有效的 go.mod 文件。如果任一路径缺失 go.mod，命令会静默跳过该路径，不报错但也不写入 go.work —— 导致你以为加进去了，实际没生效。
常见错误现象：go run . 仍报 cannot find module，或依赖未走本地代码而是拉远程版本。
- 验证方式：运行
go work edit -json查看实际加载的模块列表 - 路径必须是相对路径（不能用
~/path或绝对路径），否则go.work中记录无效 - 若模块在子目录（如
./libs/core），需确保core/go.mod存在，且go work use指向的是该目录，不是上层libs
use 和 replace 在 go.work 中的优先级与作用范围
use 指令让工作区把指定目录当作一个独立根模块参与构建；replace 则只替换某个模块的特定版本（或全部版本）为本地路径。两者不互斥，但行为不同：
-
use是“启用本地模块”，只要路径下有go.mod，它就完全接管该模块的解析，无需在各go.mod中写replace -
replace在go.work中写法为replace example.com/lib v1.2.0 => ./local-lib，仅当依赖树中明确请求v1.2.0时才生效；若请求的是v1.3.0或latest，则不触发 -
go.work中的replace优先级高于任何go.mod中的replace，但低于use—— 即如果某模块已被use，它的代码就直接用，不会走replace路径
VS Code + gopls 识别 workspace 需要重启语言服务器
添加新模块到 go.work 后，VS Code 不会自动感知变更。即使你手动保存了文件，gopls 仍可能继续按旧的模块集合提供跳转、补全和类型检查，导致 “找不到符号” 或 “import path not resolved”。
- 必须手动触发：按
Ctrl+Shift+P（macOS 为Cmd+Shift+P），输入Go: Restart Language Server并执行 - 检查是否生效：打开任意
.go文件，在 import 行悬停，看是否显示 “from workspace module” 而非 “from remote module” - 如果项目用了
GOFLAGS=-mod=readonly，gopls可能拒绝加载 workspace，需临时移除该 flag
CI/CD 中应忽略 go.work 文件，但需保留本地开发语义
go.work 是纯本地开发辅助文件，不应提交到 Git —— 它绑定的是开发者机器上的路径，CI 环境无法复现。但忽略它不等于放弃 workspace 语义。
- CI 构建时，应使用标准
go mod download && go build，不依赖go.work - 若 CI 需要模拟多模块联调（如测试主模块对工具模块的兼容性），应在构建前用
go get拉取对应 commit 的工具模块，而非依赖 workspace - 真正容易被忽略的一点：
go.work中的use路径是相对工作区根目录的，而很多团队把 workspace 根设在~/dev/myproject这类非项目仓库路径下 —— 这会导致go.work无法被 IDE 正确定位，除非显式用cd进入该目录再启动编辑器
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
