程序不是黑盒：游戏逆向攻防从零讲清底层原理

你有没有想过一个问题：一个单机游戏里你的金币是 500，一个几百 KB 的修改器把它变成了 99999，整个过程游戏自己一点感觉都没有。凭什么？游戏程序难道不是一团“黑盒”吗？为什么有人连游戏代码都没看过，就能在内存里精确找到那个数字？

答案藏在计算机最基本的几条设计原则里。这篇文章是“游戏逆向攻防”系列的第零讲，专门讲底层原理——不教具体工具按键，而是讲清楚逆向工程到底为什么能做到这些事：因为程序不是黑盒，它天生就是可读、可改、可拦截的。了解这些原理，既是为以后实战打地基，也是站在防御一侧做安全检测、反外挂、漏洞分析的基础。想学逆向但不知道从哪开始的，或者写游戏、写反外挂想搞明白对手套路的开发者，都可以从这篇入手。

1. 程序不是黑盒：冯·诺依曼架构给逆向工程留的门

1.1 存储程序这一条，决定了程序天生可以被读

现代计算机几乎清一色遵守冯·诺依曼架构，核心思想就一句话：指令和数据一起存在同一块内存里，CPU 从内存取指令、解码、执行，循环往复。

这句话听起来平淡，但它是整个逆向工程的“物理基础”。你想一下，如果指令被放在一个不可读的芯片里，数据放在另一块地方，那程序就真的是黑盒了。但现实是，程序被加载进内存后，和普通数据没有任何本质区别——都是地址上的字节。CPU 不知道“这段是用来执行的代码，那段是金币数值”，它只知道按流程取指令执行，而人是可以站在旁边把内存整个读出来的。这就是“程序可读”的根源。

生活化类比：程序就像图书馆一样，书架上的书全都敞开着摆着，管理员（CPU）按编号取书、看书、执行内容。图书馆管理员当然不懂“保密”，因为设计之初就要求所有人能访问书架。逆向工程做的，无非是“趁管理员看书的时候，也凑上去看了一眼”。

有个细节值得新手注意：冯·诺依曼架构还意味着“代码可以被当作数据修改”。现代 CPU 和操作系统为了保护自身，加了各种权限位（比如代码段只读），但这一点在历史上更赤裸：早期程序甚至可以自己改写自己的指令。即便现在有 NX/DEP 这类保护，程序在内存中的本质特征依然存在，逆向工程的分析能力也并没有消失——只是多了层权限判断。

1.2 地址、虚拟内存与指针：逆向分析的基本单位

程序运行后，操作系统会给每个进程一个独立的虚拟地址空间。代码、全局变量、堆、栈、动态库，各占一块区域。逆向分析里最常见的数据结构是“地址”——某个数值在哪个地址，某条指令在哪个地址，某个函数入口在哪个地址。

虚拟内存机制看似是保护，其实也给了逆向工程便利：因为每个进程的地址空间是统一规划的，你可以在进程外部通过 ReadProcessMemory、WriteProcessMemory 这类接口直接读写目标进程内存，也可以在调试器里直接查看。Linux 上类似的玩法是 ptrace 和 /proc/pid/mem。但请注意，这种“跨进程读写”能力本身是系统提供的合法调试/监控能力，反外挂和调试器都在用它，区别只是使用目的。

有兴趣的读者可以做一个实验：用 CE 扫描单机游戏里的血量，期间不断变化数值，对比扫描结果，最后你会得到一个或几个精确的地址。然后你把这个地址固定住（pointer scan），会发现很多地址每隔一段时间就变化——因为对象是动态分配的。真正不变的是某个全局指针，它指向一个更大的结构体，结构体里的某个偏移位置才是血量。

这就是后面章节要展开的“指针链”问题，也是很多新手卡住的地方。先记住一个结论：在逆向的世界里，一切分析都从“地址+偏移”开始，而不是从“变量名”开始。高级语言里的变量名，在机器码里根本不存在。

2. 机器码、汇编与编译器：为什么“可读”是天然属性

2.1 可执行文件本身是公开格式

Windows 的可执行文件是 PE 格式，Linux 上是 ELF。这些格式都是公开文档化的，不是什么秘密。PE 文件里有导入表、导出表、节表、资源、字符串等。IDA 或 Ghidra 打开一个 exe，能直接列出它导入了哪些 API、调用了哪些库函数，原因就是这些信息明文写在文件结构里。

为什么厂商不把这些信息藏起来？因为操作系统加载器需要用这些信息来加载程序。如果格式不公开、不标准，程序没法被统一加载和运行。这是一个“为了兼容性必须开放”的结构。逆向工程几乎零成本地利用了这点。

很多新手以为“逆向 = 破解 = 高端黑客技巧”，实际不是。用 IDA 打开一个没加壳的程序，你能看到所有的导入函数、字符串常量、调用关系。这里没有攻击行为，只是读了一个格式公开的文件。加壳、混淆、反调试是为了提高后续分析的难度，但“可读性”是娱乐程序出厂自带的属性。

2.2 汇编与机器码：翻译，不是加密

编译器把 C/C++ 代码翻译成汇编，汇编器再把汇编翻译成机器码，这个过程本质是“翻译”而不是“加密”。x86 指令编码是 Intel 手册公开规定的。比如：

字节	助记符	含义
0x90	NOP	空操作
0xCC	INT3	触发断点异常
0xE9 + rel32	JMP rel32	相对跳转
0x48 0x89 0xC3	MOV RBX, RAX	寄存器拷贝

看到 0xE9 后面加 4 字节，就能算出它会跳到哪里。看到一串 0xCC 就知道这里是断点填充。这个过程像查字典，不需要什么玄学。就算一个程序加了壳，最终执行时也必须还原成这些明文机器码，CPU 才能执行。

很多写业务代码多年的程序员第一次看汇编很不习惯，我劝你别怕。你不需要记住所有指令，重点是理解几类关键指令的语义：数据传送（MOV/LEA）、算术运算（ADD/SUB/IMUL）、栈操作（PUSH/POP/CALL/RET）、跳转（JMP/Jcc）、比较（CMP/TEST）。掌握这几类，已经能读懂九成代码的执行流。

2.3 编译器留下的“指纹”和反编译逻辑

还有一个对逆向极其友好的事实：程序是编译器生成的，不是人手工写的汇编。编译器有固定的优化模式和行为模式，比如函数序言（prologue）通常是push ebp; mov ebp, esp（32位）或sub rsp, xx（64位），循环经常编译成cmp/ja/jmp的结构，字符串常量会直接出现在文件里。这些特征让分析者能快速识别“这是一个函数入口”“这是一个循环”“这个函数调用了 printf”。

IDA 的反编译（Hex-Rays）也不是什么魔法，它是把汇编指令按语义往上还原成类 C 伪代码的过程。多数的条件跳转变成 if，通过 ESP 平衡状况推断函数参数个数，通过返回值寄存器推断返回类型。反编译的代码不是原始源码，甚至能明显歪曲原意，但它足够让你理解这段程序在做什么。

这里顺带说一个重点：Hex-Rays 反编译结果和真实源码之间不是一一对应。我有一次分析一个开源程序时，把反编译代码和原源码对照，逻辑完全对得上，但变量名、循环写法全都不一样。所以在逆向分析里，“能不能还原出精确源码”往往不重要，“能不能理解逻辑”才重要。不要迷信反编译工具，更不要以为拿到了反编译代码就等于拿到了源码。

3. 从“找数值”到“定位指针”：一个修改器的完整原理链

这一章我会用 Cheat Engine 的例子把原理讲透——因为它太适合说明“为什么逆向能做到”。

3.1 数值扫描：内存里没有类型，只有字节

修改器最常见的操作是改钱。游戏里金币是 500，CE 首次扫描输入 500，它会把整个进程内存里“表示的数值等于 500”的所有地方都列出来，可能有几万个。你把金币变成 520，再次扫描，提供 “520” 作为过滤条件，结果迅速变少。反复几次后，最终得到一个精确地址。原理很简单：内存里没有“int 类型”这种抽象概念，只有一连串字节，CE 只是暴力搜索“哪些字节组合起来等于给定值”。

这听起来很原始，但这就是“内存扫描”的全部秘密。问题来了：怎么知道是 4 字节整数而不是 8 字节、浮点数？CE 里可以选扫描类型：4 Bytes、8 Bytes、Float、Double、Byte 数组。经验上，游戏里大量数值是 4 字节整数，所以默认扫描很常见。但如果扫描不出来，换个类型试试，大部分情况能找到。学会了这一点，你已经理解 80% 的“改钱改血改蓝”操作。

要在思路上补充的是：扫描的原理还解释了为什么有些游戏数值显示得很正常但扫描不到——因为显示层可能做了转换（比如血条百分比是 0~1 的浮点，数值显示成 1000/1000 是经过 UI 计算的）。这是“没能找到值”最常见的坑。不是 CE 不行，而是内存里根本不直接存这个显示值。

3.2 找到“是谁改写了这个地址”：硬件断点的登场

直接改地址上的值，游戏逻辑往往会立刻把数值改回去，或者校验数据不同步。这时候就不能“改结果”了，要“改原因”。怎么做？让 CE 监视这个地址，一旦有人写它，立刻停下来，看看是哪条指令在写。

原理是：CE 在这个地址上设置一个硬件访问断点。x86 处理器提供了 DR0-DR7 调试寄存器，可以配置为“当某个地址被读取/写入/执行时触发异常”。游戏执行到那条mov [ecx+xx], eax的指令时，CPU 触发一个调试异常，操作系统把这个异常转交给调试器。此时，调试器看到当前 EIP/RIP 指向的指令，就是真正的“凶手”。

这就是 “Find what writes to this address” 的底层机制。不是什么主动监控，而是 CPU 在硬件层面给你当卧底。很多新手不理解这一点，以为 CE 一直在后台读内存、对比数值变化，其实不是——它借助了 CPU 的调试机制，效率和准确性都完全不同。

硬件的断点数量有限，一般只有 4 个（DR0-DR3），所以 CE 里的 “Find what writes” 通常只能同时监视很少的地址。如果你要同时监控很多个对象，就需要用更复杂的办法（比如 VEH 或者改写入代码），但那是另外一个话题了。

3.3 指针链和“基址+偏移”

找到了改写指令，顺着指令里出现的地址继续往上追，你往往会发现：当前对象的地址不是固定的，而是保存在另一个对象里。比如指令是mov eax, [ebx+0x50]，EBX 来自某个对象指针；那个对象指针又从另一个全局指针里读取。一层一层套下去，直到某一层是一个固定地址（全局变量），这就是“基址”。

所以你在脚本区常见的[[[base + 0x1C] + 0x08] + 0x50] + 0x4就是这种指针链的表示。它翻译过来是：从全局地址 base 读指针，加上 0x1C 偏移再读指针，加上 0x08 再读，加上 0x50 再读，最后一个偏移 0x4 就是你要改的数值地址。

这个套路和数据结构里的“索引+引用”是同一个思想。你理解 HashMap 是怎么通过 key 定位 value 的——算哈希、定位桶、顺着链找节点——就会觉得指针链很自然：计算机本质上就是在各种“地址引用”之间跳转。没有学过数据结构的同学在这里会明显感觉吃力，但只要你理解了“指针是指向对象的地址，对象里又保存了其他对象的地址”，指针链就没有秘密了。

指针链的偏移值是编译期就定死的，跟游戏内部的结构体定义一一对应。所以破解一个游戏的指针链，本质就是“摸清这个结构体长什么样”。这跟做安全研究时分析二进制里一个匿名结构体，是一模一样的工作。

3.4 改数据 vs 改逻辑：两条路线

到这里，修改器的完整链路已经清晰：扫描数值、找到地址、找到写者、追指针、锁定基址偏移，然后周期性写入自己想要的数值。但这个路线有个大前提——数据是普通数值，能被内存扫描找到。

如果你要改的“效果”很复杂（比如无限子弹、加速、穿墙），单纯改数值就不够了，因为子弹数量是数值可以改，加速涉及游戏引擎的事件循环，穿墙涉及碰撞检测逻辑。这种时候必须进入“改逻辑”阶段：找到判定代码，直接跳过它，或者 hook 它。这就是第五章的内容。

关于这个分界，我想提醒一句：能改数据改数据，不能改才改逻辑。修改内存数值是最稳定、最不会出错的玩法，而改代码（特别是 hook）要考虑字节长度、原指令恢复、相对偏移，复杂度直线上升。初学者一上来就学 hook 是很容易受挫的，强烈建议先在“改数值”这个层面把地址、指针、偏移玩熟。

4. 断点和单步：调试器靠的是 CPU 的硬件机制

现在进入调试器的核心原理。为什么 x64dbg/OllyDbg 能“在那一行停下来”？为什么能一步步执行？这些能力不是调试器自己发明的，全是 CPU 设计好的机制。

4.1 0xCC 软断点：把指令临时替换成一条异常

最常见的断点是软断点。调试器往下断点位置写入一个字节 0xCC（也就是 INT3 指令），把这个位置的原始字节暂时保存下来。程序执行到这里时，CPU 执行 INT3，触发一个异常（#BP）。

关键机制来了：操作系统在处理异常时会检查，当前进程是否处于被调试状态（Windows 上会调用调试子系统，内核把调试事件发给调试器）。如果是被调试进程，调试器就能收到类似“命中断点”的通知。调试器再把 0xCC 恢复成原始字节，并把 EIP 回退到断点位置重新执行，于是程序继续正常运行。这就是“断点暂停”的完整链路。

这就解释了两个经常困扰新手的问题：

• 为什么有些断点下不了？因为被下断点的位置可能是只读页，写入 0xCC 失败。
• 为什么调试器可以把 0xCC 改回去再跳回来？因为它保存了原始字节。

其实 0xCC 填充在很多程序里也能看到。为什么编译器填充区域用 0xCC 而不是 NOP 0x90？因为 0xCC 本身就是一次中断异常，如果程序意外跳进填充区域，会立刻停下来暴露问题，开发者能第一时间发现这类越界跳转。这种细节基本没人注意，但逆向工程师一眼就能认出来。

4.2 单步执行与陷阱标志

单步 “Step Over” 背后也藏着 CPU 的贴心设计：EFLAGS/RFLAGS 寄存器里有一个位叫 TF（陷阱标志）。调试器在执行下一条指令之前把这个位设为 1，CPU 每执行完一条指令，就会自动触发一次单步异常（#DB）。异常处理程序把控制权交回调试器，调试器再决定下一步做什么。

整个过程看不见、摸不着，但在 CPU 的硬件逻辑里真实发生：取指、译码、执行、异常分发、控制权移交。这就是“一步步看着程序走”的物理基础。

另外硬件断点的机制在上一章已经提到过，这里再连接一下：DR0-DR3 存放要监视的地址，DR7 配置监视类型。硬件断点和软断点的最大区别是，硬件断点不需要修改被监视位置的内容，所以对那些做了代码完整性校验（防 patch）的程序依然有效。反过来，如果程序检测到 DR 寄存器里存在非常规值，也会认为自己在被调试——这就是硬件断点检测/反硬件断点博弈的由来。

4.3 调试其实是“操作系统的能力”

无论是软断点还是单步，最终都要操作系统配合。Windows 的调试子系统、Linux 的 ptrace 都是把 CPU 异常翻译成“调试事件”的中间层。调试器在用户态拿到事件，然后操作被调试进程的寄存器、内存、堆栈。

这也解释了为什么内核态反调试（比如某些反作弊驱动）很难对抗——因为它在调试事件分发之前就做了手脚。普通游戏在用户态做反调试，逆向者直接在用户态 hook 掉检测，双方在同一个空间里玩猫鼠游戏，没有绝对的输赢。我们后续会专门说攻防细节，这里先理解一个结论：调试是 CPU 和操作系统提供的正规机制，不是系统漏洞。

5. 代码注入与 Hook：改代码比改数据更彻底

5.1 inline hook 的字节经济学

Inline Hook 是逆向里最有代表性的代码修改手段。思路说穿了一文不值：把目标函数开头的几条指令替换成一条跳转指令（比如 E9 相对跳转），跳到你自己的 Shellcode 里。你的 Shellcode 先执行自己的逻辑（比如修改参数、记录日志、改返回值），然后执行被覆盖掉的原指令，再跳回原函数的下一条指令位置，就像什么都没发生过。

但这背后有几个精确到字节的麻烦事：

第一，跳转指令固定占 5 字节（E9 + 4 字节相对偏移），所以你必须保证被覆盖的原始指令加起来至少 5 字节，而且不能从中切开一条指令。比如原函数第一条指令是 2 字节、第二条 3 字节，正好 5 字节，完美。如果第一条是 3 字节、第二条是 1 字节，你强行替换 5 字节，把第二条指令切了一半，程序执行到中间就崩了。

第二，跳转偏移是相对的，公式是目标地址 - (当前指令地址 + 5)。用工具计算可以，但手动 patch 时很容易算错。

第三，如果你的 hook 代码里用了绝对寻址的变量，要注意重定位问题——因为 shellcode 是凭空塞进内存的一小块，它访问自己数据区时不能依赖任何“默认基址”。

我见过很多人照着教程写 inline hook，发现游戏崩溃或者 hook 不生效。排查跳转偏移和指令切分这两个问题，能消灭九成故障。这就是“原理决定排错方向”的典型例子。

5.2 Hook 的函数级效果与调用链设计

为什么 hook 比改数值更“根治”？因为函数是游戏逻辑的最小封装单位。比如“造成伤害”这个函数，所有攻击流程都会调用它。你在函数头部 patch 成“直接返回 0”，那么无论是普通攻击、技能伤害、爆炸溅射，所有伤害都归零。你不需要关心伤害从哪来、经过什么公式，只需要在这一个点上做手脚。体验上一劳永逸，这正是“以点控面”。

同样是 hook，“改函数返回值”和“改游戏对象状态”是两种不同的思路。前者在函数返回处改掉 EAX 寄存器，后者在函数内部找到具体修改的逻辑。具体用哪种，取决于你要实现的效果和函数复杂度。

做逆向分析时，定位“该 hook 哪个函数”本身的技术含量比写 hook 更高。方法通常是：先用静态分析梳理函数调用关系，再用动态调试确认关键函数参数，最后在函数入口下断点验证。整个流程需要汇编、调用约定、调试器操作的综合能力，这也是为什么我说“原理才是硬通货”。

5.3 一条重要的边界

到这里，原理已经讲完了。但我想认真说一句：这些能力用在单机游戏学习、CTF 比赛、漏洞研究、安全防护上是完全正当的；用在联机游戏、商业产品作弊上是违规甚至违法的。本文的目的是讲清楚底层原理，帮想做安全、反作弊、游戏开发的同学建立“对手视角”。真正做防御工作的人，恰恰是最需要懂这些攻击原理的人。学会“怎么改”，是为了知道“哪里会被改”。

6. 为什么防御总是慢一步：从加壳到反调试的底层困境

讲到这里，你会发现逆向工程能做到这些事，最根本的原因不是工具厉害，而是计算机体系结构本身“暴露”给使用者了。这一章把攻防一体的视角给它讲透。

6.1 加壳与脱壳的信息论悖论

加壳（packer）的做法：把可执行程序加密或压缩，运行时在内存里自行解密，还原出原始机器码再跳转执行。加密壳看起来天衣无缝——磁盘上全是密文，你怎么静态分析？

但这里有个悖论：程序最终要在用户机器上执行，被 CPU 执行的前提是被还原成明文机器码。也就是说，壳在运行时必然会亲手把原始代码放到内存里。逆向者的策略很朴素：等壳解密完成，把内存里那一坨明文 dump 下来，再分析。UPX 这种压缩壳甚至能被一条命令直接脱掉，因为压缩算法是固定的；VMProtect 这种虚拟化壳麻烦得多，因为原始指令被翻译成了自定义字节码，但即便如此，执行路径还是在内存里，可以通过动态跟踪慢慢还原语义。

所以防御只能提高逆向成本，不能从原理上阻止逆向。你可以把逆向想象成审讯一个必须全程说实话的犯人——犯人（程序）为了执行自己的使命，必须在某个时刻把真相和盘托出，然后靠混淆、加密、虚拟化来让“供词”显得混乱难懂，但它没法不说。

6.2 反调试技术为什么终会被绕过

常见的反调试手段包括：调用 IsDebuggerPresent 检查调试器、检查 PEB 里的 BeingDebugged 标志、检查时间戳（因为单步执行会拖慢时间）、扫描 0xCC 断点、检测 DR 寄存器的硬件断点。这些检测的本质，都是“程序在运行过程中检查自己周围环境是否异常”。

问题是，这些检测代码本身运行在被调试者的地址空间里。逆向者可以把 IsDebuggerPresent 这个函数 hook 掉，让它永远返回 0；可以把 PEB 里的标志位改掉；可以把时间检测的代码直接 patch 成无条件跳转。市面上也有很多成熟工具默认配置就能绕过九成常见的反调试。

更深层的原因是不对称性：防御方要防住所有可能的检测点和所有可能的入口，而攻击方只需要找一个没被防御住的漏洞。用攻防对抗里常说的一个比喻：防御是在棋盘上防住所有格子的王，攻击只需要一条通向将杀的线路。理解了这一点，就理解为什么安全领域永远说“没有绝对安全”。

6.3 从“为什么能做到”到“如何做防御”

写到这里必须收束一下：很多做游戏开发、反外挂的朋友，觉得逆向工程是“外挂作者的专利”，其实正好反过来。如果你不了解改数值、改逻辑、hook 这些底层原理，你根本不知道自己的游戏哪里是脆弱的。反外挂方案的检测，本质是在逆向者用过的各种机制上做标记和监控：校验关键代码段是否被修改、检测调试器痕迹、监控跨进程读写行为、加密关键数据——这些全都建立在“理解逆向原理”的基础上。

所以，本系列把“零、底层原理”放在最前面，就是希望你先把这一课学扎实。后面我们讲 CE 实操、x64dbg 调试、IDA 静态分析、反调试对抗，才会顺理成章。

7. 从原理到能力：逆向工程师的底层知识栈与上手路线

最后一章，聊聊怎么把“懂原理”变成“会干活”。

7.1 不全是“黑客技巧”，更多是计算机基础

整理一下前面的内容，你会发现所有逆向前提都落在这些基础课上：

• 计算机组成：寄存器、内存、地址、总线、异常机制
• 操作系统：进程地址空间、加载器、调试子系统、内存映射
• 汇编语言：指令系统、调用约定、栈帧
• 编译原理：编译过程、优化模式、ABI
• 数据结构：链表、树、哈希表（指针链也是引用关系）
• 程序设计：理解高级语言底层，C/C++ 是优等亲和语言

很多人以为逆向工程师都是“黑客天才”，其实他们只是把计算机基础课学得比较扎实的人。每当有新手问我“要不要先学渗透再学逆向”，我都说先把汇编和操作系统补上——逆向是这些基础课的实战应用，没有地基的奇技淫巧迟早翻车。

7.2 一条从入门到能打的路

如果在职/在校时间有限，我的建议路线是：

1. 先会用十六进制编辑器，理解字节、地址、偏移，能徒手算出几个常见指令的编码。
2. 用 Cheat Engine 在任意单机游戏里做数值扫描，玩懂指针扫描和 “Find what writes”。
3. 学 x64dbg/OllyDbg 基本操作：下断点、单步、查看寄存器与栈、修改内存。
4. 学 IDA/Ghidra 静态分析：读反编译伪代码，用字符串、导入表定位关键函数。
5. 自己写一个 10 行以内的 inline hook demo，体会字节对齐和相对偏移。
6. 做防御向实验：给自己写的小程序加个完整性校验和防调试，再用上面学到的技能绕过它。
7. 进阶：做 CTF 的 Reverse 方向题目，或者分析泄漏的恶意样本（在隔离环境）。

每一步都不需要多高深，但每一步都要亲手做出来。你会发现自己做 demo 时踩的坑，和真实案例分析中遇到的坑高度重叠。印象最深的一次是我自己写了一个“给函数加壳”的小练习，自信满满以为没人能逆出来，结果用 CE 一搜字符串就定位到关键判断，10 分钟就破了。那一刻我彻底理解了“字符串存明文”有多致命，也明白了为什么高级壳都会做字符串加密。

7.3 我个人的几条经验之谈

最后聊点实际的。

不要只盯着工具按键，遇到“为什么这样”要追根究底。比如 CE 的指针扫描，你如果不理解指针链，就永远只会点按钮。

不要一上来就挑战 VMProtect 这类硬壳，先拿 UPX 和无壳程序练手，把常规分析流程跑通。

不要忽略“合法边界”。学习逆向、做安全防御、玩单机游戏，随便折腾；但碰联机游戏、破解付费软件可能给你带来麻烦。做技术的底线是，把能力用在让系统更安全、让自己更强的事上。

我现在回头看，最值钱的不是会多少个工具，而是理解“程序在机器上到底怎么活着的”。只要这一步走踏实了，后面所有“炫酷”的逆向技巧，都只是不同的组合方式罢了。