企业官网建设流程全解析

说实话，我平时很少看到有人愿意在8086汇编这种“石器时代”的环境里折腾游戏，但推箱子这个项目我做完之后，反而觉得它比很多用高级语言写的课程设计更有意思。整个项目不依赖任何图形库，不需要操作系统帮忙，纯粹靠BIOS中断、内存操作和一堆跳转指令，就把一个完整可玩的游戏给撑了起来。这篇文章会把我在实现过程中的设计思路、地图编码、移动判定、调试经历全部摊开来讲，适合正在学微机原理、准备汇编实验，或者纯粹想挑战硬核玩法的朋友。

1. 项目概述：为什么用8086汇编做推箱子

1.1 这个项目到底是什么

先把这个项目的边界说清楚。它不是一个运行在操作系统里、带图形界面的游戏，而是一个运行在16位实模式下的汇编程序，直接在DOS环境（比如常见的仿真器）下运行。程序启动后进入文本模式，用字符拼出地图，通过键盘的方向键控制人物移动，把箱子推到指定位置就算过关。

推箱子的游戏逻辑听起来简单：玩家移动，箱子跟着动，箱子不能穿墙，所有箱子到达目标点就胜利。但在8086汇编里，这每一件事都变得很“贵”。没有现成的数据结构，没有函数库帮你处理键盘事件，甚至屏幕上画一个字符，都要对着显存地址或者BIOS中断自己去拼。正因如此，这个项目成了我理解计算机底层机制的最好练习：内存布局、寻址方式、中断调用、标志位判断，这些教科书上的概念全部变成了要亲手处理的现实问题。

1.2 这个项目适合谁参考

如果你是学过一点汇编但还停留在“照着课本抄段代码”的阶段，这个项目是一个非常好的综合训练。它会强迫你思考三件事：第一，怎么用一维数组表示二维地图；第二，怎么在坐标移动时做边界检测；第三，怎么把键盘输入变成游戏行为。这三件事覆盖了汇编编程里最核心的寻址、比较、跳转和中断调用。

如果你已经在准备微机原理实验或者课程设计，那这个项目可以直接作为参考框架。它不需要额外硬件，不需要显卡编程，一个仿真器加一个汇编器就能跑，复杂度也刚好卡在“能学到东西但不会劝退”的区间。如果你只是想找点乐子，那也行——看着一个字符小人在地图里推箱子，成就感不比写了个网页小游戏低。

2. 地图编码与内存布局：把二维世界塞进一维数组

2.1 经典地图编码方案

推箱子第一步不是写移动逻辑，而是先把地图“存起来”。8086汇编没有多维数组的语法糖，所有数据在内存里都是一维的线性排列，所以二维地图必须自己想办法编码。

我最常用的方案，也是最直观的方案，是用一个字节表示一个格子，把所有格子的值按行排列成一段连续数据。每个字节的值对应一种地图元素，比如0代表空地，1代表墙体，2代表目标点，3代表箱子，4代表玩家。这样一张地图本质上就是一段DB定义的数据表，读取时通过“行号乘以列数加上列号”的方式计算偏移量。

这里有个关键点：为什么要用字节而不是字？因为地图元素的数量很少，0到6已经绰绰有余，一个字节足够表达，而且用字节存储能省一半内存。虽然8086的内存寻址以字节为最小单位，但如果你定义一个数组，用DB比DW更自然，后续用SI、DI这样的寄存器去遍历，也不会因为元素宽度不同而多算偏移。

2.2 我用的地图元素定义

我实际编码时，把地图元素分成了6种：

这6种状态并不是一开始就全都需要的。最初我写Demo时只有0到4，后来发现要判断“箱子是否全部归位”，必须区分“普通箱子”和“已经在目标点上的箱子”，所以才引入了5号状态。至于6号状态，纯粹是为了显示效果好：玩家站在目标点上时，目标点不能被空地盖住，不然视觉上会闪变。

用这种编码方式，一张9x9的地图定义出来大概是这个效果：

MAP_LEVEL_1 DB 1,1,1,1,1,1,1,1,1 DB 1,0,0,0,1,0,0,0,1 DB 1,0,2,0,0,0,3,0,1 DB 1,0,0,0,1,0,0,0,1 DB 1,0,3,0,0,0,2,0,1 DB 1,0,0,0,1,0,0,0,1 DB 1,0,2,0,0,0,3,0,1 DB 1,0,0,0,1,0,0,0,1 DB 1,1,1,1,1,1,1,1,1

这段数据放在代码段里，运行时再用一段循环把它复制到专门的地图工作区。为什么要复制一份而不是直接读？因为游戏过程中地图元素会动态变化——箱子被推动、玩家从A点走到B点——如果直接改原始数据，重开一局就麻烦了。所以我的做法是：原始关卡数据留在常量区，程序启动时或者切换关卡时，把它整体复制到数据段里的WORK_MAP缓冲区。这样无论怎么玩，原始数据都不会被破坏，随时可以重置。

2.3 地图的坐标计算：行、列与偏移

这是整个项目里最简单也最容易出错的部分。地图是二维的，但内存是一维的，所以格子(row, col)对应的偏移量是：

offset = row * ROW_WIDTH + col

这里ROW_WIDTH是每一行格子的数量，也就是地图的列数。比如一张9列的地图，第2行第4列的格子，偏移量就是2 * 9 + 4 = 22。把偏移量存进SI或DI寄存器，然后通过类似MOV AL, [WORK_MAP + SI]的方式读取，就能拿到这个格子的地图元素。

这里必须注意一个8086的经典约束：SI和DI是16位寄存器，偏移量最大值是65535。一张地图最大也就是几千个格子，完全够用，但如果你的地图特别大，横向超过255列，就要考虑用DX:AX之类的组合来做32位偏移，或者分段处理。我做推箱子时地图保持在9列到19列之间，16位偏移量没有任何压力。

另一个容易踩的小坑是：如果你用的是MASM或者TASM语法，数组下标访问要特别注意段前缀。默认情况下，用SI、DI访问的数据在DS段，用BP访问的在SS段。如果你在子程序里用BP做栈帧，顺手再用BP访问地图数据，那就必须显式写上DS:[BP+...]，否则取到的数据完全对不上。

3. 核心算法实现：移动判定、推箱子与胜利检测

3.1 键盘输入：中断与扫描码

推箱子的交互核心是方向键。在8086实模式下，最常用的键盘读取方式是INT 16h中断。调用方式很简单：设置AH=0，然后执行INT 16h，中断返回后，AH里是键盘扫描码，AL里是ASCII码。方向键没有ASCII码，只有扫描码，所以我主要判断AH。

我在项目里用到的方向键扫描码如下：

读取按键的逻辑封装成一个子程序，大概长这样：

READ_KEY PROC MOV AH, 0 INT 16h RET READ_KEY ENDP

这个子程序极其简单，但有个细节值得说：INT 16h的AH=0功能是阻塞式读取，也就是说，如果用户不按键，程序就停在这里等。对游戏来说这是可接受的，因为我们本来就需要等待玩家输入。而如果你想要“游戏自己动、玩家随时按”的效果，那就得改用AH=1先检测键盘缓冲区是否有数据，这又是另一个话题了。

主循环的结构非常直白：

GAME_LOOP: CALL READ_KEY ; 读取扫描码 CMP AH, ESC_KEY JE EXIT_GAME CMP AH, UP_KEY JE MOVE_UP CMP AH, DOWN_KEY JE MOVE_DOWN CMP AH, LEFT_KEY JE MOVE_LEFT CMP AH, RIGHT_KEY JE MOVE_RIGHT JMP GAME_LOOP

这段代码的效率当然谈不上高，但它线性、清晰，对16位实模式下的逻辑控制来说非常自然。要知道8086没有现代CPU的分支预测缓存，所以频繁分支比较确实会损失一些性能，但推箱子这种低频交互游戏根本不需要担心。

3.2 推箱子的碰撞检测：目标点的三种情况

移动逻辑是推箱子的灵魂，也是我第一次写的时候错得最惨的地方。玩家的移动分两种情况：前面是空地或者目标点，玩家直接走过去；前面是箱子，那就看箱子的前面是不是空地或者目标点，如果是，玩家和箱子一起往前挪一步。

我封装了一个通用移动函数，传入方向对应的行变化量DR和列变化量DC，以及玩家当前所在的偏移量。处理逻辑如下：

1. 计算玩家目标位置DEST = CURR + DR * ROW_WIDTH + DC
2. 读取DEST位置的地图元素
3. 如果DEST是墙，直接返回，不做任何事
4. 如果DEST是空地或目标点，把玩家当前位置清空，把DEST设为玩家
5. 如果DEST是箱子或者“箱子在目标点”，继续看BOX_DEST = DEST + DR * ROW_WIDTH + DC
6. 如果BOX_DEST是墙、箱子或者其他不可通行元素，返回；否则推箱子

这段逻辑里最容易漏的是第5步。我第一次实现时只判断了“DEST是箱子”，忘了“箱子已经在目标点上”也是一种箱子状态。结果就是，箱子一旦被推到目标点上，再去推它就纹丝不动，游戏直接卡死。

修正后的处理方式是：拿DEST的值分别和3、5比较。等于3说明是普通箱子，等于5说明是箱子在目标点上，两种情况都执行推箱子逻辑，只是推完之后原始格子需要恢复成不同的状态——普通箱子被推走后留下空地，而在目标点上的箱子被推走后留下目标点：

CMP AL, 3 JE PUSH_BOX CMP AL, 5 JE PUSH_BOX_ON_GOAL JMP NO_ACTION PUSH_BOX_ON_GOAL: MOV BYTE PTR [DI], 2 ; 箱子原来的位置恢复成目标点 JMP CHECK_BOX_DEST PUSH_BOX: MOV BYTE PTR [DI], 0 ; 普通箱子位置恢复成空地

这看起来只是两个字节的赋值差异，但如果你不区分，画面和状态就会错乱。后来我把这个逻辑理清楚之后，所有与箱子相关的移动都稳定通过测试。

3.3 胜利检测：统计目标点上有没有箱子

推箱子的胜利条件很直接：所有目标点都被箱子占据。每次移动完之后，扫描整张地图，统计值为2的目标点数量，如果目标是0而等于5的格子数量等于目标点总数，就说明全部归位。

你会问：为什么不直接数5的数量？因为有可能玩家当前正站在某个目标点上，这时候目标点显示成6，而它并不是箱子。如果地图上有一个目标点，玩家恰好站上去，5的数量变成0，但你并不能算胜利，因为箱子还在地上。

所以正确的判断方式是：遍历地图，统计值为2的格子数，只要还有2，就说明至少有一个目标点没有被箱子覆盖。遍历完后，如果2的数量为0，就宣告胜利。5的数量多少并不重要，因为5只是用来显示“箱子在目标点上”，真正的判断对象是未覆盖的目标点的存在。

这个遍历用CX和SI配合就能完成：

CHECK_WIN PROC MOV CX, MAP_SIZE XOR SI, SI XOR DX, DX ; DX 用于统计值为2的目标点数量 CHECK_LOOP: MOV AL, BYTE PTR [WORK_MAP + SI] CMP AL, 2 JNE NEXT_CELL INC DX NEXT_CELL: INC SI LOOP CHECK_LOOP CMP DX, 0 JNE NOT_WIN ; 胜利处理 NOT_WIN: RET CHECK_WIN ENDP

这里用LOOP指令，它会自动把CX减1并在非零时跳回，是8086里最典型的循环控制方式。整个过程没有任何递归调用，也没有复杂数据结构，但逻辑是完整的。

3.4 显示渲染：文本模式下的字符输出

地图渲染我用了两种方案，分别对应开发期的调试和最终版的体验。

第一种方案是调用INT 10h的AH=2功能定位光标，再用AH=9或者直接输出字符显示。这种方式的好处是移植性好，在文本模式下不会出错，坏处是每显示一个字符都要设置一次光标，速度比较慢。如果地图是9x9，81个格子的刷新还能接受，一旦地图变成19x19，361个字符逐個刷新，肉眼就能感到明显的卡顿。

第二种方案是直接写显存。8086在文本模式下，彩色文本模式的显存起始地址是B800:0000，每个字符占用两个字节：第一个字节是字符的ASCII码，第二个字节是属性字节（前景色和背景色）。我可以定义一个显示缓冲区，把地图上每个元素对应的字符和颜色填进去，然后一次性用串操作指令STOSW写入显存。

DISPLAY_MAP PROC MOV AX, 0B800h MOV ES, AX MOV DI, 0 MOV SI, OFFSET WORK_MAP MOV CX, MAP_SIZE RENDER_LOOP: LODSB ; AL = 地图元素 MOV AH, 0Fh ; 白色字符，黑色背景 ; 根据AL的值设置字符和颜色 CMP AL, 1 JE WALL_ATTR CMP AL, 2 JE GOAL_ATTR ; ... 其他元素分支 STOSW ; 写入显存，DI += 2 LOOP RENDER_LOOP RET DISPLAY_MAP ENDP

使用ES:DI指向显存，配合STOSW，一条指令就能写入一个完整字符+属性，这在8086时代是最快的文本输出方式。不过要注意，STOSW写的是ES段，所以必须先把ES设为0B800h，否则数据写到DS段的内存里，屏幕上什么都不会发生。

当然，字符和地图元素之间的映射不能像上面一样简单。我的实际做法是准备一张字符表，用查表的方式把元素值映射到ASCII字符和颜色属性。查表是最适合汇编的“分支”方式，比一串CMP/JE高效得多。

4. 实操过程：搭建环境、编译、运行与调试

4.1 工具链选型：汇编器和仿真环境

8086汇编没有一个“官方”的开发环境，因为当年根本没有IDE这个概念。我实际用的组合是MASM风格的汇编器加一个仿真器。如果你手头有Turbo Assembler或者MASM，都可以，语法差异不大。如果什么工具都不想装，只用NASM配合对应的仿真器也完全可行。

这里有一个经验之谈：很多人纠结选MASM还是NASM，其实对于推箱子这种规模的程序，差别不大。MASM对宏和段管理的支持更“正统”，适合照着课本章节学；NASM语法更简洁，Intel风格又直白，适合快速上手。我的建议是，哪个顺手用哪个，关键是写出能跑的代码。

运行环境我用的是常见的DOS仿真器。它模拟了8086处理器的指令集和DOS的INT 21h、INT 10h、INT 16h等中断服务，可以在不碰真实硬件的情况下完成全部调试。有一点必须强调：仿真器是模拟环境，不是真机，所以某些时序和中断行为可能与真实8086略有差异。但就推箱子这种完全依赖INT 10h和INT 16h的程序来说，仿真器和真机的行为几乎一致，差值可以忽略。

4.2 从零到能玩：开发顺序很重要

我建议的开发顺序不是从渲染开始，而是从地图数据开始。先定义好地图编码和工作区，写一个最简单的“打印地图”程序，能在地图上显示字符，这一步就完成了数据层和显示层的联通。

然后是键盘读取。写一个死循环，每按一次方向键，就让玩家字符在地图上移动一格，不处理箱子、不处理碰撞。这时候你能看到角色在地图上跑来跑去，穿墙而过，感觉像幽灵模式。这个阶段虽然“不像游戏”，但它验证了输入、输出、坐标计算三者的配合。

接下来再引入碰撞检测。先处理墙的阻挡，再处理箱子的推动。墙的阻挡最简单：目标位置如果是墙，就什么都不做。这一步做完，角色已经不能穿墙了。再接下来才是箱子的逻辑，包括“箱子在目标点”和“箱子不能穿箱”。最后加胜利检测、关卡切换和重开功能。

这个顺序最大的好处是每一步的失败都容易定位。如果你一上来就把全部逻辑写完，然后发现角色推箱子时屏幕乱跳，你根本不知道是坐标算错、碰撞判断错还是显存写入错。分步开发之后，每一个新功能只引入一类新错误。

4.3 调试中的关键心得：单步执行和状态观察

我在调试过程中最常用的手段是仿真器的单步执行功能。每次执行一行汇编指令，我就可以观察寄存器、内存和屏幕的变化。尤其在调试移动逻辑时，我会在CALL READ_KEY之后打个断点，按一次方向键，然后单步跟踪，看DI、SI、AL这些寄存器的值是否符合预期。

这里有个小技巧：把地图元素值和当前偏移量同时打印到屏幕的角落。我第一次调试时，屏幕上只有地图，看不到任何内部状态。后来我在地图下方专门留了两行调试区，把玩家偏移量、当前格子元素值、目标点剩余数量实时显示出来。这样哪怕屏幕上没有任何明显变化，我也知道程序内部的状态走到了哪里。

调试过程还让我意识到一个8086汇编特有的坑：标志位的生命周期。CMP指令会修改ZF、SF、OF等标志位，但如果你在CMP之后插入了其他影响标志位的指令，原来的比较结果就丢了。比如这样：

CMP AL, 3 MOV AH, 0Fh ; 这条指令不改变标志位，安全 JE PUSH_BOX

这是安全的，因为MOV不修改标志位。但如果你写成了：

CMP AL, 3 ADD AL, 1 ; ADD会修改标志位，覆盖CMP的结果 JE PUSH_BOX ; 这里的跳转条件已经不成立了

JE会依据最近一次修改标志位的指令结果来判断，所以ADD之后的JE判断的是AL+1是否为零，完全不是原来的意图。这种错误是汇编初学者最容易犯的，也是最难排查的，因为代码看起来逻辑通畅，但运行时行为完全不可预测。

5. 常见问题与避坑实录

5.1 常见问题速查表

我在实现和调试中碰到的问题，归纳起来主要集中在这几个方面，这里整理成一张速查表：

5.2 我的几条独家经验

第一条经验是关于循环嵌套的。推箱子地图的遍历一般用两层循环：外层行，内层列。但8086里没有现成的二维循环指令，很多人会写两层LOOP，结果CX冲突，内层LOOP把CX减到0后，外层LOOP的计数也乱了。我的做法是：外层循环用DX保存行计数，内层用CX保存列计数，两层各自维护自己的计数器，互不干扰。

第二条经验是：尽量避免在游戏主循环里使用INT 21h的屏幕输出功能。INT 21h的AH=2可以输出单个字符到屏幕，但每次调用都涉及DOS中断服务，速度慢不说，还会和直接写显存的渲染方式产生冲突。我最终只把INT 21h用于程序初始化和退出提示，渲染部分统一走显存。

第三条经验是：扩展地图时，一定要同步更新行宽度常量。这个坑我在增加第二张地图时踩过一次。我复制了一份地图数据，但忘了把行宽从9改成12，结果第二张地图的坐标计算全部错位，角色走到一半就“瞬移”到了奇怪的位置。后来我把行宽做成一个变量MAP_WIDTH，每次切换关卡时先用新关卡的地图属性初始化它，从此再没出过这种问题。

第四条经验是关于栈的使用。8086的栈是向下增长的，SS:SP指向当前栈顶。如果你在子程序里用PUSH保存寄存器，一定要保证子程序返回前所有PUSH都有对应的POP。我的一个严重Bug就是：在一个子程序里PUSH了BX和CX，但提前RET，导致栈不平衡，返回后主程序的CX变成了旧值，循环次数完全错乱。这种错误用调试器看非常诡异，你会在完全无关的地方看到寄存器出现乱值。

6. 扩展方向：从单关卡到多关卡的架构调整

6.1 多关卡数据的组织方式

单关卡实现之后，扩展多关卡并不复杂，但需要一点架构调整。核心思路是：每个关卡的地图数据长度可能不同，因此除了地图数据本身，还要准备一个关卡描述表，每一项包含三部分：地图数据的起始偏移、地图宽、地图高。

我之前提到过，如果只有一张地图，行宽可以写成固定常量。但有了多张地图，行宽就必须动态切换。你可以在关卡表里这样组织：

LEVEL_TABLE: DW OFFSET MAP_LEVEL_1, 9, 9, OFFSET BEGIN_POS_1 DW OFFSET MAP_LEVEL_2, 12, 9, OFFSET BEGIN_POS_2 DW 0 ; 结束标志

每一行对应一个关卡：第一项是地图数据偏移，第二项是宽度，第三项是高度，第四项是玩家起始位置偏移。切换关卡时，从这一行取出对应参数，更新MAP_WIDTH、MAP_HEIGHT，然后把地图数据复制到工作区，重置玩家位置。关卡结束标志用0表示，遇到DW 0就说明所有关卡都完成了。

这个设计虽然只是很原始的表驱动方式，但在没有结构体、没有指针数组的8086汇编里，已经算是清晰好用的方案了。相比写一堆独立的初始化函数，这种表的好处是：增加关卡时只需要添加一行数据和对应的地图数组，不用改任何逻辑代码。

6.2 操作计数与步数统计

推箱子这个游戏有个天然的评价指标：玩家走了多少步。加一个步数统计非常容易：在主循环里维护一个计数值，每次成功移动一次就加一。但要注意，推动箱子也算“一步”，站在原地按一个无效方向键不算步数。所以计数不能放在键盘读取之后，而应该放在移动成功判断之后。

如果想把步数显示在屏幕上，最简单的方案是在屏幕角落固定位置更新数字。你需要在渲染地图之外，单独调一个“更新HUD”的子程序，把步数数值转换成字符写入显存。这里又涉及一个经典问题：怎么把二进制数转换成十进制字符串。8086汇编没有printf，所以你得自己除10取余：

; AX = 步数，转换并显示 MOV CX, 10 XOR DX, DX DIV CX ; DX:AX / 10，商在AX，余数在DX ADD DL, '0' ; 余数变字符 MOV [DI], DL ; 写入显存

这个过程不断重复，每次除以10得到一位数字，直到商为0。注意DIV指令的被除数在DX:AX组合里，所以除法之前一定要先清零DX，否则余数会混进来。这也是汇编初学者经常忽略的细节。

6.3 光标闪烁与画面刷新策略

推箱子玩家会发现一个观感问题：如果每次移动都全屏刷新地图，屏幕会轻微闪烁。这是因为你在重绘过程中，先清屏再画新地图，清屏和画图之间存在视觉空隙。

解决办法有两种。第一种是直接按需更新：只重绘发生变化的格子。玩家移动一个格，其实只有新旧位置两个格子需要更新。这个方案效率最高，但意味着程序必须知道哪些格子变了，逻辑会复杂一些。第二种是初始化时把静态格子全部写入显存，然后每帧只更新动态元素（玩家和箱子）。对推箱子来说，墙和目标点永远不变，所以可以在加载关卡时一次性画好，之后每帧只更新玩家位置和箱子位置。

我在最终版里采用的设计是：加载关卡时全量绘制一次；游戏循环中，每次移动后只更新四个格子——玩家离开的格子、玩家到达的格子、箱子离开的格子、箱子到达的格子。通过这种局部刷新，屏幕闪烁几乎消失，字符稳稳地跳动，体验好了很多。

注意：这里的“四个格子”只在推动箱子时出现。如果玩家只是普通走到空地，那就只更新两个格子。如果你的移动逻辑统一走函数，可以在函数里判断是否推了箱子，返回一个标志位，调用方根据标志决定刷新几个格子。

7. 个人经验与后续建议

整套项目做下来，我最大的感受是：8086汇编没有想象中那么“可怕”，但它的每一个成功，都是建立在把每一步都想清楚的基础上。不像高级语言那样有垃圾回收和类型系统兜底，汇编里每个字节、每个标志位都可能是Bug的温床，但也正是这种赤裸裸的掌控感，让人在调试通过的那一刻获得巨大的满足。

如果你也想动手做一个类似的汇编项目，我给三点建议。

第一个建议是，地图编码不要想太复杂，用最简单的数字映射就好。有人会想用ASCII字符直接做地图，比如直接定义一个字符串数组，字符本身就是地图元素。这个方案看着直观，但逻辑处理时你不得不用字符比较，而且目标点和箱子状态的组合很难用单个字符表达。用数字编码加查表转换，逻辑清晰，扩展也方便。

第二个建议是，保留一张原始地图，永远不要直接修改它。你可以通过复制到工作区的方式实现重置，也可以在移动时记录撤销栈。但最基本的一条底线是，原始关卡数据必须安全，否则一局玩坏，整个游戏就废了。

第三个建议是，遇到奇怪Bug时，先怀疑标志位和寄存器，再怀疑逻辑。汇编里“代码看着没问题”但跑起来不对，十有八九是某个标志位被意外修改，或者某个寄存器在子程序调用中被覆盖了。我自己就因为在循环里调用了一个会修改CX的子程序，导致外层循环提前终止，排查了一下午才发现问题。

如果你愿意继续往下玩，这个项目还可以加很多扩展：撤销功能（记录历史状态栈）、步数排行榜、关卡编辑器、计时器，甚至用中断定时器做每步的倒计时。哪怕只是加一个音效，用PC喇叭的定时器中断发声，都会让项目更有完成度。

我用纯汇编做推箱子这个项目，最想说的还是那句话：别怕它低级。8086的指令集少得可怜，但它逼你把每一个细节都搞清楚，这种基本功在以后写任何底层代码时都会受益。希望这份复盘能帮你少踩几个坑，早日跑出属于自己的那个字符小人。