1. 引擎基础架构到底在解决什么问题
1.1 一个游戏循环让所有模块有了“呼吸节拍”
我第一次真正理解引擎基础架构，不是从文档里读懂的，而是被一个实际项目逼出来的。当时我在维护一版自研引擎，渲染、资源、物理、脚本四个模块各自都能跑，但一合到一起就频繁出问题：模型加载多了卡顿、物理抖动、热更脚本后内存涨得离谱。排查到最后，几乎所有毛病的根源都指向同一个地方——模块之间缺一个统一的“节奏调度者”。
这个“节奏调度者”就是游戏主循环。引擎里最底层的骨架，本质上就是回答三个问题：每一帧要做什么、按什么顺序做、做完之后如何把结果交给下一个模块。你可以在网上找到无数渲染管线、粒子系统、动画状态机的教程，但这些东西都是寄生在引擎基础架构之上的。没有一套清晰的模块边界和帧流程，RE提醒我，再好的渲染特性也只能在混乱中勉强运行。
游戏循环之所以重要，是因为它给了所有模块一个可预测的执行上下文。比如物理系统需要一个固定时间步长来保证稳定性，动画系统需要知道当前帧的时间增量，资源系统希望避开渲染提交的那些关键时间段去做异步流送。这些需求如果没有一个统一的循环去统筹，只靠各模块自发协调，复杂度会指数级上升。我见过不少团队死在“先写玩法、后补框架”的路子上，游戏感觉跑得动，但一旦需要加玩法、加场景、加网络，每次改动都要牵动全局。
1.2 分层、解耦、可插拔：架构的三个关键词
引擎基础架构的设计目标，我一直用三个词来概括：分层、解耦、可插拔。
分层指的是按照依赖方向把代码分成不同层级。最底层是平台抽象，比如窗口创建、输入、文件系统、时钟；中间层是核心系统服务，比如内存管理、任务调度、日志断言；再往上才是资源、渲染、场景、物理、音频、脚本等功能模块。层级之间存在明确的依赖方向，不允许上层反向依赖底层。
解耦指的是功能模块之间不直接相互调用。比如场景模块不应该直接调用渲染模块的某个具体函数，而是通过提交场景数据、生成渲染指令的方式来交互。我常用的设计是“场景模块产生描述，渲染模块消费描述”，两者之间只存在数据契约，不产生函数级依赖。
可插拔则是说任何一个模块都可以被替换、删掉或者用新的实现顶替。要做到这一点，模块对外暴露的必须是接口或抽象基类，而不是一堆公开全局函数。一个很典型的例子就是物理引擎：你把 Bullet 换成 PhysX 的时候，如果游戏逻辑代码里到处都是btRigidBody的指针，那基本等于要重写一遍游戏玩法层。可插拔不是给架构师看的洁癖，它是真实的开发效率保障。
1.3 为什么基础架构必须走在业务功能前面
新人很容易犯一个错误：先把场景编辑器、模型导入、材质调校这些“看得见”的功能做出来，基层架构却被放到后面“有空再说”。我在至少三个团队里见过这种推进顺序，结局几乎一样——每当功能越堆越多，重构成本就越来越高，最后整个引擎陷入一个“不敢改、改不动、延期靠加班”的死循环。
基础架构走在业务功能前面，不是一种流程上的执念，而是因为业务功能一旦写进代码库里，就天然地固化住了底层接口的形态。举个例子，如果你的玩家角色代码依赖了场景查询函数的返回结构，那么场景模块想换成更高效的空间索引实现时，就要先考虑怎么兼容所有已经写好的业务代码。如果场景查询从诞生就是基础架构的一部分，你反而可以为了性能不断优化其内部结构，而不用打扰上层。
所以我的经验是，任何新项目，哪怕只是打算做一个很小的技术Demo，第一周也应该花掉至少三分之一的时间把主循环、模块注册表、资源加载框架、日志系统和配置系统这几根骨架立起来。这些骨架可能只占整体代码量的百分之五，但它们决定了后续所有功能代码的“落点”。
2. 模块划分：引擎的骨架结构
2.1 核心层、功能层、工具层：三种粒度的代码归属
引擎的基础架构，我习惯把它分成三个粒度去理解：核心层、功能层、工具层。这三层不是物理目录里的三个文件夹，而是代码依赖关系上的三个同心圆。
核心层包含所有模块都要用到的基础设施。这一层不依赖任何业务逻辑，里面是内存分配器、容器、数学库、日志、断言、配置系统、文件系统抽象、平台抽象层。核心层的特点是：稳定性要求最高，改动影响面最大，代码必须像外科手术一样谨慎。
功能层指渲染、场景、资源、物理、音频、动画、网络这些引擎能力。每个功能模块之间尽量互不依赖，或者只做极有限的单方向依赖。比如动画模块可以知道骨骼资源的格式，但不需要知道渲染模块怎么提交DrawCall。
工具层是跑在引擎最外围的东西，包括编辑器工具、资源导入管线、构建打包脚本、性能分析插件等。这一层能访问功能层，但不能反过来。分层最大的价值是给你一个“责任边界”：当你发现一个Bug出现在工具层，你不至于需要去排查数学库的代码；当你修改核心层容器时，你也能评估出哪些工具会受影响。
2.2 渲染、资源、场景、物理、脚本：五大模块的边界到底划在哪
我见过很多架构混乱的引擎，问题常常出在模块边界不是按领域划分，而是按实现工具划分。
拿渲染和场景来说，正确边界应该是：场景模块负责维护游戏世界的对象关系、空间变换、空间索引和剔除结果；渲染模块负责接收场景模块提交的渲染指令，做GPU资源管理、Shader绑定、绘制排序和命令提交。如果你在场景节点的类里直接存放了某个渲染API的Mesh指针，那这两个模块就算彻底粘在一起了。
资源模块的地位比较特殊，它属于“服务型模块”，几乎所有其他模块都要向它请求资源。它的边界在于：资源模块只负责资源的加载、缓存、生命周期和格式转换，它不关心这个资源用于渲染还是播放音频。渲染模块需要拿到一张贴图时，它用资源句柄来引用，而不是直接读磁盘文件。
物理和场景的边界是另一种典型的易混区。很多初学者会把物理刚体直接当作场景对象来管理，导致场景系统里到处都是物理引擎的类型。正确姿势是场景模块持有自己的逻辑对象，物理模块通过一个适配组件把自己的刚体状态同步到场景对象上。这样将来换物理引擎，场景层和业务层代码几乎不用变。
脚本模块则有一点特殊，它通常不是独立功能，而是充当各模块之间的粘合剂。脚本系统通过绑定接口把C++层能力暴露给脚本语言，它必须位于所有功能模块之上。边界划分的一个实用判断标准是：如果你能在不修改其他模块的前提下把某个模块整个替换掉，那说明边界画了。
2.3 模块之间通信：直接调用、事件系统、数据总线
模块边界确定后，下一件事就是模块之间怎么说话。我常用的方式有三种：直接接口调用、事件系统、共享数据总线。
直接接口调用适合“同步且有明确返回值”的场景。比如场景模块调用资源模块的异步加载接口拿一个资源句柄，这种调用关系是稳定的、可预测的，运行效率也最高。缺点是一旦接口签名变更，所有调用方都要跟着改。
事件系统适合“不知道谁会关心”的场景。典型例子是玩家角色死亡时，UI系统、成就系统、音效系统、任务系统都可能要响应。如果让角色模块直接去调用每个系统的对应方法，就失去了解耦意义。用事件系统把这些通知广播出去，新增关注者不需要改动已有代码。我建议事件数据用只读结构体，避免事件处理顺序引起数据竞争。
共享数据总线是最高阶的解耦方式，适合大数据量和高频更新的情况。比如每个帧的输入状态，可以用一个全局可读的结构体来表示，所有模块都去读它，但谁也不允许写它。渲染模块要拿当前相机的变换矩阵，也是通过统一读共享数据而不是调用场景模块的函数。这一层的核心规则是：发布者和消费者之间绝对不能偶合到生命周期，否则总线就退化成了一堆全局变量。
我之前在项目里给模块通信定了一条简单规矩：同行模块之间尽量用数据总线，跨层级模块之间用接口调用，不确定的广播场景一律走事件系统。这条规矩不是理论推导出来的，而是踩了无数“到处直接调用全局函数最后查不清谁改坏了数据”的坑之后沉淀下来的。
3. 主循环与帧流程：引擎心脏怎么跳
3.1 固定时间步长与可变步长的取舍
主循环最核心的一个决策，是选择可变的帧时间步长还是固定的物理步长。很多人写第一版循环时都是这个套路：
while (running) { float dt = clock.now() - lastFrame; update(dt); render(); lastFrame = clock.now(); }看起来自然，但实际运行起来你会发现问题一大堆：帧率波动时，物理系统在这个dt下的表现会不稳定，严重时物体会“穿墙”；动画曲线在不同帧率下会产生不同的插值结果；网络同步也会因为本地时间步长浮动而变得困难。
正确解法是把“逻辑更新”和“渲染展示”拆开。逻辑层使用固定时间步长，典型值是 1/60 秒或 1/120 秒。渲染层则每帧读取当前的真实时间增量，做一个插值，把最近两帧的逻辑状态平滑展示出来。这是很多成熟引擎的通用做法，也是主循环架构里最值得先落地的一处设计。
3.2 一次完整帧里到底发生了什么
以60FPS为例，每帧预算时间是16.67毫秒。一次完整帧的主循环里，引擎会按顺序做这些事：
- 处理操作系统消息，比如窗口大小变化、输入事件。
- 读取键盘鼠标手柄输入，写入本帧的输入状态缓冲区。
- 更新脚本驱动的游戏逻辑，通常是调用每个实体上的
Update方法。 - 以固定步长执行物理模拟，如步长积压时间足够，就补跑一步或多步物理。
- 更新动画状态机、采样骨骼动画并计算蒙皮矩阵。
- 进行场景遍历、视锥剔除和遮挡剔除，生成可见对象列表。
- 收集需要绘制的所有渲染对象，按材质、深度、距离等因素排序。
- 生成渲染命令缓冲，提交到渲染线程或GPU。
- 提交渲染帧并展示到屏幕，也叫Present。
每一步都有对应的预算参考。输入处理和事件消息最便宜，通常可控制在0.5毫秒以内；物理模拟在步长合理时应该控制在2到3毫秒；渲染占大头，6到8毫秒是常见范围；如果脚本系统写得不克制，在大型场景里轻松吃到4毫秒以上。
总预算不够用时不能平均压缩，而是应该有明确的优先级：输入不能丢，物理不能跳太多，渲染决定帧率下限，脚本最优先被降级。这个优先级顺序写进主循环代码里，而不是依赖程序员的自觉，才能保证长期不退化。
3.3 消息泵、事件分发逻辑与多平台适配
跨平台引擎的主循环有一层容易被忽视的复杂度：不同平台对“每一帧的输入事件”推送方式不一样。Windows的消息循环、移动端的生命周期回调、主机平台的独占输入处理，它们的时序都不一致。
所以在引擎基础架构里，我会在平台层包一个统一的“消息泵”接口。平台层负责把底层操作系统事件翻译成引擎内部事件结构，然后在主循环的每个帧开始时统一分发。游戏逻辑永远不需要关心自己跑在哪个平台上，它只处理统一格式的输入事件。
这里有个实操经验：输入事件应该做“帧间累积”。也就是说，同一帧内到达的多个鼠标移动事件，要么合并成最新位置，要么累加成总位移，不要一次性派发多个事件给逻辑层。否则玩家在一台高刷新率的机器上快速移动鼠标时，逻辑层的输入响应节奏会跟另一台低刷新率机器完全不同。
多平台适配还有一个容易被忽略的点：时间源的统一。Windows上推荐用QueryPerformanceCounter，移动端用getTimeNanos之类的单调时钟，主机平台各不相同。引擎启动时就选好一个稳定的单调时钟作为全局时间源，所有模块都读它，不要在业务代码里各自调系统时间函数。
4. 资源管理与生命周期：对象生老病死的规则
4.1 同步加载、异步加载与流式加载分别用在什么场景
资源管理看着像“读文件返回指针”，但真正做进引擎里，你会发现它是一门生命周期管理学问。我通常把加载方式分成三种：同步、异步、流式。
同步加载用于启动阶段和需要立即拿到数据的场景，比如初始化时加载必选的引擎配置、基础Shader、默认材质。它实现最简单，但卡顿也最明显，因为一次磁盘IO可能拖掉几十毫秒甚至几百毫秒。
异步加载是游戏运行期的主路径。调用方发出加载请求后立即拿到一个句柄，资源在后台线程加载完成后通过回调或状态轮询通知调用方。这里要注意：GPU资源需要在主线程或渲染线程里创建，因为大多数图形API不允许后台线程直接调用。我惯用的做法是后台线程只做文件读取和解压，拿到原始字节后投递到渲染线程完成GPU资源创建。
流式加载适合大地图、无缝世界这种场景。它不是一次性加载整个资源包，而是根据玩家位置动态加载区域块、卸载远处块。流式加载的架构要求资源模块能追踪“哪个块被哪些实体引用”，以及无引用块的回收时机。这一块对内存管理和IO调度压力最大，也是最容易出内存毛刺的地方。
4.2 引用计数与智能指针背后的坑
资源生命周期最常见的实现方式是引用计数，也就是每种资源持有一个使用计数，归零后自动释放。听起来很美，但实际使用中我踩过几个很深的坑。
第一个坑是循环引用。资源A回调里持有了资源B的资源句柄，而B的资源加载回调里又持有了A的句柄，两者永远不会归零。解决办法是引入类似弱引用的机制，句柄区分强引用和弱引用，事件系统里只保存弱引用。
第二个坑是在容器里长期持有资源句柄，导致内存迟迟不释放。比如UI系统把每个界面的贴图句柄缓存到全局列表里，界面关闭了也不移除。看起来只是少量泄漏，但热更新长时间运行后就是几G的内存膨胀。
第三个坑是引用计数在多线程环境下的原子操作开销。如果一个资源的加载完成回调会被多个后台线程触发，每次增减引用都要做原子操作，高频小资源场景下这个开销会被放大。我会在资源句柄的缓存层做批量引用增减，避免高频单次操作。
提示：给资源模块预留一个
debugDump()接口，可以打印当前所有资源引用计数和持有者。排查内存泄漏和资源未被卸载问题时，这是最快的手段。
4.3 热更新与资源版本管理对架构的要求
很多引擎的架构是从单机游戏需求出发设计的，等到需要做线上热更时才发现该改的地方太多。热更新对基础架构的核心要求是：资源和逻辑必须和版本信息绑定，而不是散落在一堆无版本概念的裸文件里。
我会把每个资源包都当成一个带清单的、可寻址的单元。清单里记录了资源ID、版本号、依赖列表和校验值。更新时引擎对比本地的版本清单和远程清单，下载差异部分，然后整体切换资源指向。这样做的好处是回滚容易，坏掉的新版本资源不会污染旧版本。
同时，脚本系统要考虑“热更后旧资源还在被持有”的场景。我习惯在所有加载入口增加一个“全局版本屏障”：每当热更完成，引擎会记录一个版本号，所有后续资源请求都优先加载新版本；旧句柄在引用归零后自然释放，不再被新逻辑获取。这个屏障让热更新对运行中的系统是渐进生效的，而不是一刀切地重启游戏世界。
5. 渲染架构与场景组织：从CPU到GPU的路
5.1 场景管理：空间索引与剔除
渲染架构的真正起点不是GPU，而是CPU上的场景组织。每帧渲染之前，引擎需要回答一个问题：这个场景里几千上万个物体，哪些真的会被相机看到。
答案来自空间索引。小型项目用场景树就够，每个节点挂子节点和局部变换，遍历时同步维护世界矩阵。中大型开放场景则需要更高效的结构：四叉树适用于水平和开阔地形，八叉树适合有垂直层次的空间，室内场景常用BSP树或凸体门户剔除。
有了空间索引之后，再做视锥剔除：把每个空间节点的包围盒和当前相机视锥做相交测试，完全在外的节点整棵跳过。遮挡剔除更进一步，利用GPU深度缓冲或软件光栅化来判断被遮挡的大物体是否真的不可见。
我在项目里常用两层剔除：粗粒度用空间索引快速剔除远离相机的区域，细粒度对剩余物体做包围体测试和遮挡查询。剔除做得好的情况下，渲染场景中可见物体数量可以减少一个数量级，对帧率的提升远比调Shader参数来得显著。
5.2 渲染队列、命令缓冲与批量提交
场景剔除结束后，得到的是可见物体列表。但引擎不能直接按物体顺序去调用DrawCall，因为状态切换会击穿GPU性能。这就是渲染队列要解决的问题。
渲染队列会根据材质、纹理、Shader、深度状态等因素对所有可见物体做排序，把状态变化最小的物体尽量排在相邻位置，减少状态切换。更进一步，同一种材质和网格可以合并成一个实例化批次，用一次DrawCall绘制多个物体。比如场景里上千棵树，合理实例化后可能只需要几十次DrawCall。
命令缓冲则是解决CPU和GPU节奏不匹配的关键。CPU不会在每个DrawCall调用时直接驱动GPU立即执行，而是把绘制指令记录到一个命令缓冲区，攒到合适的时机再提交。这个设计让CPU可以提前准备下一帧的工作，而GPU在处理当前帧提交的命令时不必和CPU同步等待。命令缓冲的另外一个好处是线程安全，渲染主线程可以独立构建命令，而不需要和后台线程相互阻塞。
5.3 CPU与GPU的同步与异步
渲染架构里最影响性能的是CPU和GPU之间的同步点。所谓同步，就是CPU需要等待GPU完成某个操作后才能继续，最常见的是读回GPU渲染结果到CPU内存。这种等待非常昂贵，一次同步可能让整帧卡住几毫秒。所以引擎架构的原则是：尽量消除同步，让CPU和GPU工作在流水线重叠状态。
我常用的具体策略有这么几条：帧缓冲不再复用，而是做成几个缓冲轮流使用；资源上传尽量在帧开始前完成，避免渲染中间突然等待纹理创建；需要GPU回读的数据，比如遮挡查询结果，做延迟两帧再读取；帧尾的Present操作不直接阻塞CPU，而是让硬件交换链自己管理节奏。
这里有个常见误区，就是垂直同步和GPU同步经常被混为一谈。垂直同步只是限制GPU帧呈现速率，但CPU和GPU在工作流水线里的不同步仍然存在。只看帧率数字不够，还要看帧时间分布里的consecutive尖峰。这也是为什么引擎性能分析时都要看帧时间波形而不是平均FPS。
6. 引擎启动与关闭：架构里的隐藏细节
6.1 初始化顺序为什么不能乱
引擎启动看起来是小事，但初始化顺序错了，会让你在运行时遇到各种莫名其妙的问题。我推荐的初始化顺序是这样的：
- 平台层初始化，包括窗口创建、图形API上下文绑定。
- 日志系统与断言系统，这是所有调试排查的基础。
- 核心内存分配器与自定义容器，为后续系统提供稳定的内存环境。
- 线程池与任务调度系统，给异步加载和物理准备并行基础。
- 文件系统与资源系统，此时才能具备加载能力。
- 渲染设备创建与GPU能力查询，然后创建全局渲染状态。
- 场景系统注册，加载基础的默认场景与启动场景。
核心原则是：一个模块初始化时用到的所有依赖，必须已经被初始化完毕。资源系统初始化时肯定会读取配置，所以配置模块要更早；渲染设备初始化时会创建交换链，所以平台层要先完成窗口创建。如果顺序错了，最典型的表现是启动阶段偶发性崩溃，比如多线程任务在资源系统准备好之前就被要了，或者渲染模块在自己的后台线程里访问了未初始化的内存池。
6.2 关闭时最容易暴露的问题
关闭流程比启动更容易暴雷，因为启动是“从无到有”，出问题容易定位；关闭是“从有到无”，涉及所有后台线程、资源句柄、网络连接和GPU资源的回收，任何一环没有处理好都会引发崩溃或者卡死。
关闭流程我总结过一个很痛的教训：应该先停新任务的产生，再处理正在执行的任务，最后进行资源回收。如果你一上来就释放内存池，而此时后台线程还在加载资源，那内存管理器会立刻崩给你看。
推荐的关闭顺序是：暂停接受新的帧更新时间，停止脚本系统的调用，主循环退出；通知所有后台线程完成当前任务并退出；注销各功能模块，渲染模块等待GPU空闲后释放显存资源；资源模块释放缓存和句柄表；最后释放核心层的内存分配器和日志系统。
这里容易忽略的一点是，渲染资源释放和命令提交线程之间的同步。如果命令提交线程还在执行队列，而渲染设备已经卸载了，马上就是访问已释放内存的崩溃。所以我在引擎里会给渲染模块单独做一个“排空命令、等待GPU空转”的阶段，只有这个阶段结束后才允许渲染设备销毁。
6.3 崩溃恢复与自动诊断的架构设计
成熟的引擎基础架构还要考虑一件事：如果游戏运行中崩溃了，怎么留下有效信息。我不太建议依赖外部调试器，因为很多运行环境根本没有调试器可用。
我的做法是给引擎加一个全局崩溃捕获器，在进程级捕获异常时，先把崩溃时正在执行的模块、当前帧号、最近若干条日志以及线程栈保存到文件，再做默认处理。这些信息输出为统一的崩溃转储格式，方便后期用工具解析。
再进一步，引擎可以主动建立“帧生命周期检查点”：每帧开始、物理阶段完成、渲染提交完成、Present前后都写入一个递增的帧状态标记。崩溃恢复时，直接看标记就知道崩在哪个阶段，能省下大量排查时间。这种诊断数据不花多少代码，但对线上问题定位的效率提升是肉眼可见的。
7. 个人复盘：我在引擎改造中踩过的坑
7.1 资源双份内存的教训
有段时间我在做一款接入第三方面部捕捉SDK的项目，发现内存占用一直异常高。查来查去，发现第三方面部SDK在初始化时会自行加载一份模型缓存，而引擎的资源模块通过统一接口加载了同一个模型文件，两份数据都住在内存里，互不知道对方存在。
这个问题的本质是资源管理系统打破了自己的统一入口原则。引擎必须把所有外部SDK的资源加载都收拢到同一个资源管理框架之下，第三方SDK的加载函数不能绕过框架直接读文件。后来我写了一个SDK适配资源层，把第三方SDK的资源请求翻译成引擎内部资源请求，用同一个缓存和引用计数机制管理。
这条教训我后来写进了团队开发规范：任何第三方库接入时，第一件事不是看功能Demo，而是检查它的资源加载路径能不能被我们的资源模块接管。如果接管不了，宁可先用隔离方案，也不能放任各模块自行加载资源。
7.2 物理步长与渲染帧强耦合的后果
早期版本里我图省事，直接把物理更新写进render()的前面，每次渲染帧都调用一次物理Step。结果在复杂场景里暴露了一个严重问题：当渲染帧率从60FPS降到20FPS时，物理的模拟速度也变成原来的三分之一，玩家感觉整个世界都在慢放；反过来在某些帧率飙升的关卡，物理又变得过快。
彻底修复这个问题的方案是前面说的固定时间步长累加器：渲染帧只负责计算“本帧间隔里应该补跑几步物理”，物理循环内部恒定为1/60秒或1/120秒。这个改动让我花了整整一周去调整所有物理调参数据，因为原来的不稳定参数在新机制下全变了。
注意：无论引擎逻辑如何优化，物理步长最好保持恒定。稳定的时间间隔是物理求解器数值稳定的前提，这是连商业物理引擎的官方文档都会反复强调的约定。
7.3 脚本热更引发的“真卡顿”
还有一个很典型的坑，来自脚本层和引擎层的交互方式。我在项目里引入Lua脚本做热更后，测试很快发现，脚本里每帧都会创建很多临时表来传递数据，而Lua的GC会在某帧突然变形，导致游戏出现周期性卡顿。
排查过程很有意思，Lua侧自己看不出问题，只有统计脚本层的每帧GC耗时才发现，临时表创建的频次已经高到每秒几十万次。解决办法是两层并进：引擎侧提供接口，让脚本可以复用对象池或批量写入同一块共享内存；脚本编码规范上明确禁止在每帧逻辑里创建无必要的临时结构。
这里要强调的是，脚本热更本身是好东西，但脚本层和引擎层的每次交互如果都“小而频繁”，帧预算就会被快速侵蚀。尽量把多次小交互合并成一次批量调用，脚本层只做逻辑编排，真正的批量数据处理下放到C++层完成。这个原则至今仍是我评估脚本系统性能的第一个参考。
写完这篇，最后再分享一个我实践里反复验证的小技巧：先不要追求一步到位的完整引擎架构，先把主循环跑通，再让一个带贴图的模型在屏幕上转起来，然后在这个最小框架上逐步迭代。每加一个新模块，都问一遍“它依赖谁、谁依赖它、生命周期由谁管理、坏了怎么查”。这四个问题回答清楚了，引擎基础架构的大方向就不会走偏。后面如果有机会，我打算继续拆各个子系统的实现细节，把这一路踩过的坑都摊开来讲。
