type alias（type T = Existing）使新名与原类型完全等价、共享方法集；type definition（type T Existing）创建独立类型、有专属方法集，二者不可互换。
type alias 和 type definition 的区别必须分清
Go 1.9 引入 type alias，不是语法糖，而是有明确语义差异的机制。用错会导致类型不兼容、接口实现失败、甚至编译报错。
关键判断：如果想让新名字和原类型“完全等价、可互换”，用 type T = Existing；如果只是“基于现有类型定义一个新类型（带独立方法集）”，必须用 type T Existing（无等号）。
-
type MyInt = int：MyInt就是int，能直接赋值给int变量，也能实现同一个接口 -
type MyInt int：MyInt是全新类型，哪怕底层是int，也不能直接赋值给int，方法集也独立 - 重构时若把
type MyInt int改成type MyInt = int，所有已定义的func (m MyInt) String()会失效——别名没有自己的方法集
重构旧代码时 alias 能绕过 import cycle 吗
不能。alias 本身不解决导入循环，但它可以帮你“延迟解耦”——把循环点从类型定义层移到使用层。
常见场景：包 A 定义了 type Config struct{...}，包 B 需要用它，但 B 又被 A 依赖。硬加 import 就循环了。
立即学习“go语言免费学习笔记（深入）”；
- 错误做法：在 A 中写
type Config = B.Config—— 这反而让 A 依赖 B，更糟 - 可行做法：在 B 中定义
type Config = A.Config，前提是 A 不引用 B 的任何符号（包括类型名），且 A 的Config是导出的 - 更稳妥的是用接口抽象：A 暴露
type Configer interface{ GetHost() string }，B 实现它，避免具体类型暴露
JSON 序列化里 alias 和 definition 行为一致吗
底层行为一样，但要注意方法集带来的间接影响。
json.Marshal 看的是值的底层类型 + 是否实现了 json.Marshaler。alias 没有自己的方法，所以会退回到原类型的实现；而 definition 如果自己实现了 MarshalJSON，就会用它。
-
type Alias = time.Time→ 序列化走time.Time.MarshalJSON -
type CustomTime time.Time+func (c CustomTime) MarshalJSON() ([]byte, error)→ 走自定义逻辑 - 别名不能加方法，所以想控制序列化格式又不想改原类型？只能用 definition + 委托，或用中间结构体
升级 Go 版本后 alias 编译失败的典型错误
Go 1.8 及以前不支持 = 语法，直接报 syntax error: unexpected =。这不是代码问题，是环境问题。
- 检查
go version，确认 ≥ 1.9 - CI/CD 中容易忽略：Dockerfile 用
golang:1.8-alpine构建，但本地是 1.21 —— 错误不会在本地暴露 - 交叉编译时注意：目标平台的 Go toolchain 版本也得 ≥ 1.9
- 别用
//go:build条件编译 alias，它不是特性开关，是语法层级变更
alias 看似简单，但真正卡住人的地方往往不在定义本身，而在它和方法集、接口实现、模块导入边界的交互细节里。改一行 =，可能要扫三处调用点是否还合法。
