import别名只是包引用的本地代号，不能改变类型系统；真正实现平滑升级需结合接口抽象、新旧包类型兼容及逐步替换。
为什么 import 别名不是“重命名”，而是接口适配的起点
Go 中的包别名（如 import http "net/http"）本身不改变类型或方法签名，它只是给包起个本地代号。真正支撑平滑升级的是：你用别名隔离旧包引用，再通过新包实现相同接口，最后逐步替换。否则别名只是换了个名字报错而已。
常见错误现象：cannot use myClient (type *oldhttp.Client) as type *newhttp.Client in argument——类型不兼容，别名没用。
- 别名只影响当前文件的包引用路径，不影响类型系统
- 必须确保新旧包导出的结构体/接口有可互换的字段和方法集（哪怕只是鸭子类型）
- 如果旧包类型被直接嵌入（如
type MyServer struct { *oldhttp.ServeMux }），升级时需同步改写嵌入项
如何用别名 + 接口抽象过渡 github.com/go-sql-driver/mysql 到 github.com/marlow/funnel
假设你原来用 mysql 驱动，现在想试水更轻量的 funnel，但又不能停服改全量。关键是把具体驱动从代码里“拔出来”。
使用场景：数据库初始化、连接池配置、sql.Open 调用点。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先定义统一接口：
type DBProvider interface { Open(string) (*sql.DB, error) } - 旧驱动封装：
type MySQLProvider struct{}实现Open时调sql.Open("mysql", dsn) - 新驱动封装：
type FunnelProvider struct{}实现Open时调sql.Open("funnel", dsn)（注意驱动名可能不同） - 在 main 包里用别名控制加载：
import _ "github.com/go-sql-driver/mysql"和import _ "github.com/marlow/funnel"都要保留，否则sql.Open找不到驱动
go mod replace 和包别名混用时的典型陷阱
你想用 replace 把旧包指向本地修改版，同时用别名避免冲突——但 Go 会按模块路径解析，不是按别名。
错误现象：undefined: oldpkg.DoSomething，明明写了 import oldpkg "github.com/legacy/pkg"，却提示找不到。
-
replace修改的是模块路径映射，别名只是源码层面的引用缩写，两者不耦合 - 如果
replace指向一个结构不同的本地目录，而你又依赖原包的导出符号，编译失败是必然的 - 别名无法绕过
go.mod中的版本约束；若旧包 v1.2 被 replace 到本地，但新代码用了 v2.0 的 API，别名也救不了 - 验证方式：运行
go list -m all | grep legacy，确认实际加载的模块路径和版本
当旧包类型被深度嵌入时，别名无法解决的硬升级点
比如你有 type Logger struct { *log.Logger }，而新日志库不提供 *log.Logger，只提供 zerolog.Logger。这时别名连门都进不去。
性能影响：强行包装（如加一层 Logf 方法转发）会增加函数调用开销，高频日志场景明显。
- 必须提取最小契约接口（如
interface{ Printf(string, ...interface{}) }），而非依赖具体结构体 - 旧代码中所有
l.Logger.Printf(...)需改为l.Printf(...)，别名帮不上忙 - 如果旧包类型出现在公开 API 签名里（如函数返回
*oldlog.Logger），升级就必须 breaking change 或加版本前缀（如v2.Logger）
最常被忽略的是测试代码里的类型断言：assert.IsType(t, &oldlog.Logger{}, actual)——这种断言在切换后必炸，且不容易被 CI 捕获。
