type t u 定义新类型，有独立方法集且需显式转换；type t = u 是零开销别名，完全等价、不可加方法、反射不体现。
type T U 和 type T = U 的根本区别在哪
前者是定义新类型，后者才是真·别名。go 编译器把 type Res http.ResponseWriter 当作一个独立类型（哪怕右边是接口），而 type Res = http.ResponseWriter 则完全等价于原类型——连反射里 reflect.typeof() 都不显示 Res，只显示 http.ResponseWriter。
- 新类型（
type T U）有自己的方法集、可加新方法、不能直接赋值给U（除非显式转换或满足接口） - 别名（
type T = U）零开销、无运行时痕迹、可直接互换、无法添加方法（编译报错） - 接口场景下容易误判：因为
type Res http.ResponseWriter看似“能用”，其实是靠接口兼容性撑着，不是类型等价
什么时候必须用 type T = U 而不是 type T U
当你需要跨包迁移、简化函数签名、或保持值可直接传递时，= 是唯一选择。比如把旧包的 pkg/v1.User 迁移到 pkg/v2.User，老代码不想改 import，就在 v1 里写 type User = v2.User —— 这样所有字段、方法、json.Marshal 行为全一致。
- 函数类型别名：
type HandlerFunc = func(http.ResponseWriter, *http.Request)，这样你还能直接传http.HandlerFunc(f) - 嵌套泛型容器：
type EventChan[T any] = chan T，避免每次写chan map[String][]*T - 重构过渡期：别名能让你在不破坏调用方的前提下，悄悄替换底层实现
- 用
type T U做这事？不行——调用方会立刻报cannot use ... as ... value in argument
为什么 type Res response.Response 编译失败，而 type Res http.ResponseWriter 却能过
因为 http.ResponseWriter 是接口，response.Response 很可能是结构体。Go 对接口和结构体的类型兼容规则完全不同：接口看方法集是否满足，结构体看类型是否同一（distinct）。
-
type Res http.ResponseWriter→ 新类型但方法集为空且与原接口一致 → 所有实现该接口的值（如*http.response）可隐式赋值 -
type Res response.Response→response.Response若是 Struct，则Res是全新 distinct 类型 → 即使字段一模一样，也不能Res{...} = response.Response{...}，必须强制转换：Res(r) - 常见错误现象：
cannot use w (type http.ResponseWriter) as type Res in argument to handler，说明你误以为结构体也能像接口那样“自动适配”
别名不能加方法，但自定义类型可以——这到底是优势还是陷阱
这是 Go 类型系统有意为之的设计取舍：别名就是“换个名字”，不许动；自定义类型才允许封装行为。但很多人踩坑在于——本想加方法增强语义，却用了 =，结果编译报错 cannot define new methods on non-local type 或直接不允许声明。
立即学习“go语言免费学习笔记（深入）”；
- 想封装
http.ResponseWriter并加SetStatus()方法？必须用type Res struct { http.ResponseWriter; statusCode int }或type Res http.ResponseWriter+ 显式方法接收者（注意：后者只能为指针接收者，且不能用于接口值） - 用
type Res = http.ResponseWriter？加方法直接报错，语法禁止 - 性能影响为零，但语义表达能力天差地别：别名适合“命名即解释”，自定义类型适合“命名即契约”
最容易被忽略的一点：类型别名在 go vet、gopls、甚至调试器里都“不存在”，它只活在源码中。而自定义类型会留下完整的类型元数据——这意味着，如果你依赖反射做动态类型判断，或者用 Interface{} 做泛化处理，二者行为会截然不同。