类型推断（进阶）
复习
- 类型系统：用规则约束合法操作
- 表达式的类型检查：沿语法树检查
- 名字解析：确定名字指向的定义
本章为进阶内容，零基础读者可以跳过，不影响后续阅读。
TL;DR
- 类型推断让编译器从上下文推导出类型
- 程序员因此不必处处写出类型
- 常见于变量初始化、泛型与函数式语言
- 它的做法是收集类型约束，再求解
正文
静态类型检查很有价值，但“到处都要写类型”也挺累人。能不能让编译器自己猜出类型，程序员少写一点？这就是类型推断（type inference）。
从上下文猜类型
最简单的例子是变量初始化：写 var x = 1，编译器看到右边是整数 1，就能推断出 x 是整数，不必再写 int x = 1。
类型推断会顺着程序，综合各种线索来推导类型：
- 赋给它的值是什么类型
- 它参与了哪些运算（能参与哪些运算，就限定了可能的类型）
- 它被传给了什么函数、又从哪里返回
这些线索，本质上是一堆“约束”：x 的类型必须满足条件 A、B、C。类型推断的任务，就是解出满足所有约束的类型。
它让代码更简洁
类型推断最大的好处，是减少样板式的类型书写，让代码更干净、更聚焦在逻辑上。
在一些语言里，它用得更彻底：连函数的参数、返回类型，甚至泛型的具体类型，都能靠推断得出。于是你可以写得很简洁，同时仍然享受静态类型带来的编译期检查——鱼与熊掌兼得。
代价与难点
当然，它也有代价：
- 推断算法本身更复杂，编译器要做约束求解，实现难度上升
- 错误信息可能更费解：类型是推断出来的，一旦出错，编译器指出的位置和原因有时不那么直观
- 过度推断可能让代码可读性下降——类型都被藏起来了，读者也得自己推
所以，很多语言采取折中：能推断的地方就推断，关键的地方（尤其函数的公开接口）仍要求显式写明类型。既享受简洁，又保留可读性和清晰的错误提示。
这又一次体现了那个主题：每一项便利，背后都有代价，关键是找到合适的平衡点。
思考题 1
类型推断给程序员带来了什么便利？
思考题 2
类型推断有什么代价或难点？
小结
知识点
- 类型推断从上下文推导类型
- 它通过收集约束并求解来实现
- 好处是减少类型书写、保持静态检查
- 代价是编译器更复杂、错误信息可能更难懂
参考资料
- Wikipedia(zh)：类型推断：从上下文推导表达式类型
- Wikipedia(zh)：类型系统：类型推断所属的研究领域
思考题答案（仅供参考）
思考题 1
它让程序员不必处处写出类型，减少样板代码。比如通过变量初始值、参与运算的上下文自动确定类型，代码更简洁，同时仍然享受静态类型检查的好处。
思考题 2
代价是推断算法复杂、编译器实现难度上升；推断出的类型若出错，错误信息往往不够直观；类型都被隐去也可能降低代码可读性。因此一些语言只对局部做推断，关键接口仍要求显式标注。
协议
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
封面图
设计师 | 南国微雪