第三世界的妖孽做一个自制编程语言，最爽的阶段是写解析器和求值器，因为教科书把标准答案都摆在你面前了。真正把人逼疯的是第二阶段的抉择：你怎么定义“类”，怎么处理“错误”。这两个问题没有标准答案。面向对象和异常处理，各自藏着一长串专门给语言设计者准备的坑——我说的不是使用者的坑，是设计者的坑。使用者踩坑顶多改代码，设计者踩坑，那就是让整个生态的人都跟着一起踩。这篇文章就聊聊我在这个阶段踩过的、绕过的一些坑，以及对“坑”本身的一些思考。
这篇内容适合正在做语言设计、编译器、DSL，或者只是对编程语言底层逻辑感兴趣的人。我会把这些方案的取舍、代价和后续演进拆开讲，尽量把“为什么当时会这么做”和“换了我我会怎么做”都说清楚。标题里的“什么是坑”也可以理解成：我希望你读完能知道，坑长什么样，坑为什么出现在那里，以及，哪些坑其实可以绕过去。
1. 继承体系设计：从菱形问题到脆基类的连环雷
1.1 一上来就设计多继承，你会在菱形上摔得鼻青脸肿
我最初设计类体系的时候特别天真，觉得“一个类继承多个父类”不是很自然吗？人既能继承“会走路”，又能继承“会说话”，多继承简直是为现实建模量身定做的。于是我真的在自己的语言里支持了多继承，还专门写了一套复杂的名字查找规则。结果第一个大型测试用例就把我拍死在菱形问题上。
菱形问题长这样：A 是基类，B 和 C 都继承 A，然后 D 同时继承 B 和 C。那么 D 的对象里到底有几份 A 的状态？如果你说有一份，那 B 和 C 各自对 A 的修改是否互相可见？如果你说有两份，那 D 访问 A 的成员时应该取哪一份？
cpp复制class A { public: int x; };
class B : public A {};
class C : public A {};
class D : public B, public C {};
// D 对象中 x 到底是一份还是两份？
C++ 对这个问题给出了虚拟继承这个答案。虚继承解决了一部分问题，但它带来的复杂度几乎让人崩溃：最派生类要负责初始化虚基类，普通继承和虚继承的初始化顺序还不一样，一旦设计不好就会出现“明明在两行代码之间，对象状态却变了”的诡异现象。Eiffel 语言选择了另一条路，允许用户手动重命名或合并继承来的特性，等于把问题抛给了用户——这在实践中也成了一个巨大的心智负担。Python 采用 C3 线性化，把多继承扁平化成一条继承链，表面上没什么冲突了，但遇到复杂的类图时，MRO 的顺序会引发你想不到的覆盖行为，调试起来匪夷所思。
所以现在我的建议非常直接：新的语言，别提供多继承。不是说你实现不了，而是你要么花大量精力去设计规则，要么把复杂度转嫁给用户。菱形问题的本质是“多个父类路径指向同一个祖先状态”，只要让父类接口不带状态、不能构造，这个问题就消失了。Java 的接口、Rust 的 trait、Go 的 embedding 走的就是这条路线。接口和 trait 可以多继承，因为它们不持有状态、没有构造函数，冲突只在方法签名层面发生，而方法签名冲突是可以用改名或显式选择解决的。我后来把语言里所有“类”的父类都限制为一个，其他一律用 trait，心情舒畅了很多。
1.2 脆基类问题：子类随意重写，基类节节败退
先别急着高兴。砍掉多继承，单继承依然有个大坑在等你：脆基类问题。这个问题的意思是，即便你只有单继承，只要允许子类自由重写方法，基类的内部行为就很容易被子类破坏。
举个例子。基类里有个公开方法 step()，它内部调用了另一个方法 stepImpl()。子类重写了 stepImpl()，误以为这只是“扩展一下某个钩子”，结果导致基类 step() 的整体行为完全走样。更经典的场景是构造函数里调用虚方法——Java 里构造函数调用一个可重写方法，实际执行的是子类的重写版本，而此时子类的字段还没初始化，轻则拿到 null，重则抛异常。C++ 在构造函数里调用虚函数时甚至直接禁用动态分发，调用的是基类版本，这又让很多 C++ 新手感到困惑。
脆基类问题的本质是什么？是类的演进变得危险。基类的作者修改一个方法的内部实现，哪怕只是改了一行调用关系，都可能因为某个子类重写了内部方法而导致线上行为变化。库发布者改了一版内部逻辑，使用者的子类就崩溃了。这个问题几乎不可能靠程序员自律解决，只能靠语言设计去限制。
现代语言给出的对策各不相同。C# 和 Kotlin 把“重写”默认关闭，方法必须显式标记为 virtual 或 open，子类才能重写它。Java 虽然默认开放，但从 Java 9 的模块封装到 Java 17 的 sealed class，都是在逐步收紧“谁能继承、谁能重写”的边界。如果你在设计语言，我强烈建议把“可重写”做成显式的开放协议，而不是默认开启。让开发者问自己：这个方法是留给子类扩展的吗？如果是，你写清楚；如果不是，编译器帮你拦住。
1.3 控制重写权限：final、密封类与设计者的自我克制
接着上一点说，语言设计者必须面对一个诱惑：给用户提供尽可能多的扩展点。我之前设计类的时候，总觉得“不能重写”是限制用户自由，是坏设计。结果等我开始写基于这个语言的业务代码时，发现满屏都是不经思考的 override，基类修一个 bug，子类的行为跟着乱跳，完全失控。
所以语言里必须提供三层控制：final 方法禁止重写，sealed 类限制继承者的范围，open 显式声明可重写。这套机制不是给使用者添堵，而是让“继承”真正成为可审计的契约。接口保持开放，类尽量封闭；数据用组合嵌入，行为用接口抽象。你把可重写的方法数量控制得越少，类的内部不变量就越稳固。我记得我第一个版本把继承优先级设得特别高，重写完全开放，最后几乎是被自己测试代码里那些莫名其妙的联动 bug 逼着改了设计。后来我强制自己先问一个问题：这里真的需要继承吗？继承真的是表达这个关系最好的方式吗？如果能用“一个对象持有另一个对象的引用，并委托给它”来解决，就绝不用继承。这就是组合优先于继承。你在写业务代码时可能觉得这个原则老生常谈，但作为语言设计者，你要做的是把这条原则嵌进语言的默认语义里。Go 只有嵌入没有继承，Rust 直接没有继承，它们都活得好好的——这本身就是一种设计态度。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 空值与类型系统：被低估的“十亿美元错误”
2.1 null 从哪来：一个快速方案的长期债务
如果说继承是和“如何组织对象关系”搏斗，那 null 就是和类型系统本身的完备性搏斗。1965 年，Tony Hoare 在设计 ALGOL W 时引入了 null reference，几十年后他公开道歉，说这是“十亿美元错误”。为什么叫这个名字？因为从 1965 年到现在，各种语言里因为空引用导致的崩溃、安全问题、排查成本加起来，早就超过了十亿美元。问题是，这样一个饱经诟病的特性，为什么几乎所有语言都在用？因为实现起来太简单了：指针不指向任何对象时，存一个 0 地址就行。语义简单、存储成本低、编译器实现也简单。但它带来的连锁反应，几乎全部由使用者承担了。
在面向对象语言里，null 通常被设计成所有引用类型的默认值。你声明一个对象变量，不赋值，它默认就是 null。这就意味着你代码里任何一次方法调用、属性访问，理论上都可能炸。Java 的 NullPointerException 常年占据各类异常统计榜首，不是程序员不够小心，而是类型系统构造了一个处处埋雷的世界。如果你在设计一门面向对象的语言，引用类型的默认值到底应该是 null 还是某个“空对象”，这个问题你必须在第一天就想清楚。
2.2 可空类型、Option 与空安全：三种补救路线
现代语言给了三种主要解决方案。第一种是 Kotlin 和 Swift 的可空类型：把类型分成 String 和 String? 两种，可空类型上的访问被编译器禁止，必须显式解包或使用安全调用。
kotlin复制val s: String? = null
val len = s?.length ?: 0 // 安全调用，null 时得到 0
第二种是 Rust 的 Option<T>：没有 null 关键字，“可能没有值”被表示成一个枚举，必须通过 match 或 ? 运算符显式处理。
rust复制let name: Option<String> = maybe_get_name();
let len = match name {
Some(n) => n.len(),
None => 0,
};
第三种是动态语言的老办法：继续用 null/undefined，靠运行时循环检测。Python 的 None、JavaScript 的 null 和 undefined 本质上都是运行时标记。这种方式写起来最轻松，但所有错误都延迟到了运行期。
这三条路线没有绝对优劣，关键是你要为自己的语言定下基调：是把空安全当编译期的硬性约束，还是当运行期的软性约定。我现在的倾向是，宁可语法上多一点噪音，也要把“空”变成类型的一部分。不是说你一定要引入可空类型，而是要让程序员在编译阶段就能看到“这里可能没有值”的提示。你可以在语言里提供一个 Option 或者类似的原生类型，让它成为标准库的一部分，而不要像 Java 早期那样，让一切引用都默认可空，却没有任何静态提示。那种“反正写完代码跑起来才知道会不会 NPE”的体验，实在太痛苦了。
2.3 极端的“一切皆对象”：完备性执念带来的设计代价
说完了 null，聊一个很多人忽略的坑：追求“面向对象完备性”的执念。很多语言设计者希望“万物皆对象”，让 int、boolean、字符串这些基础值也变成对象，从而统一类型模型。Java 就是这么做的，结果呢？为了让 int 变对象，搞出了 Integer 包装类；为了支持集合存储基本类型，搞出了自动装箱。自动装箱引入了隐藏的堆分配、整数缓存池，以及臭名昭著的“拆箱 NPE”：
java复制Integer a = null;
int b = a; // 运行期抛 NullPointerException
更让人头疼的是，如果语言里的一切都是对象，那么“返回两个值”这种极其常见的需求，就非得定义一个类不可。Java 8 之前，想在集合里排序，你得写匿名内部类；想在函数式风格里传个函数对象，你得用一堆接口。表达式能力和简洁性被“一切皆对象”的教条严重拖累。后来 Java 引入了 record、Lambda、stream，语言层面才勉强追上其他现代语言的舒适度，但代价是语法越来越重。
这段历史对语言设计者的启示是：值类型很重要。Kotlin 的 value class、Swift 的 struct、C# 的 struct 都是在试图把“值”和“对象”区分开。设计语言时，你应该让基础类型（数值、布尔、字符串、集合）是轻量的值，而不是必须经过堆分配和引用语义的对象。参数返回值并不需要总是定义一个类，多返回值和模式匹配能解决大部分场景。用户不该为了一个简单的“坐标点”去造类，也不该为了函数式写法而和一堆接口纠缠。完备性不该以牺牲可用性为代价。
3. 异常机制设计：错误可见性与非局部控制流的平衡木
3.1 错误码方案为什么会让调用者集体失明
面向对象搞明白之后，下一个大坑是错误处理。我早期的语言设计里，错误处理只有两个字：错误码。函数返回一个整数，0 表示成功，非 0 表示某种错误，调用者自己检查。这方案在纸上看着无懈可击，可一旦你写真实业务，马上就会被以下场景折磨：有人忘了检查返回值，错误被当成正常流程继续执行；有人检查了，但判断条件写反，成功当成失败；错误从底层传到上层要经过好多层函数，每一层都得写 if (ret != 0) return ret;，少写一层，错误就丢了。
C 语言时代，errno 是一个全局变量，要么被下一次调用覆盖，要么在线程并发里互相污染。后来的语言，比如 Go，用多返回值来改进错误码，函数签名变成 (value, error)，这比全局变量靠谱多了。但 Go 的 if err != nil 写多了之后，人会产生麻木感，错误检查变成“机械动作”，一机械就会漏。错误码方案的核心矛盾在于：它把“错误是否被处理”完全寄托在调用者的纪律性上，而语言设计者恰恰不该指望用户人人自律。
3.2 异常的“隐形 goto”本质与控制流失控
于是异常出现了。异常的核心优势是：错误不再依赖调用者自觉。函数内部抛出一个异常，它会自动沿着调用栈向上传播，直到找到能处理它的地方。中间那些既不能处理也不该处理的函数，可以完全不用写代码，异常会自己跳过去。这个特性让错误处理代码的数量大幅减少，错误不再那么容易被忽略。
但异常有一个非常隐蔽的副作用：它是非局部控制流。本质上，throw 是一次“隐形 goto”，它的目的地是调用栈里任意深度的某个 catch 块。你在读代码的时候，看到一个普通函数调用，并不知道它会抛出什么异常、会在哪里被捕获。异常跨越了函数边界、类边界，甚至跨越了抽象层。局部的控制流被打断，程序的整体行为变得很难从局部代码推理出来。
更麻烦的是，异常在传播过程中可能被中间层捕获、修改、重新抛出。比如底层抛出一个 SQLException，中间框架捕获后包成 DataAccessException 再抛出来，上层程序员看到的异常信息已经和原始错误隔离了。这个包装过程会造成大量信息丢失和上下文污染。所以语言设计者要思考的问题不是“要不要提供异常”，而是“如何控制这种非局部控制流的破坏性”。
3.3 检查型异常的两难：Java 的妥协与反思
Java 当年给出的答案是检查型异常：编译器强制你处理可能抛出的异常，方法声明里必须写 throws IOException，调用者要么 catch 要么继续往上抛。初衷非常好，它试图把错误处理变成编译期约束。但多年实践下来，这个设计逐渐走向了形式主义。为什么？因为访问一个文件就可能抛出 IOException，而 IOException 之上的业务逻辑可能根本不在乎文件打开失败的具体原因。程序员无可奈何，只能一路往方法签名上堆 throws。堆到顶层，接口的抽象被异常声明绑架，修改一个底层方法的异常声明，整个调用链都要跟着改。
于是大家学会了“吞异常”：catch 住然后打印日志，什么都不做。检查型异常从“强制处理”变成了“强制打个招呼”。再后来，各种框架干脆把受检异常包成 RuntimeException，让异常逃逸出检查机制——检查型异常在实践意义上已经名存实亡。C++ 的 throw 声明更惨，语法上声明了“只抛这些异常”，结果运行时一旦违反，直接调用 unexpected() 终止程序，而不是编译报错，因此被普遍视为反模式，后来演进为 noexcept——一个纯粹的用户承诺。
这里有个深刻的教训：强制错误处理并不能保证用户认真处理错误，它只会让用户学会如何绕过检查。错误处理机制的设计目标应该是“让错误可见且可传播”，而不是“强制用户现在就得处理”。Rust 的 Result<T, E> 加 ? 运算符在这件事上找到了一条相对好的路。错误是返回值的一部分，方法签名天然可以看出来“这个函数可能失败”；? 运算符让错误可以在调用链中快速向上传播，成本很低；最终要不要处理错误，由上层业务决定，而不是被编译器逼着做形式化的 catch。可以说，Rust 是把“错误可见性”和“程序员自主性”结合得最好的方案之一。
4. 异常背后的两个硬骨头：资源清理与运行时开销
4.1 异常发生后的残局：RAII、finally 与 defer 的设计取舍
即使你决定在语言里支持异常，还有一个问题绕不开：异常往往发生在资源还没被手动释放的时候。如果程序在打开文件后、关闭文件前抛出了异常，谁来负责关闭文件？如果语言没有资源清理机制，用户就只能在每个可能出错的地方写 try-finally，样板代码多得吓人。
C++ 给出的答案是 RAII：资源在构造函数里获取，在析构函数里释放，而局部对象的析构函数在栈展开（stack unwinding）时自动执行。异常抛出后，C++ 运行时会把沿途栈上的对象挨个析构，资源自然释放。这非常优雅，但它极度依赖对象的生命周期语义，用户必须理解析构函数在什么时候、以什么顺序执行，稍有不慎就会踩到悬空引用或二重释放的坑。Java 早期没有 RAII，只有 try-finally，样板代码密密麻麻。后来 Java 7 设计了 try-with-resources，把“实现 AutoCloseable 接口的资源，在 try 块结束时自动关闭”做成了语言特性，代码才算清爽了一些。Python 则用 with 语句和上下文管理器协议解决同样的问题。
Go 选择了另一条路：defer。你可以在函数里注册一个延迟执行的动作，函数返回、甚至 panic 时都会逆序执行所有 defer。这个机制非常好用，但有一个语义死角：defer 无法区分“函数正常返回”和“panic 之后返回”，如果用户想在 panic 时执行一些不同的清理动作，必须自己检查状态。所以语言设计者要注意的是：异常机制本身不是完整的错误处理系统，它必须搭配资源清理原语（RAII、finally、defer、with 等）才算是闭环。你的语言里如果只有 throw-catch 而没有可靠地清理资源的方式，那就相当于让用户生活在煤气泄漏的房子里还告诉他可以开火做饭。
4.2 异常的性能账单：从栈展开到异常对象分配
还有一个被很多人忽视的坑：异常的性能。很多语言在 happy path（不抛异常的正常路径）上，异常几乎是零开销的，比如 C++ 的 Itanium ABI 采用函数表记录异常范围，不进入 try 块就不会额外执行代码。但一旦真的抛异常，代价相当高：要分配异常对象（即使是从栈上复制到堆上，也逃不掉堆分配），要在栈展开过程中逐帧回溯，销毁沿途的局部对象，还要通过运行时类型信息匹配 catch 块。整个过程比一次普通函数调用贵几个数量级。
Java 的异常还有一个隐藏开销：异常对象创建时默认会捕获调用栈快照（fillInStackTrace），这也是为了诊断信息，但成本很高。我曾经见过一段把异常当循环控制流用的 Java 代码，性能直接掉了一个量级。C++ 的异常对象同样需要栈回溯，虽然没有 Java 那么重的堆栈快照，但也绝不算便宜。
这件事的结论是：异常机制适合表达那些“不经常发生”的错误，不适合表达高频分支控制。如果你的语言想支持高频错误场景的高性能，就应该提供更轻量的方案。Rust 的 Result、Go 的 error 本质上都是“返回错误值”，几乎零额外开销，因此在高吞吐服务里更吃得开。语言设计者必须在设计文档里明确写出异常的性能特征：什么时候快、什么时候慢、该不该把异常当作控制流。不然用户迟早会因为性能坑来找你。
5. 异步与并发：异常最容易走丢的领域
5.1 回调地狱里的异常黑洞：CompletableFuture 的静默失效
同步代码里，异常沿着调用栈传播，清清楚楚。但到了异步场景，这条路断了。当你在一个线程池里提交一个任务，任务执行过程中发生异常，而提交方并没有立刻 get 或 join，异常去哪了？在很多框架里，它哪也不去——它就静静地躺在 Future 里，等着被某个最终调用者读取。如果没人读，它就是“永远不会响的闹钟”。
java复制CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
throw new RuntimeException("boom");
});
// 没有人调用 future.get()，异常被静默吞掉
这就是 CompletableFuture 经典的异常黑洞。你启动一个异步任务，满心以为它会在某个时刻成功，结果它在后台悄悄失败了，而且没有任何日志、没有信号，整个程序继续运行，直到某个依赖这个异步结果的操作突然拿不到数据，你才开始排查——最终发现异常发生在几个小时之前。线程池的 execute() 方法还会把异常打印到控制台，但 submit() 返回的 Future 被忽略时，异常就会悄无声息地消失。与其说这是程序员不小心，不如说这是异步编程模型的“结构性缺陷”：异常传播依赖的是调用栈，而异步任务没有调用栈。
5.2 异常应该属于“任务上下文”：从 Future 到结构化并发
所以，语言设计者如果支持异步编程，不能只提供一个 async 关键字，还必须回答一个关键问题：一个任务抛出异常之后，这个异常去哪里？传统的 Future 方案把它藏在任务结果里，等观察者来取；Kotlin 协程的方案是让异常沿着父子协程作用域传播，子协程的异常会取消父作用域；Goroutine 则干脆一点，panic 没有 recover 就直接让整个进程崩溃，错误想藏都藏不住。每种方案都是在选择“异常的可见性级别”。
近年来我比较欣赏的结构化并发理念，是把异步任务组织成有父子作用域的树。父作用域启动若干子任务，并等待它们全部完成；如果某个子任务抛异常，异常会传播到父作用域，父作用域可以选择取消其他兄弟任务，然后在自己的上下文中重新抛出。这样异常就不会消失在某个 Future 里，而是沿着任务树向上传播，直到有一个真正知道怎么处理它的地方。结构化并发还要求语言能够保证作用域退出时没有“逃亡”的子任务——就是说，你不小心启动的异步任务，不可能在父作用域结束后还挂在后台偷偷运行。这种设计把异步异常传播重新拉回到了“可预测的控制流”里。
如果你的语言要实现协程或异步任务，我建议把异常传播路径设计到任务树级别，而不是像 Java 早期那样依赖 Future.get() 这把“锁”。异常应该属于任务上下文，谁启动了这个任务，谁就有机会看到它的最终结果，而不是等异常自己漂到某个线程池的边缘。
6. 设计语言时的自我质问：哪些坑可以不踩
6.1 每一项特性都要回答“用户的痛点是什么”
设计语言最诱惑人的时刻，是你兴高采烈地加功能。多继承加上去，很酷；检查型异常加上去，很严谨；受检异常、虚函数、泛型、运算符重载……一个个特性堆上去，看起来无所不能。但每多一个特性，你其实就在增加“特性之间的交互”复杂度。这些交互经常产生意想不到的坑。我自己吃过很多亏之后，现在给任何语言特性列了一个硬性标准：它要清楚地回答，它替用户解决了什么痛点？如果这个痛点用组合、接口、标准库也能解决，那它是否值得占用核心语法？
很多语言设计的失败，不是某个特性本身不好，而是特性太多、组合太复杂。想一想 Java 早期同时提供了继承、重写、受检异常、Object 基类，结果用户要在类层次里玩出花来，到处是脆弱基类和吞掉的异常。语言设计者最重要的是克制，是“少即是多”。你可以参考一个简单的判断方法：如果你说不太清楚这个特性到底能救谁于水火，那大概率是你在给自己加戏。
6.2 从 Go 的 error 与 Rust 的 Result 学到的事
我比较了 Go 和 Rust 的错误处理哲学之后，发现它们其实是同一道选择题的两种答案。Go 选了“错误是值”：返回一个 error 类型的值，显式地让调用者处理。它把错误处理的负担明明白白摆在代码里，你可以忽略它，但代码会很丑，这让“忽略错误”变得有心理成本。Rust 也把错误当作值，但它更进一步，用 Option<T> 和 Result<T, E> 把“可能为空”和“可能出错”直接编码进类型系统，配合 match 和 ? 运算符，让错误处理在保证安全的同时尽量简洁。
这两种方案都给我一个强烈的启示：普通错误别用异常。异常适合表达“罕见且不可恢复”的情况（比如内存耗尽、断言失败、严重违反不变量），而普通业务错误（文件不存在、网络超时、参数非法）应该用返回值或错误值表达。把这两者混在一起，是很多语言生态里代码混乱的根源。用户开始用异常做控制流、用吞异常来“省事”，然后整个项目变成一座谁也不敢动的活火山。如果我有一次重新设计语言的机会，我会把二者明确分开：常规错误用“可失败的返回值”，不可恢复的故障用“崩溃/异常”，并且让这两者在类型层面就能区分。
6.3 我的错误处理三原则
整理一下我个人目前在语言设计上的一些倾向，或者说原则：
第一，错误必须可见。任何错误处理方案，如果允许错误在默认路径上被静默吞掉，这个方案就是不合格的。检查型异常逼出的“catch 后打日志”是形式主义的可见，不是真正的可见