简介：面向计算机网络课程设计的完整资料包，覆盖网络聊天程序、Tracert与Ping、基于IP多播的网络会议程序、TELNET终端等经典题目，基于MFC/C++在Visual Studio 2019环境下编写，适合高校学生完成类似实验或课程设计时参考。压缩包共197个文件，包括C++源文件（cpp/h）、工程配置（sln/vcxproj/filters）、界面资源（rc/ico）及编译产物（exe/obj/pdb）等，整体约187.79MB，内部按题目划分目录，便于定位对应工程与文档。每个题目均配有独立工程，可直接编译运行，其中第2、3题带有简单图形化界面。资源还附有课程设计报告（docx），可对照源码理解整体设计思路，也可用于规范化撰写文档，报告中对设计流程和实现细节有较完整说明，可直接作为课程设计说明书底稿。目前已有2932人浏览学习，对于需要快速上手Windows网络编程或完成课设答辩的读者具有较强的参考价值。
1. 计算机网络课程设计（湖科大）.zip：先读报告再碰代码的 MFC 课设包
这个压缩包适合三种人：正在赶计算机网络课设的学生、想快速复习 Windows Socket 编程的开发者、以及需要一份能当作参照物的 MFC C/S 工程的人。它的主体是湖南科技大学的计算机网络课程设计，网络部分用 MFC C/C++ 实现，打包内容围绕一个局域网通信程序展开：服务端监听、客户端连接、消息收发、界面展示，四件事落在代码里，另外附有课程设计报告和演示截图。打开它的正确顺序不是找 exe 双击，而是先读报告里“系统设计”那部分，把模块关系在纸上画出来，再去代码里验证。因为计算机网络这门课的老师最常问的一句话就是：“你为什么这么设计？”
2. 课程设计骨架：MFC 界面线程与 TCP Socket 链路是怎么协作的
2.1 解压后先分四类文件，再读报告里的系统设计
解压这类课设压缩包，我有个固定动作：先看文件清单，按四类归档。这样做的目的不是整理癖，而是后面遇到编译问题、答辩问题时，你能在 30 秒内找到对应的文件去查，而不是在二三十个文件里乱翻。
| 文件类型 | 常见形态 | 在课设中的角色 |
|---|---|---|
| 工程文件 | .sln / .vcxproj | Visual Studio 打开入口，标识项目结构 |
| 源码文件 | .cpp / .h | MFC 类与 socket 逻辑实现 |
| 文档材料 | .docx / .pdf | 课程设计报告、需求说明、答辩稿 |
| 资源文件 | .rc / .ico / .bmp | 对话框界面、图标、版本信息 |
对这份“计算机网络课程设计（湖科大）.zip”，我打开后最关心三个文件：服务端主对话框的实现文件、客户端主对话框的实现文件、以及报告 docx。把这三样先过一遍，基本就能判断这份资源是真有内容还是纯包装。
读报告时重点关注“系统设计”章节。典型的局域网通信课设报告会把系统分成三层：界面层负责显示和输入，逻辑层负责维护连接状态和消息转发，网络层负责 socket 收发。这个分层不是随便画的，它直接决定了你把“断线重连”或“在线列表”加在哪里。很多同学的课设代码把这三层混在同一个函数里，功能能跑但报告无法自圆其说，老师追问两句就露馅。所以拿到这份资源后，我建议你先在报告里找到系统架构图或者模块图，然后对照源码确认它真的按这个结构实现了，而不是只在文档里画了个漂亮图。
2.2 网络核心链路：从 socket 创建到 accept 的完整代码
无论界面多花哨，计网课设绕不开一条链路：socket 创建、bind 绑定、listen 监听、accept 接受、recv/send 收发。以服务端为例，我最常用这套骨架代码来讲解：
// 1. 创建监听套接字 SOCKET listenSock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (listenSock == INVALID_SOCKET) { AfxMessageBox(_T("socket 创建失败")); return; } // 2. 绑定本机地址和端口 SOCKADDR_IN addr; addr.sin_family = AF_INET; // IPv4 地址族 addr.sin_port = htons(8888); // 端口 8888，服务端必须固定 addr.sin_addr.S_un.S_addr = htonl(INADDR_ANY); // 监听本机所有网卡 if (bind(listenSock, (SOCKADDR*)&addr, sizeof(addr)) == SOCKET_ERROR) { AfxMessageBox(_T("bind 失败，端口可能被占用")); closesocket(listenSock); return; } // 3. 进入监听状态 if (listen(listenSock, 5) == SOCKET_ERROR) { AfxMessageBox(_T("listen 失败")); closesocket(listenSock); return; } // 4. 等待并接受客户端连接 SOCKADDR_IN clientAddr; int len = sizeof(clientAddr); SOCKET clientSock = accept(listenSock, (SOCKADDR*)&clientAddr, &len); if (clientSock == INVALID_SOCKET) { AfxMessageBox(_T("accept 失败")); closesocket(listenSock); return; }这段代码里我最想强调的三个点，答辩时也最容易考。第一是htons(8888)，端口号必然涉及大小端转换，不转的话 bind 会被拒绝或者绑到错误的端口上。第二是htonl(INADDR_ANY)，它让服务端监听所有网卡，包括回环地址和局域网地址，这样实验机器和演示机器之间才能互相连。第三是listen的第二个参数 5，它表示未 accept 的连接队列最大长度，并不表示最多支持 5 个客户端同时在线——这两个概念在计网教材和面试题里反复出现，老师也很喜欢拿它做追问点。
注意：服务端端口尽量选 1024 以上的数值，比如 8888、6666 这类好记的端口，避开系统保留区间。
2.3 阻塞与非阻塞：recv 循环和 CAsyncSocket 的差别
accept 之后的收发逻辑是课设代码里最容易写糊的部分。最原始的方式是在 worker 线程里写一个 while 循环，不断阻塞地 recv：
// worker 线程：循环接收数据 char buffer[1024] = {0}; int nRecv; while (m_bRunning) { nRecv = recv(clientSock, buffer, sizeof(buffer) - 1, 0); if (nRecv > 0) { buffer[nRecv] = '\0'; // 把 buffer 交给界面层显示 ::PostMessage(m_hNotifyWnd, WM_NET_DATA, 0, (LPARAM)new CString(buffer)); } else if (nRecv == 0) { // 对端正常关闭，退出接收循环 break; } else { // 错误，或者非阻塞模式下暂时没有数据 break; } }这段代码的逻辑很直接，但它把成败压在一个m_bRunning标志位上：如果线程正在阻塞 recv，你只把这个标志位改成 FALSE，线程并不会立刻退出，只能在窗口关闭时靠closesocket让 recv 返回错误来唤醒。而CAsyncSocket的写法是完全事件驱动的，收到数据自动触发OnReceive，界面刷新更自然，但状态机也更隐蔽。
所以在报告里，两种方式都必须交代清楚用的是哪一种。阻塞式容易理解、代码直白，适合课设展示；非阻塞事件驱动更贴近 Windows 编程习惯，但初学时调试难度更大。不要试图两种混着写，否则线程安全问题和消息遗漏问题会一起来。
2.4 报告配图与设计说明：课设文档要覆盖的四块内容
这份压缩包里的课程设计报告，是另一个值得反复读的东西。一份计网课设报告写得及不及格，其实就看四块内容有没有真正对上：需求分析要对上“要解决什么问题”，系统设计要对上“用什么技术解决”，核心代码要对上“最难的技术点怎么落地”，测试结果要对上“怎么证明它确实解决了”。四块内容里，测试结果是最容易被忽视的，很多报告放两张界面截图就草草收尾。但实际上老师判断一份课设是不是自己写出来的，最重要就是看测试部分有没有异常场景，比如端口被占用、客户端强行断开、消息长度超过缓冲区，这些场景的截图比十行文字更有说服力。
我看这份资源的报告时，会重点看它是否画了“客户端-服务端-客户端”的通信时序图。计网课设离不开时序，通信建立的三次握手、数据收发的请求响应、断开时的流程，能在报告里用箭头画清楚，答辩就成功了一大半。核心代码部分则要挑 socket 初始化、accept 循环、recv 数据处理这三个片段来讲，每段配一段注释，而不是把整个 cpp 文件粘贴上去。
3. 重新编译并跑通这份 MFC 工程：环境、配置与联调顺序
3.1 编译环境准备：VS 版本、字符集与 MFC 初始化
拿到 MFC 源码，第一关是让它在自己机器上编译通过。MFC 对 Visual Studio 版本很挑剔，老工程在新 VS 里打开一般会弹“是否升级”，正常点继续即可。升级完成后，不要急着 F5，先去项目属性里检查三处：平台工具集用的是 v140 还是 v142；字符集是使用 Unicode 还是多字节；MFC 的使用方式是静态库还是共享 DLL。
// 一个典型的 MFC 对话框程序启动入口 BOOL CNetApp::InitInstance() { // 初始化 MFC 支持的环境 if (!AfxSocketInit()) { // 必须调用，否则 socket() 直接失败 AfxMessageBox(_T("Socket 初始化失败")); return FALSE; } CNetDlg dlg; // 主对话框 m_pMainWnd = &dlg; dlg.DoModal(); return FALSE; }AfxSocketInit()是 MFC 封装 Windows Sockets 的入口初始化函数。它负责加载 Winsock 库，如果遗漏，后续调用socket()会返回INVALID_SOCKET，但不会弹任何有意义的提示，排查起来特别像黑匣子。我自己的习惯是在InitInstance里第一时间调用它，并把返回值检查写死。
平台工具集的匹配问题也很典型。如果资源是用 VS2015 或更早版本写的，而本机只有 VS2019，升级向导通常会把 v140 改成 v142，编译时可能出现一堆宏定义或 MFC 头文件错误。我的做法是先看错误列表里的第一条，如果是“cannot open include file: afxwin.h”这类，优先检查 MFC 组件是否安装，而不是去改代码。安装 VS 时勾选“使用 C++ 的桌面开发”会一并带上 MFC 库，默认不带的话在“单个组件”里单独补装。
字符集设置是第二个常见坑。项目属性中如果选择“使用 Unicode 字符集”，所有CString默认是宽字符；如果报告里的截图和代码都基于多字节字符集，那么发送中文时会存在隐式转换问题。我建议确认一下资源里的代码用的是什么字符集再动手，尽量跟随原工程配置，不要中途切换。
3.2 本机联调顺序：先服务端后客户端，用 netstat 验证监听
编译通过后，联调顺序很有讲究：先启动服务端，确保它在监听状态，再启动客户端去连。服务端启动后，窗口上通常有一个“开始监听”按钮，点击后界面状态应该从“未启动”变成“等待客户端连接”。此时先别开客户端，打开 cmd 用 netstat 验证端口是否真的在监听：
# 查看所有 TCP 监听状态，过滤出 8888 端口 netstat -ano | findstr 8888如果输出里有LISTENING那一行，说明监听成功；如果什么都没有，先回代码检查 bind 是否返回错误、端口是否被其他程序占用。占用的情况很常见：上一次运行的程序没退出，或者被 IDE 调试残留进程占住，用tasklist /FI "PID eq <pid>"确认后结束它即可。
Windows 10/11 默认没启用 Telnet 客户端，可以在“启用或关闭 Windows 功能”里勾上“Telnet 客户端”，然后用telnet 127.0.0.1 8888发起测试。如果服务端监听正常，telnet 窗口会保持连接不退出，说明端口通了；如果提示连接失败，说明监听状态或者防火墙还有问题。这个工具在查“端口到底有没有监听”时比写客户端更省事，答辩现场也适合用来证明服务端真的在等连接。
客户端那边，IP 的填写有讲究。本机联调填127.0.0.1最快；要验证局域网场景，填服务端机器的实际局域网 IP。用ipconfig查到的 192.168.x.x 那一串就是。填完后点击“连接”，正常情况下客户端状态栏会显示“连接成功”，服务端的在线列表里也会多出一行客户端记录。
3.3 Debug 与 Release：演示环境尽量用静态链接
很多初学者只在 Debug 配置下验证功能，答辩时也一路用 Debug 跑，我强烈不建议。Debug 版本默认带调试信息、优化少、依赖调试环境 DLL，换台电脑经常启动报错。答辩演示至少提前三天切换到 Release 配置重新编译一遍，并用 Release exe 跑完整个演示流程。
Release 编译后的检查顺序是：一，运行库改成静态链接（/MT）；二，MFC 设置为在静态库中使用；三，把 exe 单独复制到一个空白目录启动测试。如果做到这三步，exe 基本可以脱离开发环境直接运行。
我在实际项目里见过太多次这种翻车：Debug 能跑，Release 一启动就崩溃，原因是代码里有未初始化的变量，Debug 会把它填充成固定模式，Release 直接给随机垃圾。这类问题查起来非常耗时，所以拿到别人源码时，我习惯先在 Release 下编译一次，第一时间暴露这类问题，而不是等到答辩前夜。
还有一种经常被忽略的情况：资源包里自带的 exe 可能是编译时的残留产物，并不一定和当前源码对应。如果演示时发现程序行为和代码逻辑对不上，优先自己重新编译一遍再拿去用，不要迷信包里自带的二进制。毕竟课设资源的源码价值，在于你可以改，而不是只能跑。
4. 参数与代码改造：从改端口到自定义应用层协议
4.1 把硬编码 IP 和端口改成界面可配置
原课设代码里最常出现这种写法：
#define SERVER_IP _T("127.0.0.1") #define SERVER_PORT 8888在测试阶段写死 IP 没问题，但答辩演示时需要连不同机器，把 IP 写死会让演示变得很尴尬。更稳妥的做法是把服务器端口、客户端要连接的端口和 IP，统统放到对话框里让用户填。以服务端为例：
// 从界面控件读取端口号 CString strPort; GetDlgItemText(IDC_EDIT_SERVER_PORT, strPort); int port = _ttoi(strPort); // 把字符串转成整数 if (port < 1024 || port > 65535) { AfxMessageBox(_T("请输入 1024~65535 之间的端口号")); return; }参数说明：_ttoi在 Unicode 环境下也能直接处理CString，比atoi更通用，不会因为窄宽字符转换出问题。端口检查范围只拦截明显非法值，不必做得太严格，课设阶段能防住手误即可。
IP 的读取同理，从IDC_EDIT_CLIENT_IP控件取字符串，直接作为connect的参数。这样改完以后，客户端和服务端的 IP、端口都不需要重新编译就能适配不同实验环境，报告里还能多一段人机交互设计的描述。
既然端口和 IP 可配，还可以考虑让程序记住上次填的配置。课程设计不要求做配置文件，但如果想让报告多一点工程化味道，可以用GetPrivateProfileString和WritePrivateProfileString读写一个config.ini，启动时自动加载上次填写的 IP 和端口。这是 Windows 自带的 INI 读写接口，两三行代码就能让程序记住配置，比每次都手填体验好很多，而且答辩时多了一个可讲的模块。
4.2 解决粘包问题：加一个消息头而不是裸发字符串
TCP 是流协议，它只保证字节流的有序到达，不保证一次 recv 收到的就是一条完整消息。发送方连续两次 send，接收方可能一次 recv 就全部收走，这叫粘包；一条大消息被分成多个 TCP 段，接收方可能分几次才收完整，这叫半包。课设里最常见的错误是直接 recv(1024) 然后当作一条消息去显示，发送多条消息后界面出现乱行或者数据错位。
解决这个问题的经典做法是自定义一个消息头，把长度放在最前面：
// 应用层消息协议：4 字节长度 + 数据区 struct NetMsg { int nLen; // 数据区长度（不包含这 4 字节本身） char szData[1024]; // 数据区 };发送时先填 nLen 再整个发出去。接收时则需要一个“攒数据”的逻辑：先把 4 字节长度收齐，再按长度循环收数据区，直到收够 nLen 个字节才算收到一条完整消息。收完后要检查是否有多余的字节，如果有，说明下一条消息的数据已经混进来了，需要把它们保留到下一个缓冲区头部，而不是直接丢掉。
处理半包时还要注意 recv 返回 0 和返回 SOCKET_ERROR 的区分。返回 0 表示对端正常关闭连接，此时要立即结束接收循环，因为后续再 recv 已经没有意义。返回 SOCKET_ERROR 要调用WSAGetLastError()看错误码，尤其非阻塞模式下WSAEWOULDBLOCK表示暂时没有数据，不能当作连接断开来处理。这两个分支要是混淆，程序很快就会出现“客户端掉线后服务端还在傻等”的奇怪状态。
这个逻辑写起来比想象中费劲，但它正好对应计网课上讲过的“IP 分组、路由重组”概念。自己在报告里写清楚“为什么 TCP 流需要应用层协议”，比任何代码都加分。这也是我拿到资源后会重点去确认的地方：原工程是裸收发字符串，还是已经实现了简单的消息帧。
4.3 跨线程通信：PostMessage 把数据从网络线程送回界面
MFC 的界面控件只能在界面线程里操作，网络收发线程属于 worker 线程，不能直接调用控件方法。标准做法是使用PostMessage向主窗口投递自定义消息，在接收方把 CString 转成窗口可显示的文本：
// worker 线程收到数据后投递消息 ::PostMessage(m_hNotifyWnd, WM_NET_MSG_RECV, 0, (LPARAM)new CString(pBuffer, nLen)); // 主窗口头文件中声明消息处理函数 afx_msg LRESULT OnNetMsgRecv(WPARAM wParam, LPARAM lParam); // 主窗口实现文件的消息映射表里注册 ON_MESSAGE(WM_NET_MSG_RECV, &CMainDlg::OnNetMsgRecv) // 消息处理函数里取出字符串并刷新控件 LRESULT CMainDlg::OnNetMsgRecv(WPARAM wParam, LPARAM lParam) { CString* pMsg = reinterpret_cast<CString*>(lParam); if (pMsg) { m_editHistory.AppendText(*pMsg + _T("\r\n")); delete pMsg; // new 出来的对象必须在这里释放 } return 0; }其中WM_NET_MSG_RECV要自定义，一般用WM_USER + 100这样的值，避免和系统消息冲突。使用PostMessage而不是SendMessage的原因是它非阻塞，网络线程不会因为界面刷新慢而被拖住。另一个容易忽略的点是lParam指向的堆对象：谁 new 谁负责释放，这里在界面线程 delete，避免在堆上累积出内存泄漏。如果你用任务管理器抓内存，发现程序占用持续上升，多半就是这里漏了一处 delete。
线程的生命周期和窗口句柄的关系也很关键。PostMessage 投递到的是一个窗口句柄，如果 worker 线程在窗口销毁后才投递消息，消息就会丢失，极端情况下还可能访问到已释放的句柄地址。所以在关闭窗口时，必须先让 worker 线程退出，再销毁窗口，这个顺序我在避坑部分的 5.4 里还会展开。这三个改造下来，端口 IP 可配、消息不粘包、界面刷新不卡，一份课设从“能跑”变成“能讲清楚”了。
5. 计算机网络课程设计避坑：5 个真实踩过的坑
5.1 现象：双击 exe 启动直接闪退，连窗口都没看到
这是我在 MFC 课设资源里遇到最高频的启动问题。现象是双击后没有反应，或者弹出一个对话框一闪而过，任务管理器里进程也消失了。排查思路要按优先级来：第一个查InitInstance里有没有调用AfxSocketInit()，没调用的话 socket 相关所有调用都会失败；第二个查端口是不是被占用，bind返回错误会导致对话框初始化失败；第三个查是不是有静态变量在对话框创建前访问了未初始化的对象。
具体到解决，我在调试时惯用流程：先用 Debug 编译，在InitInstance入口打断点，单步走一遍，看到底是哪一步跳出了DoModal。如果是bind失败，用 cmd 执行netstat -ano | findstr 8888找到占用进程并杀掉。如果这些都查不到原因，把AfxMessageBox加到每个失败分支里。这一步虽然土，但能把黑匣子变成可见的失败点，比自己猜要快得多。
5.2 现象：本机能连接，但局域网内其他电脑连不上，显示超时
这是计网课设最经典的局域网翻车现场。代码没问题，服务端确实在监听，可另一台电脑的客户端就是连不上。先剥洋葱：第一步看网络，两台机器在同一个网段，能互相 ping 通；第二步看服务端绑定地址，如果 bind 的是127.0.0.1，那么只有本机能连；第三步看防火墙，Windows 默认会拦截入站连接，需要给 exe 增加入站规则，允许 TCP 对应端口通过。
解决步骤也很具体：代码里绑定地址用htonl(INADDR_ANY)，不要写死回环地址；然后“控制面板 → Windows Defender 防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口 → TCP → 填 8888 → 允许连接”。如果还不行，检查是不是所在的无线网络开了 AP 隔离，或者实验室的交换机端口隔离，这种情况就不是代码能解决的了，换有线网或者换一个网段再试。
5.3 现象：发送消息正常，但中文传到对方显示成问号或乱码
乱码的根因只有一个：发送方和接收方对字节流的解释不一致。MFC 有两种字符集：Unicode 下 CString 内部是宽字符，一个中文字符占 2 字节；多字节字符集下 CString 内部是窄字符，一个 GBK 中文字符也占 2 字节。如果在 Unicode 工程里把CString的内存直接当 char 数组发送，那么每个字符的第二个字节会被当成另一个字符，中文就会变成乱码。
我的建议是把字符集统一改为多字节，这样CString可以直接用GetBuffer传入 socket 发送。如果非要保持 Unicode，则发送前用WideCharToMultiByte转成 UTF-8 再发，接收后再MultiByteToWideChar转回。重点是不能在界面和网络层各用一套编码而不做转换，这是课设代码里最常见的隐性 bug。
5.4 现象：点击关闭窗口后程序卡死，任务管理器显示未响应
卡死的原因几乎都是窗口退出时网络线程还活着。MFC 关闭对话框会做两件事：销毁窗口，然后结束消息循环。如果 worker 线程还在阻塞 recv，窗口销毁后，线程试图用已销毁的窗口句柄投递消息，就可能导致卡死。
解决办法是在OnClose里先做三件事：设置退出标志位让线程循环条件失效；调用shutdown或closesocket让阻塞的 recv 返回错误；用WaitForSingleObject等待 worker 线程收尾退出。这三步顺序不能反，只要套接字没有先关闭，recv 就不会从阻塞中返回，线程也就永远不会退出。我在前面第 2.3 节的代码里强调那个 while 循环，实际是围绕这个退出逻辑设计的。任务管理器里如果看到两个同名进程，说明上一个没退出的实例还挂在那边，先全部结束再重新跑。
5.5 现象：Release exe 拷到别的电脑报“缺少 mfc140u.dll”
这个问题在答辩前发生率极高。原因就这么一句话：编译时 MFC 使用方式选了“共享 DLL”，生成的可执行文件没有把运行环境打包进去。目标机器没有安装对应的 Visual C++ Redistributable，就会在启动时提示缺少 DLL。
解决方式有两种：一个是给目标机器装 vc_redist 运行库，比较麻烦；另一种是让 exe 自体吃饱，项目属性 → 常规 → MFC 的使用 → 在静态库中使用 MFC；C/C++ → 代码生成 → 运行库 → 多线程 (/MT)。改完重新编译，exe 体积会变大，但换电脑直接双击就能跑。强烈建议在演示前做这一步，省去答辩现场装运行库的尴尬。如果你有条件，最好找一台没装过 VS 的电脑或者开个干净的虚拟机验证一下，别等站在答辩教室才发现起不来。
6. 验收前最后一步：用一张表和一套脚本把课设讲完整
6.1 对照评分点自查
答辩讲得清不清楚，先看有没有覆盖这些点：
- 通信建立：端口和 IP 是否可配置，bind/listen/connect 链路是否完整，内存释放和异常分支是否都有处理。
- 消息收发：是否解决了粘包半包，中文是否乱码，收发的编码是否一致。
- 界面交互：收到消息后控件是否即时刷新，窗口关闭时线程是否退出，在线状态是否可见。
- 测试与验证：是否用 netstat 验证过监听，是否尝试过局域网环境连接，是否准备两条异常场景的说明。
6.2 演示脚本和一个收尾习惯
答辩演示脚本要可复制：双击 Release exe 启动服务端，点击“开始监听”；再启动两个客户端，一个填 127.0.0.1，一个填局域网 IP，互发两条消息，其中一条要带中文；然后切到服务端窗口，显示在线列表里有两个客户端；最后打开 netstat 截图说明 8888 端口确实在监听。每一步对应报告中的一张图，讲完刚好落在“TCP 可靠传输”上。
也是因为这个资源，我后来每次接手别人的课设代码，都会强制自己先走一遍关闭窗口的测试。先确认网络线程能干净退出，再谈功能扩展；先能在 Release 下跑通，再去调界面配色。课设翻车大多不是在新技术上，而是在最基础的生命周期管理上。这次的避坑清单和自定义协议改造，算是电脑里常备的一张后悔药，希望帮到你。
本文还有配套的精品资源，点击获取
