type Res = http.ResponseWriter 是别名，零成本兼容；type Res response.Response 是新类型，字段相同也不兼容，因Go严格区分类型身份。
type Res http.ResponseWriter 能用，但 type Res response.Response 报错，为什么？
因为 http.ResponseWriter 是接口，而 response.Response 很可能是结构体——Go 对这两类类型的兼容规则完全不同。
- 接口类型定义新类型（
type Res http.ResponseWriter）时，只要方法集一致（它没加新方法），就允许所有满足该接口的值隐式赋值过去；*http.response满足http.ResponseWriter，自然也满足Res - 结构体类型定义新类型（
type Res response.Response）时，哪怕字段一模一样、甚至完全空，Res{}和response.Response{}仍是两个 distinct 类型，不能直接赋值，必须写Res(r)强转 - 常见错误现象：
cannot use w (type http.ResponseWriter) as type Res in argument to handler—— 这说明你误以为“长得像就能互换”，但 Go 不看字段，只看类型身份
什么时候必须用 type T = U，而不是 type T U？
当你需要「零成本替换」且「调用方完全无感」时，= 是唯一选择；否则用 type T U 会立刻破坏兼容性。
- 跨包迁移：旧包
v1.User想 alias 到新包v2.User，就写type User = v2.User；老代码照常 importv1、用v1.User，连json.Marshal行为都一模一样 - 函数签名简化：
type HandlerFunc = func(http.ResponseWriter, *http.Request)，这样你可以直接传http.HandlerFunc(f)或普通闭包，而type HandlerFunc func(...)会断掉所有已有赋值 - 泛型容器可读性：
type EventChan[T any] = chan T，避免每次写chan map[string][]*T这种嵌套；别名不增加运行时开销，编译期全展开 - 别名不能加方法——这不是限制，是设计意图：它本就不该有独立行为，只是换个名字
自定义类型（type T U）能加方法，但别名（type T = U）不能，这到底是优势还是陷阱？
这是明确的分工：要封装行为就用新类型，要复用语义就用别名。混用才是陷阱。
- 新类型
type MyInt int可以绑定func (m MyInt) Double() int，也能实现特定接口（比如fmt.Stringer），适合构建领域模型 - 别名
type MyInt = int在reflect.TypeOf()里根本不会出现，调试器里也看不到它——它只是源码里的“笔名”，编译后彻底消失 - 容易踩的坑：想给
type Status string加个.IsValid()方法，却误写成type Status = string，结果编译报错cannot define new methods on non-local type string - 另一个坑：用
type Res = http.ResponseWriter后又试图在同包里给Res加方法，Go 直接拒绝——别名没有方法集，也不归你管
如何一眼判断该用 = 还是不用 =？
问自己一句：这个“新名字”之后，是否还需要和原类型**完全互换、无缝传递、不改任何调用点**？如果是，就必须用 =。
立即学习“go语言免费学习笔记（深入）”；
- 检查反射输出：
reflect.TypeOf(Res{}).Name()返回空字符串（别名） vs 返回"Res"（新类型） - 看是否要导出方法：要加方法 → 选
type T U；只图好写好读 → 选type T = U - 看错误信息关键词：
cannot use ... as type T in assignment通常是你该用别名却用了新类型；cannot define new methods on non-local type则是反过来了 - 最简单的验证方式：写一行
var _ U = T{}，如果编译通过，那T就是别名或兼容接口类型；通不过，就得查是不是结构体 + 新类型了
