简介用C语言与EasyX库实现的简易植物大战僵尸是一份C语言程序设计期末作业的完整课程设计资源。面向计算机相关专业在校生尤其适合需要完成游戏类课程设计或初次接触EasyX图形编程的读者可借鉴其代码组织、碰撞检测与动画控制思路。压缩包共98个文件大小16.73MB主要包含cpp源码、Visual Studio工程文件、大量gif动画序列、jpg/png/bmp图像素材、mp3背景音乐及psd设计源文件代码与美术资源均齐备可直接运行体验并替换素材。项目已通过功能测试答辩评审平均分达96分完成度较高当前已有118人学习下载。配套README与文档说明梳理了项目结构与启动方法便于快速上手亦可在此代码基础上扩展新关卡、植物类型或音效适合作为课程设计模板和入门进阶练习项目。1. 用 C 语言和 EasyX 做一个植物大战僵尸为什么期末作业选它用 C 语言和 EasyX 库写一个植物大战僵尸是很多 C 语言程序设计期末作业里的经典选项。它不像图书管理系统那样只操作几张表也不像贪吃蛇那样几十行就能写完难度正好卡在“要动点脑子、但不至于做不完”的位置上。用 EasyX 的好处是装一个库就能画图、处理鼠标键盘不用碰 Windows API 那一大堆消息循环细节新手能把注意力放在游戏逻辑上。这篇笔记会带你走一遍完整的落地路径从窗口骨架、僵尸链表、卡片冷却到读档存档把每个模块的代码和参数都讲清楚照着敲就能交出一份能演示的期末作业。2. 先搭骨架把 EasyX 窗口、游戏循环与碰撞检测跑通2.1 环境准备与库的选择为什么用 EasyXEasyX 是 Windows 下一个轻量的图形库它封装了 GDI 绘图接口让 C/C 程序可以像 Turbo C 时代那样直接画点、画线、贴图。选它做期末作业主要是因为成本低一个头文件、一个静态库装完就能用不需要引入 Qt 或 SDL 这种重型依赖。如果你用的是 Visual Studio直接去 EasyX 官网下载安装包它会自动匹配 VS 版本如果你用 Dev-C需要手动把 include 和 lib 路径配到编译器里。我一般不建议在这步花太多时间折腾装好之后先跑通一个能弹出窗口的程序确认环境没问题再做游戏逻辑。用 EasyX 做植物大战僵尸还有一个隐性好处它能用IMAGE对象直接装载.png和.jpg图片植物和僵尸的素材可以从网上找现成的素材包不需要自己画图。这对期末作业来说很实际因为绘图不是你课程设计的考察重点游戏逻辑才是。素材路径建议放在项目目录下的res文件夹里并统一用相对路径加载避免交作业时路径失效。2.2 最小窗口骨架初始化、画布与消息循环先写一个能运行的最小骨架验证环境没问题。下面这段代码会创建一个800 * 600的窗口背景填充为绿色并处理关闭按钮事件。#include graphics.h #include conio.h int main() { // 初始化图形窗口宽度800高度600 initgraph(800, 600); // 设置背景色为草地绿 setbkcolor(RGB(90, 160, 90)); cleardevice(); // 消息循环EasyX 用 peekmessage 非阻塞获取消息 ExMessage msg; while (true) { while (peekmessage(msg, EX_MOUSE | EX_KEY)) { if (msg.message WM_CLOSE) { // 用户点了窗口关闭按钮 closegraph(); return 0; } } // 暂时空转后面游戏循环会放在这里 Sleep(10); } }initgraph是 EasyX 的窗口初始化函数参数分别是宽度和高度单位是像素。peekmessage是非阻塞的它会从消息队列里取一条消息没有消息时立即返回如果用getmessage程序会卡在等待用户输入上导致游戏画面无法持续刷新。WM_CLOSE是窗口右上角关闭按钮产生的消息如果不处理它窗口点了关闭后进程还活着只能靠任务管理器杀掉。代码里的Sleep(10)是为了防止空转把 CPU 占满。这里有个容易踩的坑Sleep的单位是毫秒如果写成Sleep(10)循环每秒最多跑 100 次刚好可以作为后面游戏循环的帧率基准。但要注意Sleep的精度受系统时钟影响实际误差一般在 10 到 20 毫秒所以它只适合做粗粒度控制后面做卡片冷却计时时不能靠它数秒。2.3 游戏循环的帧率控制Sleep 与定时器怎么选游戏循环的经典写法是固定每次刷新间隔比如每帧 16 毫秒对应约 60 FPS。但 EasyX 的绘图效率不高尤其是背景贴图加多个精灵绘制时一帧可能超过 30 毫秒。我建议把目标帧率定在 30 FPS也就是每帧约 33 毫秒这样既能保证流畅度又给绘图留足余量。const int FRAME_INTERVAL 33; // 目标每帧间隔毫秒 DWORD lastTime GetTickCount(); while (running) { DWORD currentTime GetTickCount(); DWORD elapsed currentTime - lastTime; if (elapsed FRAME_INTERVAL) { update_game(elapsed); // 更新游戏逻辑 draw_game(); // 绘制画面 lastTime currentTime; } else { // 距离下一帧还有时间让出 CPU Sleep(FRAME_INTERVAL - elapsed); } }GetTickCount返回系统启动以来的毫秒数用它做帧间隔判断比裸Sleep稳定。这里把逻辑更新和绘制分开是因为后面要管理僵尸链表和子弹列表如果每帧都执行逻辑刷新频率不一致会导致移动速度忽快忽慢。传入elapsed参数后移动距离按比例计算比如僵尸速度是每秒 20 像素那么一帧里应该移动20.0 * elapsed / 1000.0像素这样不管帧率波动多大位置的推进速度都是一致的。需要注意DWORD是无符号 32 位整数GetTickCount在系统运行 49 天后会回绕到 0但课程设计运行时间很短不用考虑这个边界情况。如果后面加了timeSetEvent高精度定时器才需要单独做时间换算。2.4 初步的碰撞检测矩形相交与网格简化植物大战僵尸里的碰撞可以分为两类子弹打中僵尸以及僵尸碰到植物。最简单的做法是矩形相交检测每个对象维护一个RECT结构存左上和右下两个点的坐标然后两两判断是否重叠。对于数量不超过几十个的游戏对象两两遍历的性能完全够用。// 矩形相交判断返回1表示两个矩形重叠 int rect_hit(RECT a, RECT b) { // 只要两个矩形在某条轴上不重叠就说明没碰上 if (a.right b.left || b.right a.left) return 0; if (a.bottom b.top || b.bottom a.top) return 0; return 1; }这是最朴素的碰撞检测但它有一个问题僵尸移动速度较快时两颗子弹之间可能正好跨过了僵尸的位置出现“穿模”现象。解决办法有两种一是把子弹的碰撞矩形按上一帧到本帧的移动轨迹合并成一个长条矩形二是限制每帧移动距离不超过僵尸宽度的三分之一。我一般用第二种因为改动小而且 EasyX 游戏里对象速度都不会设得太离谱。网格简化是在地图上预铺一个9 * 5的格子数组每格大约80 * 100像素植物只能种在格子里。这样碰撞检测可以跳过大部分无关对象子弹只需要判断自己所在列的格子内是否有僵尸僵尸只需要判断自己所在列的第一株植物是否在脚下。这个优化能让逻辑更清晰也能避免后期植物多了之后卡顿。3. 把“僵尸”做成链表出怪节奏与碰撞计分的实现3.1 僵尸链表的结构体定义与初始化僵尸数量不是一个写死的数组长度它会在游戏过程中不断产生所以用链表管理最合适。每个僵尸节点保存位置、血量、行走状态还有一个指向下一个节点的指针。链表的好处是插入和删除都是常数时间尤其是僵尸死亡时从中间摘掉一个节点的操作非常简单。typedef struct Zombie { int x, y; // 僵尸左上角坐标 int hp; // 当前血量 int speed; // 每帧移动像素数 int state; // 0行走 1攻击 2死亡 struct Zombie *next; // 指向下一个节点 } Zombie; // 头节点不存数据简化插入和删除逻辑 Zombie *zombieList NULL; void zombie_init() { // 分配一个哨兵头节点 zombieList (Zombie *)malloc(sizeof(Zombie)); zombieList-next NULL; } void zombie_add(int x, int y, int hp, int speed) { Zombie *newZ (Zombie *)malloc(sizeof(Zombie)); newZ-x x; newZ-y y; newZ-hp hp; newZ-speed speed; newZ-state 0; // 头插法新僵尸插到最前面遍历时自然先处理最新生成的 newZ-next zombieList-next; zombieList-next newZ; }这里把链表头设计成哨兵节点不存真正的数据。删除某个僵尸时统一用prev-next target-next来摘除不需要额外判断“删的是不是头节点”。头插法的好处是插入成本最低且后生成的僵尸天然排在链表前面遍历时优先处理。坏处是如果后续要做“按生成顺序播放动画”就得改尾插但课程设计里一般用不到。内存管理是链表最容易翻车的地方。僵尸死亡后要free节点否则每波出怪都会泄漏内存。写删除函数时务必在free之后把前驱的指针更新好避免出现悬空指针。我这里习惯用一个zombie_remove(Zombie *target)函数内部先找到前驱节点再摘除这样调用方不需要关心链表结构细节。3.2 出怪节奏的算法波次表与计时触发植物大战僵尸的出怪节奏不是随机乱出而是有一个波次表第几秒出什么类型、出几只是有规律可循的。课程设计不需要做得那么复杂直接用一张静态表加一个计时器就行。我通常定义这样的结构体数组typedef struct Wave { int startTime; // 游戏开始后的秒数 int count; // 生成数量 int hp; // 僵尸血量 int speed; // 僵尸速度 } Wave; // 示例波次表40秒第一波75秒第二波110秒第三波 Wave waveTable[] { {40, 3, 100, 20}, {75, 5, 120, 22}, {110, 8, 150, 25}, }; #define WAVE_COUNT (sizeof(waveTable) / sizeof(waveTable[0]))游戏主循环里记录一个gameTime变量每帧累加elapsed / 1000.0秒。每次波次触发后用一个标志位标记该波次已经出过防止重复生成。生成时做一个随机偏移让同一波僵尸的纵向位置在y ± 30像素内抖动否则所有人都在同一行看起来就像排队散步。有个细节是表里配置的僵尸是“同一时间全部生成”还是“间隔几秒逐个出现”全部生成会让玩家瞬间面对一大片压力太大。我建议做成逐个出现波次触发后每隔 1.5 秒生成一只。实现方式是在波次结构里加一个spawnInterval和spawnedCount主循环里按计时触发而不是一次性把所有节点都zombie_add进去。3.3 碰撞检测与计分数组遍历和链表遍历的差别子弹打在僵尸身上需要遍历链表里的每个僵尸判断是否命中。如果子弹数量也不大直接外层遍历子弹数组、内层遍历僵尸链表即可复杂度是O(子弹数 * 僵尸数)最多几百个对象完全跑得动。// 遍历僵尸链表扣血并判断死亡 void hud_hit_check() { Zombie *p zombieList-next; while (p ! NULL) { // 每个子弹对象独立判断自己的矩形是否命中当前僵尸 for (int i 0; i bulletCount; i) { if (bullets[i].active rect_hit(bullets[i].rect, get_zombie_rect(p))) { p-hp - bulletPower; bullets[i].active 0; // 子弹命中后消失 if (p-hp 0) { p-state 2; // 死亡 score 10; } break; // 一颗子弹只打中一个僵尸 } } p p-next; } }这段代码里有个容易被忽略的优化手段把僵尸的矩形计算封装成get_zombie_rect(p)而不是每个循环里手动写RECT初始化。原因很简单后续如果要给僵尸加攻击状态矩形会随动画帧变化集中成一个函数后只改这一个地方。同样地score 作为全局变量在碰撞检测里直接累加后面做 UI 绘制时从它取值就行。链表遍历和数组遍历的最大差异在删除时体现出来。数组删除中间元素要挪动后面的所有元素链表删除只需要改两次指针。但这会儿用的是标记删除先把active置 0等主循环的清理阶段统一把active 0的节点free掉。我建议别在碰撞循环里直接free否则遍历指针会乱套调试起来非常痛苦。4. 卡片冷却与阳光掉落游戏数值的计时与参数调整4.1 卡片冷却tick、高精度计时与半秒处理卡片冷却控制着玩家不能连续种植同一种植物是游戏节奏的关键。传统做法是记录上次种植时刻每次点击卡片时判断当前时刻与上次时刻的差值是否超过冷却时间。在 C 语言里我一般用clock()或GetTickCount()做这个判断。注意clock()返回的是进程 CPU 时间单位是毫秒但精度依赖系统时钟误差约 10 毫秒对冷却这种秒级判断完全够用。// 卡片冷却状态每个卡片一个 typedef struct CardCoolDown { int lastUsedTime; // 上次使用时的系统毫秒数 int coolTime; // 冷却时长毫秒 int ready; // 1可用 0冷却中 } CardCoolDown; int card_can_use(CardCoolDown *card, int now) { // 冷却剩余时间 上次使用时间 冷却时长 - 当前时间 if (now - card-lastUsedTime card-coolTime) { card-ready 1; return 1; } return 0; }这里有个边界坑如果now是从GetTickCount()拿到的无符号整数直接计算now - lastUsedTime在正常情况下没问题但如果中间系统休眠过这个差值会变得超大可能导致冷却瞬间完成。我一般会在主循环里统一把now转成DWORD并且冷却判断只用加减法不用除法避免整数溢出和浮点误差。关于半秒处理EasyX 里图片切换、文字闪烁这类视觉反馈如果每帧都更新会显得太快所以常用“半秒到一秒”的节拍刷一次。比如冷却图标上的遮罩按 500 毫秒为单位渐变看起来很流畅也不会导致画面狂闪。用elapsed累积一个uiTick到 500 毫秒就翻转一次状态比每次都用Sleep精准得多。4.2 阳光掉落与收集随机函数边界与命中判定阳光是玩家种植的资源阳光掉落需要设计随机性但rand()的默认随机序列是固定的每次运行都一样这会导致玩家很快摸透规律。解决方法是先种随机种子srand(time(NULL))。注意time(NULL)的精度是秒如果程序启动间隔不到一秒随机种子可能相同不过课程设计里这个概率很低。// 阳光掉落参数控制 #define SUN_INTERVAL 5000 // 每隔5秒自然掉落一波 #define SUN_RANDOM_X 600 // 掉落横坐标范围 0~600 #define SUN_FALL_SPEED 40 // 阳光下落速度像素/秒 int nextSunTime SUN_INTERVAL; void sun_update(int elapsed) { nextSunTime - elapsed; if (nextSunTime 0) { // 生成一个阳光坐标基于随机数 int sx rand() % SUN_RANDOM_X; int sy 20; // 从屏幕顶部开始下落 sun_create(sx, sy, SUN_FALL_SPEED); // 重置下一次掉落时间并加一点随机偏差 nextSunTime SUN_INTERVAL (rand() % 2000); } }随机数的范围控制容易出事rand() % 600的结果在 0 到 599如果阳光的宽度是 80 像素那么最右侧的右边界是 679已经超过窗口宽度 800但不会出界太多。如果后面加了一个草坪边缘偏移这里就要改成rand() % 500 100让阳光落在安全区域内。命中判定用鼠标点到阳光的矩形上检测鼠标消息里的x, y是否落在阳光矩形内。EasyX 的EM_EX_MOUSE消息里x和y是窗口客户区坐标直接用。阳光收集后要加一点音效或分数反馈否则玩家反馈很干。我习惯在sun_create时用一个全局数组记录阳光对象每帧更新位置并绘制。由于阳光数量通常不多用数组比链表更合适逻辑也更直观。4.3 数值手感调整一局游戏里的时间常数平衡表植物大战僵尸之所以好玩是因为数值经过了大量调整。课程设计不需要做完整平衡但至少要让玩家玩起来不觉得离谱。我总结了三个核心参数必须认真调阳光掉落间隔、卡片冷却时间、僵尸出生间隔。下面这张表是我尝试过的基础数值可以直接套用。参数建议值调整影响阳光自然掉落间隔5 秒越短资源越充裕游戏越简单阳光收集后增加25 点影响玩家能种多少植物向日葵卡片冷却6 秒控制前期铺场速度豌豆射手冷却7 秒主力输出频率普通僵尸出生间隔8 秒一只出怪越密集压力越大僵尸移动速度20 像素/秒太快会碾压防线太慢显得无聊调参的方法是写一个调试开关在游戏启动时按F1打印这些常量到控制台边玩边改。不要每次改代码都重新编译那样浪费时间。我建议把数值全部定义成宏例如#define SUN_INTERVAL 5000修改后重新编译一次就好。如果答辩时老师问“你怎么确定这个平衡”可以回答先让自动脚本跑 500 帧记录胜率再手动微调。虽然课程设计可能没时间做自动化但这个回答方向能加分。5. 避坑与工程结构从交作业到守住代码质量5.1 现象编译报错“无法打开 graphics.h”原因是 EasyX 库没安装成功或者编译器位数不匹配。EasyX 只支持 32 位和 64 位程序在 Visual Studio 里新建项目时一定要选择“空项目”并且确认解决方案平台是 x86 或 x64。如果用的是 Dev-C需要把下载的 include 文件夹里的graphics.h拷贝到编译器 include 目录。解决重新执行安装包选择匹配的编译器版本或者在项目属性里手动添加包含目录。5.2 现象点击窗口关闭按钮程序没有退出原因是WM_CLOSE消息没处理while循环空转窗口虽然消失但进程还挂着。解决按前面的骨架代码在消息循环里判断WM_CLOSE并调用closegraph()后再return。如果你把消息循环和游戏循环写在一起注意peekmessage要在每帧调用一次否则关闭消息可能在忙等中一直得不到处理造成窗口无响应。5.3 现象僵尸删除后遍历链表程序崩溃原因是在遍历过程中直接free了当前节点随后又访问了p-next指针已经失效。解决标记法先遍历一遍把要删除的节点加进一个待清理队列遍历完后再统一free或者在删除前先保存next指针但这样代码容易看花眼。我建议课程设计里用标记法代码更清晰也符合“稳定优先”的原则。// 安全删除僵尸先标记再统一清理 void zombie_sweep() { Zombie *p zombieList-next; while (p ! NULL) { if (p-hp 0) { p-state 2; // 标记死亡 } p p-next; } // 第二遍遍历真正摘除节点 Zombie *prev zombieList; p zombieList-next; while (p ! NULL) { if (p-state 2) { prev-next p-next; free(p); p prev-next; } else { prev p; p p-next; } } }5.4 现象杀毒软件报警或运行崩溃有几种可能Windows Defender 误报新生成的 exe资源加载时使用了绝对路径换机器跑就找不到图片或者图片文件本身损坏。解决把素材放在项目目录下用相对路径加载杀毒误报时在答辩机器上重新编译一次通常就好了。另外EasyX 程序在部分虚拟机里可能没有硬件加速绘制会变慢这是正常的不要以为是代码问题。5.5 把代码拆成多文件用 Makefile 保持可维护课程设计如果只有一个main.c几千行代码后期会让新手指头都大。建议按模块拆分main.c负责主循环zombie.c管理僵尸链表plant.c管理植物与卡片gfx.c封装 EasyX 绘制接口。头文件里只放结构体定义、函数声明和宏常量。这样拆分后每次改一个模块只需要编译那个文件配合 Makefile 或 VS 项目就能快速增量编译。模块间接口要提前约定好。我习惯把跨模块的函数命名统一前缀比如zombie_、plant_、sun_这样阅读代码时看到前缀就清楚属于哪个模块。老师检查代码时也会觉得你有工程意识这一点在答辩时的印象分很重要。5.6 存档与读档用文件 IO 存关卡进度很多课程作业要求“游戏能保存进度”用 C 文件 IO 就能做。常见做法是把当前波次、血量、阳光数和已种植植物列表写入一个文本文件读档时再解析回内存。写的时候用fprintf读的时候用fscanf或者fgets逐行读。// 保存进度到 save.dat void game_save(const char *path) { FILE *fp fopen(path, w); if (fp NULL) return; fprintf(fp, %d\n, gameTime); fprintf(fp, %d\n, sunAmount); fprintf(fp, %d\n, score); // 遍历植物数组按格子和类型保存 for (int i 0; i GRID_COUNT; i) { if (grid[i].type ! EMPTY) { fprintf(fp, %d %d %d\n, i, grid[i].type, grid[i].hp); } } fclose(fp); }读档时要注意文件可能被你改坏所以每一行都要检查解析是否成功。如果fscanf返回值不是预期值就放弃读档、重新开始。另一个坑是存档文件编码Windows 下文本文件默认可能是 GBK如果你在代码里写了中文注释文件打开乱码不影响运行但用文本编辑器保存时别把编码改成 UTF-8 with BOM否则 VS 里编译会报奇怪的字符错误。5.7 交作业前的检查清单文档说明怎么写文档是期末作业评分的重要组成部分尤其当老师没时间细看代码时文档就是第一印象。建议包含这几部分项目结构说明、每个模块的核心函数表、游戏操作说明、设计思路和踩坑记录。操作说明要写清“怎么运行、怎么操作、怎么赢”老师可能没玩过你的游戏如果文档里有截图和步骤他就不需要猜。调试过程那块把自己真实遇到过的报错和解决方式写进去比写成“本系统经过深思熟虑”这种套话有价值得多。代码里也可以写简要注释但不要去注释每一行老师一眼就能看出是凑数的注释。6. 用 glib 给游戏加 BGM小技巧让大作业更完整6.1 为什么选 glib直接用 PlaySound 的坑很多人在做到音频这一步时第一反应是调 Windows 的PlaySoundAPI。它能放 wav但有两个问题一是PlaySound是阻塞的播放循环音效时会卡住主循环导致画面按键失灵二是不支持 mp3而网上找的植物大战僵尸原声大碟多是 mp3。这时候可以引入 glib 的事件循环来播放音频。glib 是 Linux 下 GTK 的底层库但在 Windows 上也可以直接用它提供非阻塞的定时器回调适合把音频播放和游戏主循环解耦。如果你不想引入 glib也可以用mciSendString播放 mp3它是非阻塞的。但mciSendString的字符串命令比较隐晦出错后调试困难。相比之下glib 的g_timeout_add只要注意回调函数内执行时间就不会影响主循环响应。6.2 用 GMainLoop 播背景音乐最小示例下面的示例演示如何用 glib 主循环定时触发 BGM 播放。代码里使用g_timeout_add注册一个定时事件每隔一毫秒检查一次播放状态并用PlaySound异步模式播放下一段音频。#include glib.h #include windows.h #include mmsystem.h // 播放一段wav立即返回 void play_wav_async(const char *name) { PlaySound(name, NULL, SND_FILENAME | SND_ASYNC); } // 每毫秒调用一次的音乐调度回调 gboolean music_tick(gpointer data) { static int part 0; if (part 0) { // 开场先放一段前奏 play_wav_async(intro.wav); part 1; } // 用另一个定时器在合适时机切换主旋律 return G_SOURCE_CONTINUE; } int main(int argc, char *argv[]) { GMainLoop *loop g_main_loop_new(NULL, FALSE); // 注册定时回调间隔1000毫秒 g_timeout_add(1000, music_tick, NULL); // 进入glib主循环事件驱动 g_main_loop_run(loop); return 0; }注意一点PlaySound播放 wav 时会阻塞调用线程直到播完所以在music_tick里判断当前是否在播放避免重复触发。glib 定时回调本身是在主循环线程里执行的如果回调里调用阻塞 API游戏循环就会被卡住。所以我的做法是回调只负责修改一个全局标志位真正调用PlaySound的地方放在单独线程或者用SND_ASYNC让系统去管理播放。6.3 把音频模块接进游戏循环主循环与按键不卡顿最终集成到游戏里时不要把 glib 主循环和你的游戏循环生硬地拼在一起。一个可用的办法是游戏主循环仍然用原来的while跑glib 只用来做音频调度的定时器。在main里先初始化 glib 上下文然后g_timeout_add注册音频回调再进入游戏循环。每次游戏循环里调用g_main_context_iteration(NULL, FALSE)处理到期的音频回调不会阻塞。while (running) { // 处理glib的定时事件非阻塞 while (g_main_context_iteration(NULL, FALSE)) ; // 游戏逻辑与绘制 update_game(elapsed); draw_game(); Sleep(FRAME_INTERVAL); }这样设计后音乐切换由 glib 调度游戏逻辑独立运行两者互不干扰。如果以后想换成跨平台的音频库比如 SDL_mixer只要替换音频调度模块就行游戏的部分不用动。这是我在课程设计里最喜欢的做法每个独立功能用一个小库解决不要在一个文件里堆所有事情。最后作为过来人留一个习惯每写完一个模块就编译一次把错误消灭在增量编译里。我当年赶工的时候经常写完一个文件才编译结果一个下午全在改语法错误差点把交作业的时间都耽误了。希望这个思路和代码片段对你有帮助动手做的时候多留一点调试时间祝你的大作业顺利收尾。本文还有配套的精品资源点击获取
