type T U 是新类型声明，生成独立类型元数据并可添加方法；type T = U 是别名，运行时完全等价且不可加方法。
type T U 和 type T = U 的行为完全不同
Go 里 type Res http.ResponseWriter 和 type Res = http.ResponseWriter 看似只差一个等号，但编译器处理方式天差地别：前者是**新类型声明**，后者才是**真·别名**。别名在运行时完全消失，连 reflect.TypeOf() 都不认它；而新类型会生成独立的 runtime._type 元数据，调试器里能看见、类型断言会失败、方法也能单独加。
-
type Res = http.ResponseWriter：赋值、传参、断言全畅通，Res就是http.ResponseWriter，只是换个名字写代码 -
type Res http.ResponseWriter：哪怕右边是接口，也得靠“方法集一致”才能隐式赋值；一旦你给Res加个Log()方法，它立刻和原接口不兼容 - 结构体场景更严格：
type User struct{...}和type Admin User是两个类型，字段一模一样也不行，必须显式转换Admin(u)
什么时候能直接赋值？看右边是不是接口 + 方法集是否一致
很多人以为 “type T U 右边是接口就能随便转”，其实只对了一半——前提是 T 没额外定义任何方法。Go 允许接口到接口的隐式赋值，仅当二者方法集完全相同。
- ✅ 合法：
type Res http.ResponseWriter（空定义）→var w Res = httpResponsePtr，因为Res方法集 =http.ResponseWriter方法集 - ❌ 非法：
type Res http.ResponseWriter再加func (r Res) Log() {...}→ 此时Res方法集变大，不能再接*http.response - ❌ 结构体永远非法：
type Res response.Response（假设response.Response是 struct）→Res{}和response.Response{}类型不互通，连==都报错
反射和调试时，它们根本不是一回事
用 reflect.TypeOf() 或调试器看变量类型，是区分别名和定义最直观的方式。别名不会出现在反射结果里，而新类型会以独立名称出现——这点直接影响日志、序列化、泛型约束等实际场景。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
type MyInt = int→reflect.TypeOf(MyInt(5))返回int，不是MyInt -
type MyInt int→reflect.TypeOf(MyInt(5))返回MyInt，且reflect.ValueOf(...).Kind()是Int，但Name()是"MyInt" - 泛型约束中若写
type Number interface{~int | ~float64}，MyInt int能匹配，MyInt = int也能，但行为差异藏在方法绑定和接口实现里
别名不能加方法，定义可以——这是最常踩的坑
想给某个类型封装一层逻辑，下意识写 type ReqID = string，然后想加个 Validate() 方法？编译直接报错：cannot define new methods on non-local type string。因为别名不能加方法，只有新类型才可以。
立即学习“go语言免费学习笔记（深入）”；
- 要加方法 → 必须用
type ReqID string（新类型），再写func (r ReqID) Validate() bool { ... } - 只想换名省打字 → 用
type ReqID = string（别名），但别碰方法，也别指望它在 debug 里显示为ReqID - 混用风险高：有人先用别名，后来想加方法，改成定义后所有调用点都得补类型转换，尤其在 HTTP handler 或 JSON 解析这种边界处容易漏
