replace不能替代接口废弃策略，因其仅修改路径不改变语义，无法解决调用方仍用已废弃接口的问题；真正平滑废弃需接口层设计+渐进迁移，replace仅用于最终验证阶段。
replace 不能替代接口废弃策略
直接用 replace 把旧模块替换成新模块，无法解决“调用方还在用已废弃接口”这个根本问题。Go 没有运行时接口弃用机制，replace 只改路径不改语义——如果新模块删了旧方法、改了函数签名或返回类型，老代码会直接编译失败，而不是友好提示。
真正平滑废弃，必须靠接口层设计+渐进迁移，replace 最多只在最后阶段辅助验证。
用 type 别名做零感知过渡
当你要把 github.com/old/pkg.User 迁移到 github.com/new/id.User，且希望所有现有 import "github.com/old/pkg" 代码无需修改，就用别名：
// github.com/old/pkg/go.mod module github.com/old/pkg go 1.21 // github.com/old/pkg/user.go package pkg import "github.com/new/id" // ✅ 关键：type User = id.User（等号，不是 struct 定义） type User = id.User
这样所有已有代码继续调用 User.String()、User.ID 等，行为完全不变；而新功能可直接在 github.com/new/id 中迭代，旧包只保留别名和文档说明。
- 别名不产生新类型，方法集、接口实现、反射结果全部继承自
id.User - 不能写成
type User id.User（这是新类型，会断掉所有方法） - 旧包的
go.mod里必须require github.com/new/id v1.2.0，否则构建失败
配合 deprecated 注释 + linter 检查
在旧接口定义处加 // Deprecated: use github.com/new/id.User instead，再用 revive 或 staticcheck 配合规则自动报错：
// github.com/old/pkg/user.go
// Deprecated: use github.com/new/id.User instead
type LegacyUser struct {
ID int64
}
配置 .revive.toml 启用 deprecated 规则，CI 中跑 revive -config .revive.toml ./...，就能拦截新代码继续使用 LegacyUser。
- Go 自身不校验
Deprecated注释，必须依赖外部 linter - 注释必须紧贴类型/函数声明上方，空行会失效
- 不要只写“已废弃”，要明确指向替代项，否则开发者无从下手
replace 仅用于最终验证阶段
等 90% 以上代码完成迁移后，才在主项目的 go.mod 中临时加一行：
replace github.com/old/pkg => github.com/new/id v1.2.0
然后跑 go mod tidy && go test ./...。如果还有编译错误，说明残留调用没清理干净——这不是 replace 的问题，而是迁移未完成。
- 这条
replace必须在 PR 合并前删除，绝不能进主干分支 - 它不会让
LegacyUser复活，只会让github.com/old/pkg的导入实际加载github.com/new/id的代码 - 若新模块没有导出同名符号（如漏了
type User = ...），这里会立刻暴露缺失
最易被忽略的是：别名必须在旧模块中定义，而不是在调用方或新模块里；一旦旧模块被 replace 掉，别名就没了，整个迁移链就断了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
