模块依赖不是重构工具而是约束条件，go.mod仅记录依赖关系，重构由模块边界重新定义驱动；replace用于灰度解耦，vendor锁定临时依赖状态，模块名变更需同步更新所有import路径及外部require。
模块依赖不是重构工具，而是重构的约束条件
Go 的 go.mod 本身不提供重构能力，它只记录和约束依赖关系。真正驱动系统重构的是你对模块边界的重新定义——而 go mod tidy、go get 和 replace 指令，只是帮你验证、隔离和渐进落地这些新边界。
用 replace 实现模块解耦的灰度迁移
当老系统里 pkg/user 和 pkg/order 高度耦合，又不能一次性拆出独立模块时，replace 是最稳妥的过渡手段：
- 先把
pkg/user复制为新模块github.com/yourorg/user-service，保留原有接口但重写实现 - 在主项目的
go.mod中添加：replace github.com/yourorg/user-service => ./internal/user-service
- 逐步把调用方从
import "your-old-repo/pkg/user"改为import "github.com/yourorg/user-service" - 每次
go build都会强制走本地路径，避免误发版或依赖冲突
注意：replace 不影响 go list -m all 输出，但会绕过 proxy 和 checksum 校验——上线前必须删掉 replace 行并 go mod tidy 验证真实依赖树。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
go mod vendor 不是为打包，是为锁定重构过程中的临时依赖状态
重构期间频繁切换分支、回退、并行开发，vendor 能防止因 go.sum 变动导致的构建漂移：
- 执行
go mod vendor后，所有依赖源码固化在./vendor目录 -
go build -mod=vendor会忽略go.mod中的require，只读vendor - 适合 CI 流水线中跑重构验证测试：确保某次提交所见即所得，不被远程模块更新干扰
- 但不要长期启用
-mod=vendor，尤其在replace场景下，它会忽略replace指向的本地路径
模块名变更后，旧 import 路径仍可工作，但别依赖它
Go 允许模块名（module 声明）与代码实际路径不一致，比如把 github.com/old/repo 改成 github.com/new/user-core，只要旧 import 路径没变，编译仍通过——但这只是兼容性假象：
- 其他项目若
require你的旧模块名，就会拉错版本或失败 -
go list -u -m all会报find newer versions of modules，提示你已脱离语义化版本轨道 - 真正安全的做法是：同步改模块名 + 所有内部 import 路径 + 更新所有外部
require行
重构中最容易被忽略的，是那些藏在测试文件、mock 工具、CI 脚本里的硬编码 import 路径——它们不会报错，但会让模块升级失效或导致 panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
