我最早接触游戏逆向时脑子里最大的疑问不是“怎么改”而是“凭什么能改”。一款游戏在我眼里就是个黑盒可为什么别人能一上来就定位到血量地址、能在某个函数入口稳稳断住、能改一条跳转指令让整个判定逻辑反转这个问题不解决后面工具用得越多心里越是发虚。后来把计算机组成原理、汇编、操作系统、编译原理这几块碎片串到一起才明白游戏逆向的底层逻辑其实一句话就能讲透计算机没有秘密只有不熟练。这篇作为系列的第零篇先不谈任何具体工具和操作专门把“逆向工程为什么能做到这些事”背后的底层原理讲清楚适合刚入门的新手也适合那些会点工具但始终觉得根基不稳的朋友。1. 逆向工程的核心本质计算机天然是一本摊开的书很多人第一次接触逆向时很自然地把这个过程想象成“破解密码”。实际上完全不是。逆向工程能成立不是因为黑客掌握某种神乎其神的技巧而是因为计算机从诞生第一天起就注定无法对自己隐藏任何东西。1.1 所有程序最终都是可枚举的指令序列计算机不“理解”语义它只做一件事取指令、执行指令、继续取下一条。无论你用C、C#还是Lua写游戏逻辑最终交给CPU的只是一段按地址顺序排列的机器码。机器码由操作码和操作数组成二进制对人眼不友好但它不是加密而是编码。编码就一定有规则而规则本身就是公开的——Intel和ARM都会发布几千页的指令集手册详细说明每一个字节对应什么操作。反汇编器做的事本质上不是“破解密码”而是拿机器码去查指令手册翻译成人能读的汇编语言。这个过程跟把英文翻译成中文没什么两样区别只在于指令集是机器语言“字典”是固定的。理解了这一点就会发现所谓的“程序不可读”只是错觉。只要你能拿到二进制内容你就等于拿到了一本摊开的书阅读能力高低只是熟练问题不是可能性问题。1.2 数据与代码不分家内存里没有秘密文件冯诺依曼架构有个在今天看来极其关键的设定数据和代码存放在同一个存储空间中。这意味着你在内存里读到的某个数值既可能是角色血量也可能是一条即将被CPU执行的指令这完全取决于CPU的视角。这个设定对逆向者来说是个大利好。程序运行时所有“有意义的东西”——血量、金币、坐标、背包道具ID、函数地址、虚表指针、字符串常量——都真实地存在于内存的某个角落。内存不是保险箱它就像一张极大的网格纸每个格子都有地址而且谁拥有访问权就能从头到尾看个遍。游戏开发者可以在代码层面做各种加密和混淆但最终必须把真实数据放到内存里让程序使用这一步永远绕不过去。这就是所有“找数值”操作的根本立足点。1.3 操作系统的“监视接口”是逆向的最初入口可能有人会问游戏是别人写的程序凭什么我能看到它内部状态答案在于现代操作系统本身就必须提供“查看和修改其他进程内存”的机制。Windows有ReadProcessMemory、WriteProcessMemory、调试APILinux有ptrace更底层的内核模块甚至可以读物理内存。这些接口不是系统漏洞而是操作系统功能的一部分调试器、性能分析器、杀毒软件都在利用它们工作。游戏逆向能起步恰恰是因为游戏运行在一个“允许被检查”的通用操作系统之上。你见过哪台游戏主机能被随便附加调试器因为主机系统根本不给这个权限。而PC游戏只要跑在Windows上它就必须接受这个前提系统为了调试和兼容性留下的能力同样可以被你用来做分析。这套底层逻辑也顺带解释了为什么Linux下有那么多强大的逆向工具——因为Linux的proc文件系统和ptrace机制让进程内幕暴露得更直接。2. 底层原理的三大支柱指令、栈与内存布局说完了大方向接下来进入真正的地基。游戏逆向的一切操作落到最底层都是围绕三件事展开指令、栈、内存布局。把这三根柱子立起来后面所有高深技巧你都能自己推导出来。2.1 指令集机器码从来不是加密只是翻译以x86架构为例机器码最常见形态是“操作码操作数”。随便看一段0x401000: 8B 45 FC mov eax, [ebp-4] 0x401003: 83 F8 64 cmp eax, 100 0x401006: 7C 05 jl 0x40100D第一行的8B 45 FC含义是“把地址[ebp-4]处的值读入eax”第二行是“把eax与100比较”第三行是“如果小于跳到0x40100D继续执行”。如果你同时能知道ebp此时指向的是哪个栈地址你就能顺藤摸瓜推测出这段代码在处理什么逻辑。学习汇编最重要的不是记住每一条指令而是理解几大类别数据传输指令负责移动数据算术逻辑指令负责计算跳转指令负责改变执行流栈操作指令负责函数调用。所有程序无论多么复杂本质上都是这几类指令的组合。你会看到一个有意思的现象游戏中再花哨的技能特效、再复杂的AI逻辑只要被编译成机器码就只剩下这些单调的指令循环。这种“单调”恰恰是逆向能进行的前提——如果指令集设计得毫无规律可循连CPU自己都无法稳定执行更别说被人反推了。2.2 栈与寄存器函数调用就是一部录好的证据链很多人学逆向时对“栈”很头疼其实可以打个生活化的比方栈就像一摞便签纸每调用一个函数就在最上面压一张新的便签记录“我是谁、从哪来、要处理什么临时数据”函数返回就把这张便签撕掉露出下一层的记录。具体到汇编层面函数调用是这样的循环call指令把下一条指令的地址压入栈中跳转到目标函数函数入口通常执行push ebp; mov ebp, esp建立栈帧局部变量则通过修改esp来分配空间返回时leave; ret把栈帧还原并弹出之前存好的返回地址CPU继续执行调用者原来的代码。这个过程对逆向者而言就是一份完整的“证据链”。只要你站在某个函数内部向上追溯栈帧就能清晰地看到“谁调用了它、参数是什么、从哪里来”。即使程序被去除了所有调试符号函数之间的调用关系依然像指纹一样留在栈结构里。以下是我整理的常见调用约定理解了这张表你看到参数不必再瞎猜调用约定参数传递方式栈清理方常见场景cdecl参数从右往左压栈调用者C语言默认许多跨平台代码stdcall参数从右往左压栈被调用者Win32 APIthiscallthis指针经ECX传递参数压栈被调用者C成员函数fastcall前两参数用寄存器其余压栈被调用者x64平台默认约定在x64平台前四个整数参数分别放入rcx、rdx、r8、r9其余参数压栈这套规则是公开且稳定的。所以动态调试时你在调用点之前查看寄存器值基本就能判断出当前函数收到的是什么参数。这就是为什么很多逆向老手可以直接“看汇编猜源码”——不是某种玄学直觉而是调用规律就摆在那里。2.3 虚拟内存与模块加载地址就是地图坐标游戏不是一坨散落的字节而是按模块组织的主程序exe、各种dll每个模块被加载到进程虚拟地址空间中。Windows下的PE格式、Linux下的ELF格式都会在文件头部描述代码段、数据段、资源段的位置操作系统加载时再把这些段映射到内存里的固定位置。这里有一个关键概念虚拟内存。每个进程都拥有独立的地址空间游戏A和游戏B的0x401000不会互相冲突。但在这个进程内部地址是相对稳定的——虽然ASLR地址随机化会让模块基址每次启动都不一样但只要模块加载完成函数与数据的相对偏移就固定了。这意味着你每次启动游戏时某个关键函数不一定在“主模块0x401000”这个绝对地址但它一定在“主模块固定偏移”处。对逆向者来说这就好比你进到一个每次都会重新布局的迷宫但迷宫里的“原点”是固定的所有宝箱跟原点之间的相对位置也是固定的。只要确定模块基址就能照着偏移表一一找到目标。这也是为什么很多分析工具在附加进程后都直接显示“模块基址偏移”的原因。3. 游戏为什么是逆向的“完美样本”把视角收回到游戏本身上来。逆向工程的教材里经常用普通程序当例子但游戏几乎是最好的教学样本。因为它比普通软件更复杂、更动态但又严格遵循程序运行的客观规律。3.1 游戏本质是状态机所有关键信息必须活跃在内存里任何游戏无论单机还是网络本质上都是一个状态机。它必须随时随地知道“我是谁、我在哪、我有什么、我还差多少经验、怪物还剩多少血”。这些状态必须保存在某个地方CPU要计算时就必须能从内存里读到它。理解这一点很多新手常见的困惑就会迎刃而解为什么游戏里的血量值能被直接搜索到因为它必须是一个真实的、内存里存在的数值。开发者可以设计成这样显示层显示100血但内部其实存的是浮点数或者内部值乘以10再显示甚至可以把最终血量放在服务端只下发一个显示值。但只要这个值在本地参与计算、在本地做显示它就必然以某种形式短暂地在内存中活跃。这个“必然”不是开发者能去除的逻辑而是程序运行的基本书页。顺便说个底层细节如果你要找一个放在复杂数据结构里的数值比如在一个用hashmap装载的道具数量直接照固定偏移翻内存是没有意义的因为元素位置由哈希决定。但hashmap底层原理本身也是一张数组加链表/红黑树的物理结构运行时会展开为具体的节点对象。理解容器底层的物理布局能帮你在面对复杂游戏对象时少走很多弯路。3.2 数值扫描原理在必定存在的地方做集合交集很多游戏逆向教程第一课就是“用CE搜索血量数值”。CE原理看起来简单得让人怀疑先搜初始值100得到一堆候选地址打一下让血变成85再搜索85候选地址急剧减少重复两次最终锁定唯一地址。这背后的数学逻辑其实就是集合交集。你第一次搜100时全进程内存里有成千上万个位置恰好是100但不一定是你想要的那个第二次搜85时只有那些“从100变成85”的地址会被保留。经过几轮变化不符合行为特征的地址全部被筛掉。整个过程就像你在一万个房间里找一盏灯先筛出亮着的房间再过一会儿找“亮转暗”的房间再叠加“位置没动但状态变了”这个条件目标自然浮出水面。这里真正的基础支撑是两个事实第一数值有确定的宽度大部分是4字节int和存储格式小端序第二目标数值一定存在于内存中并保持最新值。CE并没有破解什么它只是在帮你做高速集合过滤。理解这个过滤逻辑后你会发现任何可以被“观察到变化”的数据——经验值、金币数、冷却时间——都能用同样的思想去追踪。3.3 从数据反追逻辑硬件断点与“谁改了它”找到数值地址只是第一步逆向的真正枢纽在“找出是谁改写了这个地址”。经典的动态分析思路是找到血量地址后对这块内存下硬件断点设定“写入时触发”。当游戏执行到扣血相关指令时CPU会暂停调试器带你精确地停在那条“罪魁祸首”指令面前。这个能力的底层是什么呢硬件断点利用了CPU调试寄存器DR0-DR3。CPU在每次执行指令时都会检查当前访问的内存地址是否与调试寄存器设置的值匹配匹配就触发异常。这个机制对性能和兼容性负责也是让“断点”能工作在硬件层面的关键。当你停在扣血的指令处接着向上追溯栈和调用者你会发现完整的逻辑链条游戏读到了伤害数值把它与减伤系数相乘再减去目标血量。更重要的是你可以在那个判断跳转的瞬间看清楚整个“生死逻辑”——什么时候允许伤害生效什么时候被判定为闪避什么时候暴击翻倍。这些逻辑全部由CPU按步执行每一步都可供暂停、检查、回溯。CPU可以跑得飞快但它从来不会“一步跨过两行”。4. 编译器的“可预测性”是逆向的隐形帮手有人会觉得源码被编译成机器码之后应该面目全非才对。实际上恰恰相反编译器是逆向者的隐形盟友。它极具规律性的产物是逆向分析能高效进行的重要原因。4.1 源码到汇编的映射非常稳定现代编译器在优化级别固定的情况下对同样的源码结构生成的汇编几乎可以用“标准化”来形容。if-else结构通常被编译成cmp加jcc条件跳转的组合for和while循环通常变成cmp加jcc加jmp的三角结构字符串常量会被集中到只读数据段全局变量放在数据段。这些规律不是某个编译器独有的习惯而是从编译器实现逻辑中必然衍生的结果。举个例子下面这段C代码if (player.hp 0) { game_over(); }在Release模式下你几乎总能在反汇编窗口里看到类似这样的产物mov eax, [player_hp_addr] test eax, eax jg continue_label call game_over continue_label:test eax, eax; jg是“判断大于0”的经典组合。有经验的逆向者看到这种片段几乎可以立刻“脑补”出源码里的比较逻辑。这种能力不是背出来的而是建立在对“编译器如何翻译控制流”的理解之上的。4.2 调用约定与符号缺失下的结构推断Release版本通常会被去除符号包括函数名、变量名但这并不意味着结构彻底消失。程序中的函数数量、调用关系、函数大小、导入导出表这些结构信息仍然是肉眼可见的。在没有符号的情况下逆向者通常靠三个视角来重建结构。第一个视角是函数边界函数入口序言和出口结语leave; ret是明显的标识按图索骥就能切开成千上万的函数区间。第二个视角是导入表一个PE文件导入哪些API可以告诉你这个程序大概做了哪些事。第三个视角是字符串游戏里的提示语、错误码、格式化字符串往往是最显眼的“地标”。我自己分析游戏时有个习惯先看程序导入了哪些函数、再搜一遍明文字符串往往就能把整个游戏的框架猜个七八成。因为这些信息是二进制文件里明明白白存放的除非开发者刻意做字符串加密很少人会在游戏里做全套否则这些线索会一直留着。4.3 优化与混淆难度阶梯但不是铜墙铁壁编译器提供多种优化级别O2和O3下会出现函数内联、循环展开、死代码消除等行为。函数内联会让原本一个完整的独立函数消失调用的地方被直接展开成函数体循环展开会让循环结构变成一长串重复代码。这些优化确实会提高阅读难度但不改变核心事实输入到输出的计算关系依然存在数据流依然有迹可循。你要做的是从“按源码来对照”的思路切换到“按数据流来追”的思路顺着被内联的代码片段往上找调用关系。更难啃的是混淆比如OLLVM这类工具带来的控制流平坦化、虚假控制流、指令替换。控制流平坦化把一个逻辑的跳转关系拆成一层分发器让你初看时仿佛置身迷宫。但老话说得好混淆只能增加阅读成本不能删除逻辑。代码必须实现原本的功能运行结果不能改变这是混淆的底线。所以对付混淆核心策略就是“动态调试看行为”而不是纯静态死读。5. 操作系统与API所有动作都要过“公共门”游戏再封闭、再加密它终究跑在操作系统之上。这决定了它所有“想做的事”都必须通过与操作系统交互来完成而这些交互点就是逆向的最佳切入口。5.1 游戏再封闭也要向系统低头游戏虽然是自带引擎的庞然大物但底层仍然是“普通进程”。它需要创建窗口、接收键盘鼠标输入、分配内存、读写文件、播放声音、渲染画面、建立网络连接。这一系列动作不可能靠游戏自己用魔法完成全部要调用操作系统提供的API接口。举个例子一个DirectX 11游戏要渲染一帧画面它必须调用DXGI的Present方法把画面送到屏幕上它要播放音效就会调用XAudio2或WASAPI的接口它要读存档文件就会调用ReadFile或CreateFile。这些API的调用点都是固定的、公开的、可被hook的。这意味着逆向不一定非要理解整个游戏架构只需要偷懒地抓住“它必须调用什么”。想知道游戏在渲染什么就hook Present方法想拦截游戏收到的网络消息就hook send/recv相关函数想搞清楚某个按键交互逻辑就hook输入消息的处理函数。这种“借力打力”的思路是新老逆向都爱用的高效路径。5.2 Hook的底层原理让执行流在必经之路上改道讲Hook之前先破除一个神秘感Hook完全没有破坏什么它只是在“必经之路”上改了路标。程序运行时某个DLL函数比如ReadFile的入口地址在模块加载后是确定的。CPU执行到函数入口时只会盲目地取指令、执行根本不关心这些字节是原本就有的还是被人动过手脚。Inline Hook的做法是在函数开头覆盖若干字节写入一条跳转指令jmp跳向自定义函数。自定义函数可以完成监控、修改参数、篡改返回值等操作处理完再跳回原函数剩余部分。IAT Hook则更简单粗暴修改exe导入表中该DLL函数的地址指针让程序在调用时直接就跳进自定义函数连原函数头部都不用动。这两种思路都成立的前提只有一个程序运行时的调用路径必须经过那个“入口地址”。只要绕不开这个入口你的Hook就一定能生效。这也是为什么游戏开发者想反Hook往往会用“多次调用API”“直接系统调用”等方式来避开常规hook点但这种做法要么损失兼容性要么损失性能很难做绝。5.3 调试器断点原理CPU级别的暂停能力调试器是怎么实现“断点”的通常有两种手段。软件断点调试器把目标指令的第一个字节改写为0xCC对应int 3指令。CPU执行到这个字节时触发异常异常处理权交给调试器调试器再把这个字节还原为原本内容让程序可以继续运行。硬件断点利用调试寄存器DR0到DR3设置最多四个内存或指令地址当CPU访问匹配时触发异常。硬件断点的好处是不修改代码不容易被程序本身检测到所以更适合对付带反调试的程序。理解了断点原理就会明白为什么完全绕过调试是不可能的任务。只要CPU还保留“暂停执行并报告状态”的能力调试器就不可能被彻底屏蔽。反调试技术能做的事只有“增加分析成本”检测调试器特征、在异常时干扰、设置定时校验但这些东西终究只是拖延技巧不能从根上消灭被调试的可能。6. 攻与防其实是同一枚硬币懂了底层原理再看攻防两端就会有一种奇妙的通透感攻和防建立在同一套机制上只是目标相反。明白了这一点你既不会觉得进攻方无所不能也不会觉得防守方束手无策。6.1 攻找数据、跟代码、改流程把前面的所有原理映射到实战逆向的三个基本动作无非是找数据、跟代码、改流程。找数据是定位目标——不知道血量在哪一切无从谈起。跟代码是串联因果——从一次数据变化出发逆着调用链找到决定这个变化的函数。改流程是达成目的——把某条跳转指令的跳转条件反转把某次函数调用的参数修改让原本的判定失效或生效。“改流程”最经典的例子就是修改条件跳转。游戏里凡是“如果满足条件A则执行B否则执行C”的逻辑编译后都逃不开跳转指令。把jne改成je把jmp的方向改一下游戏行为就会从一个分支切到另一个分支。这听起来非常强大但注意它的边界你修改的永远是客户端本地的逻辑。如果最终的决定权在服务端本地改了也只是表面现象。从防御视角看理解这套攻击思维才是做好防守的前提。你会知道对方大概率在哪里落脚——总会去找关键数值、总会去hook有特征的系统API从而更清楚该在哪里布防。6.2 防反逆向的常见策略及其代价防守方常见的思路有几种但每一条都有代价。加壳压缩原始代码运行时再动态解密能极大提升静态分析难度但会拖慢加载速度容易被杀毒软件误报兼容性也是大问题。混淆打乱代码形态提高阅读成本但代码体积膨胀、性能下降而且动态调试依然是绕不过的克星。反调试则是主动检测调试器的存在比如检查BeingDebugged标志、时间差检测、检测硬件断点等。但这些手段本质上是在“监控环境”只要被绕过一次就会失效。更重型的方案是内存校验定期对关键代码段做哈希校验发现被修改就闪退或报告服务器。校验做得好确实能拦截很常见的修改方式但校验本身也是一段代码也住在内存里也可能被分析定位并跳过。你会发现防守的终极困境任何保护措施都必须通过CPU执行而CPU执行的代码就必须是明文可见的。代码加密后运行时还是要解密解密后的那一小段时间就是“暴露窗口”反调试代码自己也要跑它检测别人的同时自己的特征也留在内存和指令流里。6.3 客户端与服务端的信任边界从架构上看最彻底的反外挂方式就是把关键逻辑全部放进服务端客户端只负责发指令和表现。角色属性、伤害计算、掉落判定都在服务端进行本地改了数值也无效。听起来完美但代价是游戏体验变差每走一步都要网络请求延迟一高就无法战斗于是客户端必须做一些本地预测来平滑体验。这些本地预测本身就成了新的可修改目标。客户端永远不可能完全舍弃本地逻辑因为渲染、操作反馈、动画播放这些都必须在客户端进行。哪怕服务端不做校验客户端也至少要“知道”当前世界状态才能渲染。这个矛盾决定了游戏逆向会一直存在反作弊效果只能靠“分层校验服务器仲裁”来逼近而不存在绝对的堡垒。理解这层边界你在做攻时会更清楚打到哪一层才算真正拍板做防时也更知道哪些环节是无论如何也守不住的雷区。7. 新手最容易踩的坑与排查思路最后分享一些常见问题排查经验。这些坑我在带新人时见得最多每一个背后都连着前面的底层原理所以排查起来并不玄学都是有逻辑可循的。7.1 搜不到数值先检查你对内存的假设最常见的卡壳场景是明明在屏幕上看到血量掉到85CE里也搜了85结果提示“0 candidates”。这时候先别怀疑工具坏了先反思你对这个数据的假设。第一个可能是类型错了。血量可能不是4字节int而是单精度浮点、双精度浮点甚至8字节long long。不同的游戏引擎有各自偏好的存储类型搜不出来就先换类型扫描。第二个可能是显示值和实际值不一致。血条显示100/100内部实际存储可能是0到1的浮点比例也可能是1000而不是100甚至显示逻辑会把小数或负数换算成好看的整数。第三个可能是数据被加密了。虽然加密数据最终也要解密使用但如果在“解密-使用-再加密”的间隙里没被你搜中你就搜不到。应对方法是观察更细微的变化比如多搜几轮变化前后的值或者改用“未知初始值变大了”的模糊搜索思路顺藤摸瓜。另一个很隐蔽的情况是目标数值根本不是普通变量而是藏在hashmap这样的动态结构里。如果对象在哈希表中直接按固定偏移遍历内存只能看到索引和哈希值看不到整洁的线性排列。理解数据结构底层的物理布局比对着一堆偏移猜来猜去有效得多。7.2 一附加就崩溃可能是反调试在干扰新手第一次附加游戏进程时经常遇到点附加后游戏立刻崩溃、画面冻结或者直接退出。排除掉操作时机问题比如在游戏忙碌时强行附加大概率是游戏内置了反调试检测。常见的手法包括调用IsDebuggerPresent这类API检查PEB的BeingDebugged标志位也有用NtQueryInformationProcess做更深入的检测还有的是通过检测硬件断点或时间差来判定“有人在跟踪”。这些检测一旦命中游戏就可能故意崩溃、自动退出或者把错误路径伪装成普通bug。排查思路是分层的。先从系统层面确认是否真的存在检测逻辑用调试器在可疑检测API上断点看是否命中再考虑绕过方式比如把PEB标志位改掉或者用更隐蔽的调试方式。但这里要提醒一句现代很多联网游戏的反作弊系统是内核级的普通玩家在这个层面操作不仅困难也容易触发账号处罚。如果是学习目的我建议选单机游戏或自己写的程序练手体验远好于硬碰联网大作。7.3 断点打不中优化、内联和多线程是三大元凶动态调试中花了九牛二虎之力定位到一个疑似函数地址下了断点结果程序跑得飞快断点从未命中。常见原因有三个。第一函数被编译器内联了。Release模式下小函数经常被展开到调用处原函数地址根本不会在调用栈中出现自然断不到。排查方法是看汇编里call的调用目标如果某个call后面跟的是一段内联代码而不是真正的函数就要顺着跳转重新定位。第二数据被多个线程修改。大部分游戏都是多线程架构主线程跑逻辑渲染线程跑画面网络线程跑收发数据。你断在某条写入指令上可能命中的是其他线程一闪而过的临时写入真正的目标线程反而走的是另一条路径。排查方法是查看断点命中时线程ID确认线程身份再调整断点范围和过滤条件。第三硬件断点数量有限。x86处理器只提供四个调试寄存器常规用法下最多四个硬件断点。如果程序自身也要用调试寄存器就会和你产生冲突。遇到这种情况要么精简断点数量要么改用软件断点作为补充但软件断点有被校验检测的风险两者需要权衡。我在实际分析中还有一个独家习惯在游戏完全静止的菜单界面先下好断点等逻辑进入战斗场景再确认命中时机。这样可以排除大量“加载期间代码临时路径”带来的误命中分析起来干净很多。最后说点个人体会。我每次带新人入门都让他们先别急着碰游戏而是打开一个最简单的C程序——hello world看反汇编里自己写的main函数长什么样看函数入口那些push和mov看字符串是放在哪里的。这一件事做明白了游戏逆向的地基就稳了一半。后来你接触再复杂的程序会发现它不过是这个hello world在更大规模上的重复指令按顺序执行数据按规则摆放函数按约定互相调用。每一条看起来高深莫测的技巧解析到底层都是这些朴素的原理在发挥作用。如果你读完这篇能对“为什么能做到这些事”有一个清晰的框架那这个系列的第零篇就算真正完成任务了。