HTML5游戏开发走到一定规模之后，真正卡住人的往往不是玩法逻辑，而是框架层能不能扛住不断叠加的模块、不断膨胀的资源、以及不同运行环境之间的差异。我见过不少团队，前期用一套轻量脚本跑得飞快，等到要接入新的渲染管线、要支持多分辨率适配、要同时管理几十个场景和上百个资源时，代码就开始互相打架，改一处崩三处。Hilo 这个框架之所以值得单独拿出来聊，就是因为它在设计之初就把“可扩展”当成第一目标，而不是事后打补丁。这篇内容我会从架构拆解的角度，把 Hilo 的分层思路、模块机制、渲染抽象、资源管理和扩展点逐一讲透，适合已经能写游戏逻辑、但想搞清楚框架底层怎么组织的中高级开发者，也适合正在选型、想判断一个框架能不能长期支撑项目的技术负责人。读完之后你应该能自己判断：哪些设计可以直接抄，哪些地方需要按项目实际情况改造，以及扩展一个新模块时到底该往哪一层插。

1. 先搞清楚Hilo要解决的扩展性难题

在动手拆架构之前，得先明白一个HTML5游戏框架在“扩展性”这件事上到底面临哪些真实压力。很多人以为扩展性就是“能加功能”，其实远不止。真正的扩展性压力来自四个方向：模块数量增长带来的耦合压力、渲染目标多样化带来的抽象压力、资源规模膨胀带来的管理压力，以及运行环境差异带来的适配压力。Hilo 的架构设计基本就是围绕这四类压力展开的，理解了这个前提，后面看它的分层和模块机制才不会觉得是在看一堆无关的类。

1.1 模块耦合：为什么“能加功能”不等于“好扩展”

一个框架最开始往往只有渲染和事件两件事，代码写在一起也没什么问题。但当你要加动画系统、加物理、加音频、加场景管理、加资源加载器时，如果这些模块之间是直接互相引用的，那每加一个模块，原有模块的依赖图就复杂一分。举个具体的场景：动画系统需要知道当前帧的时间，渲染系统也需要知道当前帧的时间，如果两边各自去读系统时钟，看起来解耦了，实际上时间源不统一，动画和渲染就会不同步。Hilo 的做法是把这类“跨模块共享的基础能力”收敛到核心层，模块之间通过核心层提供的能力间接协作，而不是点对点直连。这就是它控制耦合的第一条原则：共享能力下沉，业务模块横向隔离。

我在实际项目里踩过一个很典型的坑：早期为了图快，让场景管理模块直接持有渲染器的引用，结果后来要换渲染后端时，场景管理里散落着大量渲染器特有的调用，改起来牵一发动全身。Hilo 把渲染抽象成统一的接口层，场景管理只跟接口打交道，换后端时上层几乎无感。这个设计看起来只是多了一层，但它把“变化点”隔离在了一个可控范围内，这正是扩展性的核心——不是让变化不发生，而是让变化的影响范围可预测。

1.2 渲染目标多样化：一套逻辑要跑在Canvas和WebGL上

HTML5游戏的渲染后端选择从来不是一成不变的。2D休闲游戏用 Canvas 2D 足够，但一旦要上粒子特效、大量精灵批处理，WebGL 的优势就出来了。问题在于，如果游戏逻辑层直接调 Canvas 的绘图API，那想切 WebGL 就等于重写。Hilo 在这块的思路是定义一层渲染抽象，把“画什么”和“怎么画”分开：上层描述绘制意图（比如画一个带纹理的矩形、设置变换矩阵），下层由具体的渲染实现去落地。这样同一套游戏逻辑，理论上可以跑在不同的渲染实现上。

这里有个容易被忽略的细节：抽象层设计得不好，反而会成为性能瓶颈。比如每次绘制都创建临时对象、每帧都做大量接口转发，抽象的成本就吃掉了收益。Hilo 在抽象层里对高频路径做了对象复用和调用收敛，这一点在拆源码时值得重点看——抽象不是免费的，好的抽象会把开销控制在可接受范围内。我在做类似抽象时的一个经验是：把每帧调用次数最多的那几个方法单独拎出来做性能剖析，确保它们的转发成本足够低，低频的配置类接口则可以适当放宽。

1.3 资源规模膨胀：从几张图到几百个资源的治理

小项目里资源加载就是几行代码的事，但资源一多，问题就来了：加载顺序、依赖关系、内存释放、重复加载、加载进度聚合，每一项都能让代码迅速腐化。Hilo 把资源管理做成独立模块，核心是“资源描述 + 加载队列 + 缓存”三件套。资源用统一的描述结构声明，加载器按队列调度，加载完成的资源进缓存供复用。这个结构的好处是，新增一种资源类型（比如从图片扩展到音频、字体、图集）只需要注册新的解析器，而不用改动加载调度逻辑。

我特别想强调资源释放这块。很多框架只管加载不管释放，项目跑久了内存一路涨。Hilo 的资源管理提供了显式的释放入口，但释放时机需要业务层自己把握——框架能给你工具，但不能替你做决策。实际项目里我的做法是给资源打上“场景归属”标记，场景切换时批量释放不属于新场景的资源，同时保留一份全局常驻资源清单。这个策略配合框架的缓存机制，基本能把内存控制在稳定区间。

1.4 环境差异：同一份代码要面对不同设备和浏览器

移动端和桌面端的差异、不同浏览器对API的支持差异、屏幕尺寸和像素比的差异，这些如果散落在业务代码里处理，会非常难维护。Hilo 把环境相关的适配收敛到少数几个入口，比如舞台尺寸的设定、像素比的换算、输入事件的归一化。业务层拿到的坐标、尺寸都是经过归一化的，不需要关心底层是触摸还是鼠标、是高分屏还是普通屏。这种“差异收敛”的思路，是框架能跨环境复用的关键。

2. 分层结构：Hilo把哪些东西放在了核心层

拆一个框架，最有效的方式是先看它的分层。Hilo 的分层不是那种画在文档里好看、代码里对不上的分层，而是能直接在目录结构和依赖关系上验证的。大致可以分成四层：核心层（事件、时间、基础工具）、渲染抽象层、资源与场景层、以及面向业务的组件与扩展层。依赖方向是单向的，上层依赖下层，下层不感知上层。这个单向依赖是扩展性的地基，一旦出现反向依赖，分层就名存实亡了。

2.1 核心层为什么只保留事件、时间与基础工具

核心层是整个框架里最稳定的部分，它不应该包含任何跟“游戏”强相关的东西。Hilo 的核心层主要提供事件机制、统一的时间源、以及一批基础工具函数。事件机制是所有模块通信的公共语言，时间源保证动画、渲染、逻辑更新用的是同一个时钟，基础工具则处理一些跨模块的通用计算。把这三样放在核心层，是因为它们被几乎所有模块依赖，且自身变化极少。稳定的东西放底层，易变的东西放上层，这是分层设计里最朴素也最有效的原则。

这里有个设计取舍值得说：事件机制到底该不该做得“重”。有些框架的事件系统支持冒泡、捕获、优先级、一次性监听等一大堆特性，功能是强了，但每次派发事件的成本也上去了。Hilo 的事件机制相对克制，聚焦在“订阅-派发”这个核心语义上，把复杂度留给了真正需要它的地方。我在实际使用中的体会是，游戏里绝大多数事件都是简单的通知型事件，过度设计的事件系统反而会增加理解和调试成本。当然，如果你的项目确实需要复杂的事件流，可以在上层再封装，而不是把核心层做重。

2.2 渲染抽象层的接口边界怎么划

渲染抽象层是 Hilo 架构里最需要拿捏分寸的地方。接口划得太细，上层要调一堆方法才能画出一个东西，用起来繁琐；划得太粗，上层又被绑死在特定实现上，失去抽象意义。Hilo 的边界大致是：上层负责组织“绘制单元”和“变换”，下层负责把这些单元真正画到目标上。绘制单元的描述是数据化的，不直接持有绘图上下文，这样渲染实现可以自由决定怎么消费这些数据。

我在参考这个设计做自己的抽象时，总结了一个判断接口边界是否合理的土办法：假设明天要新增一个渲染后端，看看需要改动的上层代码有多少。如果只需要实现新的后端、上层零改动，说明边界划对了；如果上层要跟着改一堆调用，说明抽象漏了。另一个办法是看接口里有没有出现特定后端的专有概念，比如接口参数里冒出某个只有 Canvas 才有的对象，那就是抽象没做干净。

2.3 资源与场景层如何承接“规模”

资源层和场景层是直接面对“规模压力”的两层。资源层负责加载、缓存、释放，场景层负责组织游戏对象、管理生命周期、处理场景切换。这两层放在渲染抽象之上、业务组件之下，位置很关键：它们既要利用下层的渲染能力，又要给上层提供稳定的组织方式。场景层的一个核心设计是“场景即容器”，场景本身不关心自己里面装的是什么，只负责容器的通用职责（添加、移除、更新、渲染调度），具体内容由业务组件填充。这种“容器与内容分离”的思路，让场景层可以复用到各种类型的游戏里。

2.4 组件与扩展层：业务代码应该长什么样

最上层是组件与扩展层，也就是业务开发者主要打交道的部分。Hilo 在这一层提供了基础的显示对象、常用的交互组件，以及一套扩展机制。业务代码的理想形态是：继承或组合框架提供的基础对象，通过注册扩展来增加能力，而不是去修改框架源码。这一点非常重要——能通过扩展解决的问题，绝不去改框架源码，否则框架升级时你的修改就全丢了。扩展层的设计目标就是让“加能力”这件事有正规入口。

3. 模块机制：新增一个能力到底往哪插

理解了分层，接下来最实际的问题就是：我要加一个新能力，比如一个粒子系统、一个寻路模块、一个存档系统，到底该往哪一层插、怎么插才不破坏原有结构。Hilo 的模块机制给了几个明确的插入点，选对了插入点，扩展就是加法；选错了，扩展就变成对原有代码的侵入式修改。

3.1 扩展点的三种类型与选择依据

从实践角度看，Hilo 的扩展点大致可以归为三类：能力型扩展（给已有对象增加新方法或新行为）、系统型扩展（新增一个独立运转的子系统，比如物理、音频）、资源型扩展（新增一种资源类型的加载与解析）。这三类的插入位置完全不同。能力型扩展通常通过混入或继承基础对象来实现；系统型扩展作为独立模块挂在主循环或场景上；资源型扩展则注册到资源管理器。

选择依据其实很直接：看你的能力是“依附于某个对象”还是“独立运转”。粒子效果如果只是某个显示对象的附属表现，那算能力型；如果粒子系统要独立管理自己的更新和渲染批次，那更接近系统型。我见过有人把本该独立的音频系统硬塞进显示对象里，结果音频的生命周期跟显示对象绑死，对象一销毁音频就断，非常别扭。先判断能力的归属，再决定插入点，这一步想清楚了，后面写代码会顺很多。

3.2 用混入还是继承：一个常被低估的决策

给基础对象加能力时，继承和混入是两条路。继承的优点是结构清晰、能用父类的能力，缺点是层级一深就僵化，而且一个对象只能继承一条链。混入的优点是灵活、可以组合多个能力来源，缺点是能力来源分散、调试时不容易追踪某个方法到底从哪来。Hilo 的基础对象设计对这两种方式都留了空间，实际怎么选要看具体场景。

我的经验判断是：如果新能力和对象是“is-a”关系（比如一个特殊的精灵就是一种精灵），用继承；如果是“has-a”或“can-do”关系（比如一个对象“可以被拖拽”“可以被选中”），用混入。拖拽、选中这类交互能力特别适合混入，因为它们可以独立复用到各种显示对象上。但混入用多了要小心方法名冲突，我的做法是给混入的能力加统一前缀，比如拖拽相关的方法都以 drag 开头，降低冲突概率，也方便排查。

3.3 系统型模块如何挂进主循环而不打架

系统型模块最麻烦的地方是“什么时候更新”。如果每个系统都自己去监听帧事件、自己算时间差，多个系统之间的更新顺序就没法保证，容易出现“物理算完了渲染已经画过了”这种时序错乱。Hilo 的主循环提供了统一的更新调度入口，系统型模块应该挂在这个入口上，按注册顺序或显式指定的优先级更新。这样更新顺序是可控的、可预测的。

这里有个实操细节：更新顺序不是随便定的。一般来说，输入处理要在逻辑更新之前，逻辑更新要在渲染之前，渲染之后可能还有后处理。如果你的系统对顺序有要求，一定要显式声明优先级，不要依赖注册的偶然顺序。我在一个项目里就因为两个系统注册顺序在不同入口下不一致，导致偶发的表现异常，排查了大半天才发现是顺序问题。顺序敏感的系统，优先级必须写死，这是血泪教训。

3.4 资源型扩展：注册解析器的完整链路

新增一种资源类型，比如从图片扩展到图集或自定义二进制格式，走的是资源型扩展这条路。完整链路大致是：定义资源描述结构、实现解析器、注册到资源管理器、在加载队列里按类型分发。解析器的职责是把原始数据转成框架能用的资源对象，它不应该关心加载调度，那是管理器的活。这种职责分离让新增资源类型变得很轻——你只需要写一个解析器，调度、缓存、进度这些通用逻辑全部复用。

我在做自定义资源格式时的一个心得是：解析器要能处理“解析失败”的情况，并且失败信息要足够具体。资源加载失败在游戏里太常见了，如果解析器只抛一个笼统的错误，排查起来非常痛苦。我的做法是解析器里对关键字段做校验，失败时带上资源标识和具体原因，这样线上出问题时日志一看就知道是哪个资源、哪一步出的错。

4. 渲染与主循环：扩展性最吃紧的两条链路

如果说分层和模块机制决定了框架“能不能扩展”，那渲染和主循环就决定了框架“扩展之后跑不跑得动”。这两条链路是每帧都在执行的高频路径，任何一点设计不当都会被放大成性能问题。Hilo 在这两块的设计思路，核心都是“把每帧的工作组织得可预测、可裁剪”。

4.1 主循环的更新与渲染分离为什么重要

主循环里把“更新”和“渲染”分成两个阶段，看起来是常识，但真正做到彻底分离并不容易。分离的意义在于：更新阶段的频率和渲染阶段的频率可以不同，逻辑更新可以固定步长保证物理稳定，渲染则跟着显示刷新走。Hilo 的主循环结构支持这种分离，更新和渲染各自有独立的调度。这样做的直接好处是，当设备性能不足时，可以优先保证逻辑更新的稳定性，渲染掉帧对玩法的影响相对可控。

我在实际项目里对固定步长更新有个补充做法：给更新步长设一个上限，防止某一帧卡顿后累积了过大的时间差，导致下一帧要补算一大堆逻辑，反而更卡。这个“时间差钳制”是很多固定步长实现里容易漏掉的细节，漏掉的话在低端设备上会出现明显的“卡一下然后快进”的现象。

4.2 绘制单元的批处理与状态切换成本

渲染性能的大头往往不在“画”本身，而在“切换状态”。每次切换纹理、切换混合模式、切换着色器，都是有成本的。Hilo 的渲染抽象在设计上考虑了绘制单元的组织，让相同状态的绘制可以尽量连续执行，减少切换。这个思路在2D游戏里尤其有效，因为2D游戏的绘制单元往往有大量相同的纹理和状态。

这里有个很实际的优化点：绘制顺序的组织。如果为了减少状态切换而打乱绘制顺序，可能会破坏层级关系（比如背景画到了前景上面）。所以批处理不是简单地“把相同的放一起”，而是在保证正确层级的前提下，尽量让相邻的绘制单元状态一致。我的做法是把场景里的显示对象按层级分组，组内再按纹理排序，这样既保证了层级正确，又在组内拿到了批处理收益。这个平衡点需要根据实际场景调，没有万能公式。

4.3 变换与坐标系统的统一处理

坐标和变换是渲染里最容易出隐蔽bug的地方。Hilo 把变换统一成矩阵处理，显示对象的位移、缩放、旋转最终都归一到矩阵运算，渲染时把矩阵传给下层。统一处理的好处是，嵌套对象的变换可以逐级累乘，坐标转换有统一入口，不会出现“这个对象用了一套坐标、那个对象用了另一套”的混乱。

我在处理坐标转换时踩过的坑是：屏幕坐标、舞台坐标、对象局部坐标之间的转换如果没有统一入口，很容易在事件处理里算错。比如点击事件拿到的是屏幕坐标，要判断点中了哪个对象，就得逐级转换。Hilo 提供了坐标转换的工具方法，业务层应该统一走这些方法，而不是自己手算。自己手算短期看省事，长期看是bug温床。

4.4 渲染后端的可替换性验证方法

验证渲染抽象是否真的可替换，最直接的办法是做一次“假替换”：写一个极简的渲染后端（哪怕只是把绘制调用打印出来），看上层代码能不能不改就跑通。如果能，说明抽象是干净的；如果跑不通，跑不通的地方就是抽象漏了的地方。这个方法我在多个项目里用过，比看文档可靠得多。Hilo 的渲染抽象之所以值得参考，就是因为它的上层逻辑确实可以和后端实现解耦，这个解耦不是嘴上说说，是能在代码里验证的。

5. 资源与场景的规模化治理经验

前面讲了架构和机制，这一节聊点更贴近项目落地的：资源和场景在规模上来之后怎么治理。这部分框架能给的是一套工具和约定，真正决定成败的是使用方式。我把自己在多个项目里沉淀下来的做法整理出来，配合 Hilo 的机制讲，能直接拿去用。

5.1 资源描述结构的设计要点

资源描述结构是整个资源管理的地基，设计得好，后面加载、缓存、释放都顺；设计得不好，处处要打补丁。一个够用的资源描述至少要有：唯一标识、资源类型、来源地址、可选的依赖列表、可选的元数据。唯一标识用于缓存索引和引用，类型用于分发解析器，依赖列表用于处理“图集要先于使用它的精灵加载”这类关系，元数据则留给业务层放自定义信息。

我特别建议在描述结构里预留一个“分组”字段。分组可以是场景名、可以是功能模块名，它的作用是给批量操作提供抓手——批量加载、批量释放、批量查进度都靠它。没有分组字段的话，后期想做“切场景时释放旧资源”就只能靠命名约定去猜，非常脆弱。这个字段加的时候几乎零成本，后期收益巨大。

5.2 加载队列的并发控制与进度聚合

加载队列要处理两个问题：并发控制和进度聚合。并发控制是指同时发起的加载请求不能无限多，否则会拖慢整体、甚至触发浏览器的连接数限制。Hilo 的加载队列支持并发上限配置，这个上限要根据资源类型和网络环境调，图片类可以适当高一些，大文件则要控制。进度聚合是指多个资源的加载进度要能汇总成一个总进度，用于加载界面展示。聚合时要注意按资源大小加权，而不是简单按数量平均，否则一个大文件会让进度条长时间停在某个位置然后突然跳满。

我在做进度聚合时的一个细节处理是：给进度设一个“最小增量阈值”，只有进度变化超过阈值才触发界面更新。因为加载进度回调可能非常频繁，每次都更新界面会造成不必要的重绘。这个小优化在加载大量小文件时效果很明显。

5.3 场景切换时的资源生命周期管理

场景切换是资源生命周期管理的关键节点。我的做法是把资源分成三类：全局常驻（比如通用UI、字体）、场景专属（比如某个关卡的地图和角色）、临时资源（比如一次性特效）。场景切换时，释放上一个场景的专属资源，保留全局常驻，临时资源用完即释放。这个分类策略配合 Hilo 的资源缓存和释放入口，能把内存占用控制在一个可预期的范围内。

这里有个容易忽略的点：释放资源时要确保没有对象还在引用它。如果释放了一个纹理但还有显示对象在用，轻则显示异常，重则报错。我的做法是在释放前做一次引用检查，或者用引用计数的方式管理——资源被引用时计数加一，不再引用时减一，归零才真正释放。引用计数会增加一点管理成本，但对于资源生命周期复杂的项目，这点成本非常值。

5.4 场景容器的职责边界与常见越界

场景作为容器，职责应该清晰：管理子对象的增删、驱动子对象的更新和渲染、处理场景级的生命周期事件。越界的常见表现是场景开始关心“子对象具体是什么类型”“子对象的业务状态”，一旦场景里出现针对特定业务对象的判断逻辑，场景就失去了通用性，复用无从谈起。保持场景“无知”是容器设计的关键——它只知道“我有一批子对象”，不知道“这些子对象是干什么的”。

我在评审代码时判断场景是否越界，会看场景类里有没有出现具体业务类的名字。如果出现了，基本就是越界了。正确的做法是把业务相关的组织逻辑放到业务层，场景只负责通用的容器职责。这个边界守住了，场景层就能在多个游戏、多个关卡之间复用，扩展性自然就来了。

6. 我在扩展Hilo时踩过的坑与应对

架构讲得再漂亮，落地时该踩的坑一个都不会少。这一节我把几个印象深刻的坑拿出来复盘，重点不是告诉你“别踩”，而是把排查链路完整呈现出来，因为排查思路比结论更有复用价值。

6.1 扩展模块与核心事件机制的冲突排查

有一次我给框架加一个自定义的输入手势模块，挂上去之后发现原有的点击事件偶尔会丢失。排查过程是这样的：先确认手势模块本身逻辑没问题（单独测试正常），再确认是不是事件被拦截了（在事件派发处打日志），最后定位到手势模块在处理触摸移动时调用了阻止默认行为，影响了后续点击事件的判定。根因是手势模块和点击判定共享了同一套底层事件，手势模块的“激进”处理干扰了点击。

修复方案不是简单去掉阻止默认行为，而是给手势模块加一个“识别阈值”：移动距离超过阈值才认定为手势并接管事件，阈值以内仍然放行给点击判定。这个案例的教训是：扩展模块介入公共事件流时，一定要有“让路”机制，不能一上来就全盘接管。公共事件流是多个模块共享的资源，任何模块都不应该无条件独占。

6.2 渲染批次被意外打断的定位过程

另一个坑是性能问题：某个场景的帧率明显低于预期，但绘制对象数量并不多。排查时我先用分帧计时定位到渲染阶段耗时异常，再进一步看绘制调用，发现状态切换次数远超预期。追下去发现是场景里混入了一些“透明占位对象”，它们不可见但仍然参与了绘制流程，每次绘制都触发了一次状态切换，把原本可以连续的批次打断了。

解决办法有两个层面：一是让不可见对象在渲染调度时被跳过（框架层面支持可见性判断），二是在业务层面清理掉那些遗留的占位对象。这个坑的启示是：渲染性能问题往往不是“画得太多”，而是“组织得不好”。定位这类问题，看绘制调用序列比看对象数量更有用。

6.3 资源重复加载的隐蔽来源

资源重复加载是个很隐蔽的坑，表现是内存里同一张图有多份、加载次数异常。排查时我在资源管理器的加载入口打了日志，发现同一个标识被请求了多次，而且请求来源分散在好几个模块里。根因是各模块各自判断“我需要这个资源”然后直接发起加载，没有走统一的“先查缓存再加载”的入口。修复方案是把资源获取收敛到一个统一方法：先查缓存，命中直接返回，未命中才进加载队列，并且对“正在加载中”的资源做去重，避免同一资源并发加载多次。

这个坑的通用教训是：共享资源的获取必须有唯一入口。只要允许各模块自己发起加载，重复加载就迟早会发生。收敛入口这件事，越早做成本越低。

6.4 从踩坑反推：什么样的扩展方式最抗腐化

把这几个坑放在一起看，能反推出几条抗腐化的扩展原则。第一，扩展模块介入公共资源（事件流、渲染流程、资源缓存）时，必须有明确的让路和去重机制。第二，扩展模块的状态要和核心状态隔离，不能因为扩展模块的异常影响核心流程。第三，扩展的入口要收敛，避免同一件事有多个入口导致行为不一致。这三条原则不针对某个具体框架，而是任何框架做扩展时都适用的底层纪律。Hilo 的架构之所以扩展性好，很大程度上就是因为它把这些纪律固化在了分层和模块机制里，让开发者“想犯错都没那么容易”。

7. 判断一个游戏框架扩展性是否够用的自检清单

聊了这么多 Hilo 的设计，最后落到一个更普适的问题：拿到任何一个HTML5游戏框架，怎么快速判断它的扩展性够不够用。我整理了一份自检清单，都是能通过看代码或做小实验验证的，不需要通读全部源码。

这份清单里的每一项，我在实际选型和评审中都用到过。其中“渲染是否可替换”和“资源获取是否收敛”这两项最能快速暴露问题，建议优先做。一个框架如果连假后端都跑不通，说明抽象没做干净，后期换渲染方案的成本会非常高；资源获取如果到处散落，规模一上来必然出重复加载和内存问题。

需要说明的是，这份清单不是要求框架每项都满分，而是帮你判断“短板在哪、能不能接受”。没有完美的框架，只有匹配项目阶段的框架。小项目阶段，某些项不达标也能跑；但如果你预期项目要长期迭代、模块会持续增加，那这些项就是必须守住的底线。Hilo 的架构价值，恰恰在于它把这些底线做进了设计里，而不是留给使用者自己去补。