go.work与replace是不同层级机制：前者用于多模块协同开发且replace必须用./开头的相对路径，后者仅作用于单个模块；二者不可混用，否则导致构建失败、ide报红、ci失效。
Go 工作区（go.work）和 replace 是两套不同层级的机制，不能混用或“联通”——前者用于多模块协同开发（跨多个独立 go.mod 项目），后者仅作用于单个模块内的依赖重定向。强行把二者拉通，反而会导致构建失败、IDE 报红、CI 失效。
go.work 中的 replace 必须用 ./ 开头的相对路径
很多人试图在 go.work 文件里写 replace github.com/user/core => /home/user/project/core，结果 go build 直接报错：replace directive must not be absolute。Go 明确禁止绝对路径。
-
go.work的replace只接受以./开头的相对路径，且该路径必须相对于go.work所在目录 - 例如
go.work在~/myproject/go.work，则合法写法只有：replace github.com/user/core => ./core - 如果本地模块实际在
../shared/core，不能直接写../shared/core——Go 不支持跨父目录引用；要么软链进当前工作区根目录，要么调整结构 - 这个
replace是全局生效的，会影响所有被go work use加入的模块，不是某个go.mod的局部行为
go.mod 中的 replace 不会被 go.work 自动继承
你在子模块 ./api/go.mod 里写了 replace example.com/utils => ../utils，但执行 go run ./api 时它可能根本没生效——因为 go.work 模式下，go 命令会忽略子模块里的 replace，只认 go.work 文件中声明的规则。
-
go.work中的replace优先级高于任何go.mod里的同名规则 - 如果你既想用工作区，又想保留子模块自己的
replace（比如调试一个临时 fork），唯一办法是：不启用go.work，退回到单模块模式，用go mod edit -replace+go mod tidy管理 - 验证是否被覆盖：运行
go list -m -f '{{.Replace}}' example.com/utils，输出为空或不是你预期的路径，说明被go.work屏蔽了
go run/test 默认不读取 go.work，除非显式指定
这是最隐蔽的坑：你在 ./api 目录下敲 go run main.go，它完全无视 go.work，也不会加载里面定义的 replace 或 use 路径——它只按传统方式解析 ./api/go.mod。
- 正确做法是始终在工作区根目录执行命令：
go run ./api或go test ./core - 如果非要在子目录操作，必须加
-workfile参数：go run -workfile ../go.work ./main.go（注意路径是相对于当前目录） -
go list -m all是唯一快速验证当前是否处于工作区模式的方式：输出中出现v0.0.0-00010101000000-000000000000 => ./core这类带箭头和本地路径的行，才算真正生效
真正难处理的不是语法，而是路径语义的混淆：go.work 的 replace 是模块地址到文件系统路径的映射，而 go.mod 的 replace 是模块地址到另一模块地址的映射——两者粒度、作用域、生效时机完全不同。混用前，先问清楚：你要解决的是「多个独立模块协同开发」，还是「单个项目临时调试一个依赖」？选错机制，后面全是静默失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
