go中type newname = existingtype是类型别名，与原类型完全等价；type newname existingtype则是新类型，不兼容原类型且可定义方法。
Go 里写 type NewName = ExistingType 才是真正的类型别名；漏掉等号，就变成全新类型，后续赋值、传参、实现接口全都会报错。
type NewName = ExistingType 和 type NewName ExistingType 的区别
这是最常踩的坑：只差一个等号，语义天差地别。
-
type UserID = string→UserID和string完全等价，可直接互赋、传给fmt.Printf("%s", ...)、实现同一接口 -
type UserID string→UserID是独立新类型，UserID("123")不能直接传给接收string的函数，必须显式转：string(uid) - 编译器不提示“少等号”，只报
cannot use ... as ... value，容易卡在函数调用处反复排查 - 反射层面：
reflect.TypeOf(UserID("x")).Name()对别名返回空字符串，对新类型返回"UserID"
类型别名不能加方法，但能继承原类型的方法
别名不是“带壳的原类型”，它根本没自己的方法集——只是编译器在类型检查阶段替换成原类型名。
-
type MyInt = int→ 无法写func (m MyInt) Double() MyInt，编译报错：cannot define new methods on non-local type -
type MyInt int→ 可以正常定义方法，且MyInt不再和int兼容 - 如果原类型本身有方法（比如某个自定义类型
type DurationMs int64加了Seconds()），那么它的别名会继承这些方法；但这是原类型的功劳，不是别名的能力 - JSON 序列化行为完全一致，无需额外 tag，也无运行时开销
哪些场景必须用类型别名，而不是新类型
核心判断标准：是否需要「零成本兼容」或「跨包类型对齐」。
- 包迁移过渡：
type Config = github.com/org/pkg/v2.Config，旧代码引用pkg/v1.Config时只需加这一行，不用改任何调用点 - 简化长签名：
type HandlerFunc = func(http.ResponseWriter, *http.Request)，这样中间件既能接收http.HandlerFunc，也能被当成普通函数字面量传入 - 泛型辅助：
type EventStream[T any] = chan T，既保持语义清晰，又避免引入新类型带来的方法绑定和转换负担 - API 版本兼容：
type ReqV1 = Request，老接口保留ReqV1参数名，新逻辑统一走Request，不重复实现
调试和日志中怎么看类型别名实际是什么
别名在运行时不存在，所以打印类型名或查反射时容易误判。
-
fmt.Printf("%T", UserID("123"))输出的是string，不是UserID -
reflect.TypeOf(UserID("123")).Name()返回空字符串，因为别名没有自己的名字；而reflect.TypeOf(MyString("x")).Name()（新类型）返回"MyString" - 想确认变量底层是不是别名，看它的声明源码有没有
=；IDE 跳转到定义时，如果直接跳到原类型（如string），大概率是别名 - JSON marshal/unmarshal 结果完全一样，别指望靠序列化输出区分别名和原类型
真正难的不是写对等号，而是想清楚：你到底要的是「换个名字喊」，还是「立个规矩管」。前者用别名，后者必须用新类型加方法和构造函数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
