go work init 后 go run 找不到本地微服务模块，是因为它仅创建空 go.work 文件，未自动纳入模块；必须显式执行 go work use 指定含 go.mod 的目录，并确保 import 路径与 module 声明完全一致。
go work init 之后为什么 go run 还找不到本地微服务模块
因为 go work init 只创建空的 go.work 文件，不自动把任何模块纳入工作区。Go 工具链仍按单模块逻辑走，从 go.mod 的 require 里拉远程版本，完全无视你本地改的 service-auth 或 service-order。
- 必须显式执行
go work use ./service-auth ./service-order ./shared-utils（路径需指向含go.mod的目录） - 确认当前 shell 在 workspace 根目录（不是子模块里），且
go.work文件存在并可读 - 检查
GOFLAGS是否设了-mod=readonly——它会阻止 Go 自动解析本地 import 到 workspace 模块 - 如果某个服务 A 的
go.mod里写的是github.com/company/auth v0.3.0，但你本地改的是./service-auth，就得在go.work里补一条replace github.com/company/auth => ./service-auth
微服务间 import 路径怎么写才被 go work 正确解析
import 路径必须和模块定义的 module 声明完全一致，不能用相对路径或本地文件系统路径。比如 service-order 的 go.mod 里是 module github.com/company/order，那代码里就得写 import "github.com/company/order"，而不是 import "./service-order" 或 import "../service-order"。
-
go work的作用是“当遇到这个 import 路径时，优先去use列表里的本地路径找”，不是重写 import 语法 - 所有微服务模块的
module名应保持稳定，避免频繁改名；否则go.work里的replace也要同步更新 - 共享库（如
shared-utils）建议用真实域名前缀（github.com/company/utils），而非伪域名（example.com/utils），减少上线前替换成本
CI/CD 流水线里要不要保留 go work
不要。CI/CD 构建阶段应完全忽略 go.work，退回到单模块模式。
- 流水线脚本中显式设置
GOFLAGS="-mod=mod"或直接 unsetGOFLAGS，确保依赖解析不依赖 workspace - 每个微服务单独
cd进对应目录，运行go build -o ./bin/service-x，以各自go.mod为准 -
go.work文件只 commit 到 dev 分支或主干，但 CI 配置里加rm -f go.work更稳妥 - 若用
go mod vendor打包，vendor 目录生成逻辑不受go.work影响，可放心使用
IDE 跳转和补全为什么有时失效
VS Code 的 Go 扩展（v0.42+）和 Goland（2025.1+）支持 go.work，但前提是 workspace 根目录下有有效文件，且 IDE 启动路径就是该根目录。
- 别用 VS Code “Open Folder” 打开某个子模块目录——要打开整个 workspace 根目录
- 重启 IDE 或手动触发 “Go: Restart Language Server” 常能解决刚加完
go work use后的跳转延迟 - 如果
shared-utils被多个服务use，但其中一个服务没声明require github.com/company/utils，IDE 可能报 unresolved import——此时需补上require（哪怕版本号写v0.0.0），go work不替代go.mod的合法性校验
go.mod 仍需保持最小必要 require，go work 不是逃避模块契约的借口。本地开发图省事全靠 use，上线前才发现某服务漏写了对 shared-utils 的 require，导致构建失败。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
