HTML5游戏开发走到一定规模之后，真正卡住人的往往不是玩法创意，而是框架本身撑不住。小项目里随手写的渲染循环、事件绑定、资源加载，一旦场景数量上去、模块开始互相引用、团队从一个人变成三五个人，代码就会迅速腐化成一张扯不开的网。我接触过不少做互动营销页、轻量级休闲游戏、教育类互动课件的团队，几乎都在同一个地方栽跟头：前期图快，把所有逻辑塞进一个主循环里，后期想加一个功能就得动全身。Hilo 这个框架之所以值得单独拿出来聊，就是它在架构层面把"高扩展性"这件事想得比较透，而不是简单地提供一套绘图 API 就完事。这篇内容我会从架构设计的角度，把 Hilo 的分层思路、模块解耦方式、渲染与更新机制、资源管理策略、扩展点设计逐一拆开讲，中间穿插我自己在类似框架上踩过的坑和实操建议。适合已经会用 Canvas 或 DOM 做简单动画、想进一步理解"框架为什么这么设计"的中级开发者，也适合正在选型、需要评估一个 HTML5 游戏框架能否支撑长期迭代的技术负责人。读完之后你应该能自己判断：什么样的项目适合这套架构，哪些扩展点必须提前规划，以及怎么在它的骨架上搭出属于自己的业务层。
1. 从"能跑"到"能长大"：Hilo 架构设计的整体思路拆解
1.1 为什么游戏框架的扩展性比功能数量更重要
先说说我对"扩展性"这三个字的理解。很多框架在宣传时会列一堆特性：支持精灵图、支持骨骼动画、支持物理引擎、支持粒子系统。这些是功能，不是架构。功能可以后补，架构一旦定死就很难改。Hilo 的设计取向很明确——它不追求把市面上所有游戏能力都内置进来，而是把"舞台、对象、渲染、事件、资源"这几条主干做稳，剩下的通过继承和组合去扩展。这个取舍背后有一个很现实的判断：HTML5 游戏的形态差异太大了，互动广告可能只需要一个时间轴加几个点击区域，而休闲游戏需要完整的场景切换、对象池、碰撞检测。如果框架把业务逻辑写死，两类项目都会被拖累。
我见过一个典型的反面案例：某团队用一套"大而全"的框架做互动课件，结果框架自带的场景管理器和他们的页面路由打架，最后不得不把框架源码改得面目全非，升级一次就崩一次。Hilo 走的是另一条路，它把核心抽象压到很少的几个类上，每个类职责单一，业务层通过继承去长出自己想要的东西。这种设计在项目初期看起来"要多写一点代码"，但到了中期，当你需要给所有游戏对象统一加一个生命周期钩子、或者给所有显示对象统一加一层滤镜缓存时，你会发现只需要在一个基类上动手，而不是满项目搜索替换。
从架构视角看，Hilo 解决的核心问题是关注点分离。渲染归渲染，更新归更新，资源归资源，事件归事件。这四件事在代码里如果纠缠在一起，扩展性就无从谈起。举个最朴素的例子：一个精灵的移动逻辑，如果写在渲染循环里直接改坐标，那么当你想把这个精灵放到对象池里复用时，你会发现它的移动逻辑和渲染时机绑死了，没法单独控制。Hilo 把"更新"和"渲染"拆成两个阶段，对象只负责描述自己的状态，舞台负责在合适的时机驱动它们，这就给复用和扩展留出了空间。
1.2 分层结构：舞台、显示对象、渲染器、资源管理器各管一摊
Hilo 的整体结构可以粗略分成四层，我用一张表把每层的职责和扩展方式列清楚，这样你在设计自己的业务模块时就知道该往哪一层挂。
| 层级 | 核心职责 | 典型抽象 | 扩展方式 |
|---|---|---|---|
| 舞台层 | 驱动主循环、管理场景根节点、协调更新与渲染时序 | Stage | 继承或包装，注入自定义时钟 |
| 显示对象层 | 描述可视元素的位置、尺寸、变换、层级 | View / Sprite | 继承基类，重写绘制与更新 |
| 渲染层 | 把显示对象画到 Canvas 或 DOM 上 | Renderer | 替换渲染实现，适配不同后端 |
| 资源层 | 加载、缓存、释放图片、音频、数据 | LoadQueue / 缓存池 | 注册自定义加载器与解析器 |
这个分层的关键在于依赖方向是单向的。舞台依赖显示对象，显示对象依赖渲染器接口，资源层被上层按需调用，但资源层不反过来依赖舞台。单向依赖是扩展性的地基，因为你可以替换任意一层的实现而不影响其他层。比如你想把 Canvas 渲染换成 WebGL 渲染，只要新的渲染器实现了同样的接口，显示对象层完全不用改。再比如你想加一套自定义的资源格式（比如某种打包后的图集），只要注册一个解析器，加载流程照常走。
我在实际项目里做过一次验证：把一个基于 Hilo 思路的小框架的渲染后端从 2D Canvas 换成离屏 Canvas 加脏矩形重绘，改动集中在渲染层，显示对象层只改了一个标记脏区域的方法调用，业务代码一行没动。这就是分层带来的好处。反过来说，如果你的项目里渲染逻辑散落在各个业务类里，这种替换几乎等于重写。
1.3 主循环的时序设计：更新与渲染为什么要分开
主循环是游戏框架的心脏，Hilo 在这块的时序安排值得单独说。它把每一帧拆成"更新"和"渲染"两个阶段，先让所有对象更新自己的状态，再统一渲染。这个顺序不是随便定的。假设你先渲染再更新，那么这一帧画出来的是上一帧的状态，视觉上会慢半拍；更麻烦的是，如果更新阶段里有对象增删，渲染阶段遍历的列表就可能不一致，导致闪烁或者报错。先更新后渲染，保证了渲染时看到的是一个稳定的、本帧最终确定的对象树。
更新阶段内部还有一个细节：固定时间步长还是可变时间步长。Hilo 默认走的是基于实际帧间隔的可变步长，这在大多数休闲游戏里够用，实现简单。但如果你要做物理模拟或者需要确定性回放，可变步长会带来问题——同样的操作在不同帧率下结果不同。我的建议是，如果你的项目涉及物理或者需要联网同步，在舞台层外面包一层固定步长的累加器，把逻辑更新和渲染解耦成不同的频率。具体做法是维护一个累加器，每帧把实际耗时加进去，当累加器超过固定步长就执行一次逻辑更新并减去步长，渲染则每帧都做。这个模式在业界很常见，Hilo 的架构留出了这个扩展空间，因为更新和渲染本来就是分开的，你只需要控制更新的触发频率。
提示：固定步长的步长值不要拍脑袋定。常见做法是取 1/60 秒，但如果你的逻辑更新很重，可以降到 1/30 秒并配合插值渲染，避免逻辑更新拖垮帧率。插值的思路是渲染时用"上一帧状态"和"当前帧状态"按累加器余量做线性插值，视觉上依然平滑。
2. 显示对象体系：继承树怎么设计才不失控
2.1 基类只放共性，差异全部下沉到子类
显示对象是 Hilo 里被继承最多的部分，也是最容易设计失控的地方。我见过不少项目，基类越写越胖，最后变成一个什么都管的上帝类：位置、尺寸、变换、事件、动画、碰撞、生命周期全塞在一起。这种基类一旦被几十个子类继承，任何一处改动都可能引发连锁反应。Hilo 的做法是基类只保留最共性的东西——位置、尺寸、可见性、父子关系、变换矩阵，以及更新和渲染两个钩子方法。动画、碰撞、输入响应这些能力，要么放到独立的组件里，要么由具体子类自己实现。
这个取舍的逻辑是变化频率。位置、尺寸、可见性这些属性几乎每个显示对象都有，而且很少变，放基类合理。动画和碰撞则因项目而异，有的项目根本不需要碰撞，硬塞进基类就是负担。把变化频率低的东西放基类，变化频率高的东西下沉，这是继承设计的一条朴素原则。你可以用下面这个判断流程来决定一个能力该放哪：如果这个能力 80% 以上的子类都会用到，且实现方式基本一致，放基类；如果只有部分子类需要，或者不同子类实现差异大，做成组件或独立类；如果只在特定业务场景出现，放到业务层，别污染框架层。
2.2 变换与层级：父子关系的坐标传递怎么算
显示对象的父子关系是 Hilo 架构里一个容易被低估的设计点。父节点移动，子节点跟着动；父节点旋转缩放，子节点的坐标系也跟着变。这背后是变换矩阵的级联乘法。每个显示对象维护一个局部变换矩阵，渲染时从根节点往下逐层相乘，得到世界变换矩阵。这个机制让"把一组元素打包成一个整体来操作"变得非常自然，比如一个角色由身体、武器、血条三个子对象组成，移动角色只需要动父节点。
但这里有个性能陷阱我得提醒：矩阵级联是有成本的，层级越深，每帧的计算量越大。如果你的场景里有大量深层嵌套的显示对象，渲染前的矩阵计算可能成为瓶颈。优化思路有两个：一是把不常变化的子树做矩阵缓存，只有父节点变换改变时才重新计算；二是扁平化层级，把视觉上不需要真正父子关系的对象提到同一层，用绝对坐标定位。我在一个塔防类项目里做过对比，把防御塔的炮台、底座、血条从三层嵌套压成一层加手动偏移，渲染耗时下降了接近两成。当然这是用可维护性换性能，层级扁平化之后，整体移动的逻辑要自己维护，得权衡。
2.3 对象池与复用：频繁创建销毁的显示对象怎么管
游戏里有一类对象生命周期很短、创建频率很高，比如子弹、粒子、飘字。如果每次都 new 一个显示对象再销毁，垃圾回收的压力会很大，帧率会出现周期性抖动。Hilo 的架构本身不强制对象池，但它的显示对象设计对池化是友好的——对象的状态和它的挂载关系是分离的，你可以把一个对象从舞台上摘下来、重置状态、再挂回去，而不需要重新构造。
对象池的实现要点我总结成三条。第一，重置要彻底。位置、旋转、缩放、透明度、可见性、事件监听、动画状态，全都要回到初始值，漏一个就会出现"复用的子弹带着上一发的拖尾"这种诡异现象。第二，池的容量要有上限。无上限的池在极端情况下会吃掉大量内存，建议设一个软上限，超过就真正销毁。第三，获取和归还要走统一入口，不要在业务代码里到处直接操作池的数组，否则很容易出现同一个对象被两处同时持有的 bug。下面是一个简化的池实现骨架，语言用 JavaScript：
class ObjectPool { constructor(factory, reset, maxSize = 200) { this.factory = factory; this.reset = reset; this.maxSize = maxSize; this.free = []; } acquire() { const obj = this.free.pop() || this.factory(); obj.__inPool = false; return obj; } release(obj) { if (obj.__inPool) return; // 防止重复归还 obj.__inPool = true; this.reset(obj); if (this.free.length < this.maxSize) { this.free.push(obj); } } }__inPool这个标记是我踩坑之后加的。早期版本没做重复归还保护，结果某次逻辑分支里同一个子弹被归还了两次，池里出现两个引用指向同一对象，取出来之后两发子弹互相干扰，排查了大半天。这种防御性标记成本极低，收益很高，建议默认加上。
3. 渲染与更新机制：帧循环里的那些取舍
3.1 渲染后端的抽象：Canvas 与 DOM 怎么共存
Hilo 支持 Canvas 和 DOM 两种渲染方式，这个能力在架构上的意义比表面上大。Canvas 适合大量绘制、像素级控制、复杂特效；DOM 适合文本排版、表单交互、可访问性要求高的场景。一个项目里两种需求同时存在是很常见的，比如游戏主体用 Canvas 画，但设置面板、排行榜用 DOM 做。如果框架只支持一种，你就得自己搭桥，桥搭不好就是两套坐标系、两套事件、两套生命周期，维护成本翻倍。
Hilo 的处理方式是把渲染抽象成一个接口，显示对象不关心自己最终画在哪。这个抽象的关键在于坐标和事件的统一。显示对象的坐标是逻辑坐标，渲染器负责把它映射到具体后端；事件也是先经过框架的统一事件层，再分发给具体对象。这样业务代码写起来是一致的，切换后端或者混用后端时，差异被收敛在渲染器内部。我在一个混合项目里用过这个思路：主场景 Canvas 渲染，弹窗用 DOM，弹窗的定位直接复用显示对象的逻辑坐标，由 DOM 渲染器换算成 CSS 的 left/top，省掉了一套坐标转换代码。
3.2 脏矩形与全量重绘：什么时候该优化
全量重绘就是每帧清空整个画布再重画所有对象，实现简单，但在对象多、画布大的时候很浪费。脏矩形重绘只重画发生变化的区域，理论上能省很多。但我要泼一盆冷水：脏矩形不是银弹。它的前提是你能准确追踪哪些区域脏了，而追踪本身有成本；如果场景里大部分对象每帧都在动（比如满屏粒子），脏区域很快覆盖全屏，优化收益趋近于零，反而多了一层计算开销。
我的经验判断是：静态背景加少量动态元素的场景（比如棋牌、解谜、UI 密集的界面），脏矩形收益明显；全屏高频动画的场景（跑酷、弹幕），老老实实全量重绘，把精力放在减少绘制调用上更划算。Hilo 的架构没有强制某一种，渲染器接口留出了实现空间。如果你要自己做脏矩形，记得处理一个边界情况：对象移出旧位置时，旧位置所在的区域也要标记为脏，否则会留下残影。这个"旧区域"的追踪是脏矩形实现里最容易漏的地方。
3.3 更新钩子的粒度：每帧都更新所有对象合理吗
舞台每帧遍历所有显示对象调用更新钩子，这个做法在对象数量上千之后会成为负担。优化方向有两个。一是按需更新，给显示对象加一个"是否需要每帧更新"的标记，静态对象跳过更新逻辑，只参与渲染。二是分层更新，把更新频率不同的对象分到不同的更新组，比如背景层每三帧更新一次，前景层每帧更新。这两种优化都不需要改框架核心，在业务层包一层调度即可，这也是 Hilo 架构留出扩展点的价值体现。
不过要小心过度优化。我见过一个项目，为了省更新开销，把更新频率做成可配置的，结果配置项散落在十几个地方，调一次行为要改一堆参数，最后没人搞得清某个对象到底多久更新一次。优化的前提是可观测，加优化之前先有性能数据，加完之后要有对比，别凭感觉。
4. 资源管理与加载：别让加载成为扩展性的短板
4.1 加载队列的设计：并发、优先级与失败重试
资源加载看起来是个体力活，其实架构设计空间不小。Hilo 的加载队列支持并发加载，但并发数不是越大越好。浏览器对同域名并发连接数有限制，开太多反而互相排队，还占内存。我的经验值是图片资源并发 4 到 6 个比较稳，音频可以少一些。更重要的是优先级，首屏必需的资源（比如 loading 图、主界面背景）要优先加载，非首屏的（比如后续关卡的图集）可以延后甚至懒加载。加载队列如果不支持优先级，所有资源一视同仁地排队，首屏体验就会被拖累。
失败重试也是必须考虑的。网络抖动导致某张图加载失败，如果不重试，游戏里就会出现空白贴图。重试策略建议做指数退避，第一次失败等 500 毫秒，第二次等 1 秒，第三次等 2 秒，重试三次还失败就走降级逻辑（用占位图或者提示用户）。这里有个细节：重试要区分错误类型，404 这种资源不存在的错误重试多少次都没用，直接失败；超时和网络错误才值得重试。
4.2 缓存与释放：内存不是无限的
资源加载进来要缓存，避免重复请求，但缓存不能只进不出。一个有多关卡的游戏，如果每关的图集都缓存着不释放，内存会一路涨上去，低端机上迟早崩。Hilo 的资源层提供了缓存机制，释放策略需要业务层来定。我的做法是给资源打上"引用计数"或者"所属场景"的标签，场景切换时释放不再被引用的资源。引用计数更精确但更容易出错（漏减一次就永远释放不掉），按场景释放更粗放但更安全。中小项目我推荐按场景释放，简单可靠。
释放的时候要注意纹理和 DOM 引用的清理。图片对象释放后，如果还有显示对象持有它的引用，渲染时可能报错或者画出空白。稳妥的做法是释放前先确保没有显示对象在使用，或者用弱引用加存活检测。这块没有银弹，靠的是清晰的资源生命周期约定。
4.3 图集与按需加载：减少请求数的实操
小图单独加载会产生大量请求，每个请求都有开销。图集把多张小图打包成一张大图，一次请求搞定，还能减少纹理切换。Hilo 的架构对图集是友好的，显示对象通过指定图集里的区域来绘制。打包图集时有个经验：把同时出现的图放一起，比如同一个界面的按钮、图标打成一个图集，避免一个界面要加载好几个图集。另外图集尺寸别超过 2048×2048，超过之后部分低端设备的纹理支持会出问题。
按需加载则是另一个维度。不是所有资源都要在启动时加载完，把资源按场景或功能模块分组，进入某个场景前再加载对应的组，启动会快很多。代价是场景切换时可能有短暂等待，需要用过渡动画或者预加载来掩盖。这个取舍取决于你的项目更看重启动速度还是切换流畅度，没有标准答案。
5. 扩展点设计：框架留的口子怎么用才不挖坑
5.1 继承扩展与组合扩展的边界
Hilo 主要通过继承来扩展显示对象，但继承不是唯一手段，也不总是最好的手段。继承适合"是一种"的关系，比如"按钮是一种显示对象"；组合适合"有一个"的关系，比如"角色有一个血条"。滥用继承的典型症状是继承链越来越深，改一个基类行为影响一大片。我的建议是继承链控制在三层以内，超过三层就考虑用组合或者把能力抽成独立的系统。
组合扩展在游戏里特别有用，因为游戏对象往往是多个能力的叠加。一个敌人可能有移动能力、攻击能力、受击闪白能力、死亡掉落能力，这些能力如果都做成基类方法，基类会爆炸；做成独立的能力对象，按需挂载，就灵活得多。Hilo 的显示对象可以挂载任意自定义属性，这给组合扩展留了口子。你可以定义一个能力接口，约定attach、update、detach三个方法，显示对象持有一个能力列表，更新时遍历调用。这套模式在不少游戏框架里都有影子，实现不复杂，收益很大。
5.2 事件系统的扩展：自定义事件与冒泡
事件系统是框架里最容易被忽视、又最影响业务写法的一块。Hilo 的事件机制支持自定义事件和冒泡，这意味着你可以在显示对象树上做事件委托，比如给一个容器挂点击监听，容器内所有子对象的点击都能被捕获。这个能力对 UI 密集的项目非常关键，否则每个按钮都要单独绑事件，解绑还容易漏。
扩展事件系统时要注意两点。第一，事件对象的复用。高频事件（比如每帧的移动事件）如果每次都 new 一个事件对象，GC 压力不小，可以用对象池复用事件对象，但要注意在分发完成后重置，避免上一个监听者修改的字段影响下一个。第二，冒泡的终止。子对象处理完事件后如果不想让它继续冒泡，要能阻止，否则父容器的监听会被误触发。这两个点在实现自定义事件类型时都要考虑到。
5.3 插件化：把可选能力做成独立模块
一个框架要长期演进，可选能力最好做成插件，而不是塞进核心。Hilo 的架构允许你把调试工具、性能面板、场景编辑器这类东西做成独立模块，按需引入。插件化的好处是核心保持精简，插件出问题不影响主流程，团队里不同人维护不同插件也不会互相干扰。设计插件接口时，关键是定义清楚插件能访问什么、能修改什么。访问范围太窄插件没用，太宽又等于没有封装。我的经验是给插件开放"只读的舞台引用加受控的注册接口"，插件通过注册接口往舞台的生命周期里挂钩子，而不是直接改舞台内部状态。
6. 实操中的常见问题与排查实录
6.1 帧率抖动与卡顿的排查路径
帧率问题排查最忌讳瞎猜。我的固定流程是：先确认是持续低帧还是周期性抖动。持续低帧通常是绘制或更新太重，用性能面板看每帧耗时分布，定位到具体阶段；周期性抖动多半和垃圾回收或者资源加载有关，看内存曲线有没有锯齿。定位到阶段之后，再往下钻：如果是渲染重，看绘制调用次数和画布尺寸；如果是更新重，看对象数量和更新逻辑里有没有昂贵的计算。
一个常见的隐形杀手是每帧创建临时对象。比如在更新逻辑里写new Point(x, y)做坐标计算，每帧几百次，GC 就会周期性触发，表现为规律性卡顿。解决办法是把临时对象提到循环外复用，或者用基本类型拆开算。这个坑我在早期项目里踩过，当时怎么都找不到原因，后来用内存分析工具才看到每秒产生几万个短命对象。
6.2 事件不触发与坐标错位的典型原因
事件不触发，先查三件事：对象是否可见、是否在舞台树上、事件监听是否绑在了正确的对象上。不可见的对象通常不参与命中检测，这是符合预期的，但有时候开发者把透明度设成 0 以为还能点，结果点不到。坐标错位则多半和变换有关：父节点有缩放或旋转时，子节点的命中检测要用世界坐标，如果框架的命中检测用的是局部坐标就会偏。还有一种情况是画布被 CSS 缩放了，逻辑坐标和屏幕坐标不一致，需要在事件入口做一次换算。
排查坐标问题有个笨办法但很有效：在点击位置画一个临时标记，看标记和实际点击点是否重合，不重合就说明坐标换算有问题，再逐层检查变换。这个方法比盯着代码看快得多。
6.3 内存泄漏的定位与常见泄漏点
内存泄漏在长时间运行的游戏里是致命的。常见泄漏点我列个表，方便对照排查。
| 泄漏点 | 表现 | 排查方法 |
|---|---|---|
| 事件监听未解绑 | 对象销毁后仍响应事件，内存不降 | 销毁时打印监听数量，对比前后 |
| 定时器未清除 | 后台仍在执行，CPU 占用高 | 全局搜索定时器创建，检查清除逻辑 |
| 闭包持有大对象 | 内存持续增长 | 内存快照对比，看大对象引用链 |
| 资源缓存只进不出 | 切换场景后内存不回落 | 监控缓存大小，检查释放逻辑 |
| 对象池无限增长 | 长时间运行后内存爬升 | 给池设上限，观察池大小 |
排查内存泄漏的核心工具是内存快照对比：在操作前后各拍一次快照，看哪些对象数量异常增长，再顺着引用链找到持有者。这个过程需要耐心，但比盲改有效得多。
6.4 跨端适配的坑：不同设备的渲染差异
HTML5 游戏要跑在手机、平板、桌面浏览器上，渲染差异是绕不开的。高分屏上如果没做设备像素比适配，画面会糊；不同浏览器的 Canvas 实现有细微差异，某些混合模式或者滤镜效果在部分设备上不生效；触摸事件和鼠标事件的坐标体系也不完全一致。Hilo 的架构在这些方面提供了一些基础支持，但适配策略还是要业务层定。
我的建议是把适配逻辑收敛到一个独立的模块里，统一处理像素比、画布尺寸、坐标换算、输入归一化。业务代码只面对逻辑坐标和统一的输入事件，不直接碰设备差异。这样换设备或者加新平台时，改动集中在一处。适配模块里最容易被忽略的是安全区域，全面屏设备有刘海和圆角，UI 贴边可能被遮挡，需要留出安全边距。
7. 我个人的几点实操体会
做这类框架的架构分析和实际使用，我最大的体会是：扩展性不是设计出来的，是约束出来的。Hilo 之所以扩展性好，不是因为它加了多少功能，而是因为它克制地划定了每层的边界，并且坚持单向依赖。你在自己的项目里套用这套思路时，最重要的不是照搬它的类结构，而是学会问自己：这个改动会影响几层？依赖方向有没有被打破？如果答案是"会影响很多层"或者"依赖反了"，那就说明边界没划好，该停下来重新设计。
第二个体会是关于"提前规划扩展点"的度。规划太少，后期改不动；规划太多，前期全是空架子，还容易过度设计。我的经验是只规划那些确定会变的点，比如渲染后端、资源格式、输入方式，这些几乎每个项目都会遇到差异；至于具体的业务能力，等真正需要时再抽，别为了"以后可能要用"提前造一堆抽象。空抽象比没有抽象更害人，因为它会误导后来的人以为那里有东西。
第三个体会是性能优化要建立在测量之上。我见过太多团队凭直觉优化，结果优化了不痛不痒的地方，真正的瓶颈还在。加任何优化之前，先有基线数据；加完之后，有对比数据；没有数据支撑的优化，宁可先不做。框架的架构给了你优化的空间，但用不用、怎么用，得看你的项目实际跑出来的数据。
最后分享一个我在多个项目里验证过的小技巧：给框架的每个核心层写一个极简的冒烟测试，比如舞台能不能正常驱动一帧、显示对象能不能正确计算世界坐标、资源能不能加载并释放。这些测试跑起来只要几秒钟，但能在你改动架构时第一时间发现破坏性变更。架构越复杂，这种轻量测试的价值越大，因为它保护的是"扩展性"本身——你敢于改，是因为你知道改坏了能立刻发现。
