做网络编程的人多多少少都会遇到一个经典选题——用C/C写一个基于UDP协议的群聊服务器。我第一次看这个题目的时候其实有点懵群聊不是应该用TCP吗消息要可靠到达UDP丢包了怎么办真把自己丢进项目里做了一遍才发现这个题目背后考察的东西比表面上多得多——UDP协议的无连接特性怎么用、多个客户端的在线状态怎么管理、广播消息怎么设计、消息边界在哪里、开发环境怎么搭起来每一步都有坑也每一步都有收获。这篇文章我就把从零开始做“基于UDP协议的群聊服务器C/C”的完整过程摊开讲从协议选型到架构设计从VSCode环境配置到核心代码实现再到实际运行中遇到的诡异问题都记录在这里。适合刚学完Socket编程、第一次接触UDP开发的人直接照着走也适合想快速补一遍C/C网络编程基础的老伙计收藏备用。项目本身不难但把每一行代码背后的“为什么”讲清楚才是真正值钱的部分。1. 为什么用UDP做群聊服务器1.1 理解UDP与TCP的本质差异刚接触网络编程的人常有疑问群聊消息不是应该可靠到达吗为什么总有人推荐用UDP做这个项目要回答这个问题得先把UDP和TCP的区别掰开揉碎看清楚。TCP是面向连接的、可靠的、基于字节流的传输协议。三次握手建立连接、四次挥手断开连接中间的每个报文都有确认和重传机制。它的可靠性建立在复杂的连接状态管理之上。如果用TCP做群聊服务器必须为每一个在线客户端维护一个连接考虑客户端断线后怎么探测、半包和粘包怎么处理、多个连接之间消息怎么同步这套东西对初学者来说很容易把人埋进状态机的泥潭。UDP则完全相反。它是无连接的、不可靠的、基于数据报的传输协议。不需要握手也不需要维护连接状态你把数据包往目标IP和端口一丢剩下的交给网络尽力而为。听起来很“简陋”但正因为无连接UDP天然适合广播和一对多的分发场景。群聊的本质就是一个客户端把消息发到服务器服务器再把消息转发给其他所有人。这种场景下服务器不需要知道每个客户端的连接状态只要知道“往哪个地址发”就够了。丢几个包会造成什么实际影响聊天消息丢了一条用户最多看到消息有跳变重新问一句“你刚才说什么”就完了。但你可以比较一下游戏里的操作指令、语音通话里的音频流这些都是UDP的天下因为它们对实时性的要求远高于可靠性。群聊也是同样的道理——实时送达优先于百分百可靠。1.2 群聊场景与UDP的匹配度分析群聊服务器用UDP还有一个核心原因服务器不需要维护连接代码复杂度直线下降。TCP服务器要处理的事情很多每来一个客户端就要 accept 一个fd、维护fd集合、处理读写事件、处理连接断开通知。而UDP服务器只需要一个socket调用 recvfrom 就能拿到“谁发的、发了什么、什么时候发的”然后调用 sendto 把消息发给目标地址。地址就是你手上现成的 sockaddr_in 结构直接存在数组或者哈希表里就能完成在线用户管理。我后来在实际项目中慢慢意识到群聊服务器的核心功能其实是“转发”收到一个包解析出用户名和消息内容然后发给除发送者以外的所有在线客户端。这个逻辑在UDP下可以用十几行代码完成在TCP下可能要三五十行而且还要处理各种边界情况。当然也要说清楚商用IM系统不会只用裸UDP。微信、QQ这类产品要同时保证速度和可靠通常是UDP做传输、上层自己实现确认重传这是另一个话题。但作为学习项目和面试作品UDP版本既能体现你对协议原理的理解又不会让实现难度失控是很合理的选题。还有一点值得提UDP服务器天然支持多个客户端“同时”发消息。TCP服务器如果采用单线程模型多个客户端同时连接时容易阻塞在某个fd上而UDP socket收到数据报后recvfrom 返回一个完整的报文不存在“这个客户端的数据把另一个客户端的数据堵住”的问题。这一点让服务器端的并发处理变得非常简单直观。2. 整体架构与方案选型2.1 服务器端职责拆解基于UDP的群聊服务器最简单的架构就是一张“转发表”。我把它拆成几个职责创建UDP套接字绑定本机IP和固定端口。循环调用 recvfrom 接收客户端的消息recvfrom 返回数据的同时会把发送者的地址信息填进 sockaddr_in 结构体。收到消息后把发送者地址记录到在线用户表里。如果地址是第一次出现打印“xxx加入群聊”。把消息封装成统一格式例如带用户名和消息内容然后调用 sendto 遍历用户表发给除发送者以外的每一个客户端。定期检查在线用户表把长时间没有发消息的客户端踢下线实现简单的超时机制。在线用户表用什么数据结构我建议初学者直接用std::mapstd::string, sockaddr_in因为需要根据客户端标识比如用户名或者IP端口快速查找地址。如果只是最简单版本用一个std::vectorsockaddr_in存地址列表也完全够用反正遍历广播的时候都要走一遍。不过做过几次之后你会明白用IP端口作为键值最稳妥因为它天然唯一不受用户名重复问题困扰。2.2 客户端职责拆解客户端的结构比服务器简单直观创建UDP套接字不需要显式 bind操作系统会自动为它分配一个临时端口。这样服务器才能通过 recvfrom 获取到你的地址并把消息回传给你。启动两个线程一个发送线程、一个接收线程。发送线程从标准输入读一行文字组装成消息包调用 sendto 发给服务器。接收线程阻塞在 recvfrom 上只要服务器广播了消息recvfrom 就返回并打印到屏幕。为什么要两个线程因为阻塞调用会卡住线程。如果发送和接收都在一个线程里那么你正在 recvfrom 等着收消息的时候输入框就无法读取用户输入聊天体验会非常糟糕。一边收一边发必须要线程分离。2.3 单线程还是多线程——选型背后的权衡服务器端我推荐用单线程主循环不要为每个客户端开线程。原因很简单UDP是无连接的服务器根本没有“每个客户端一个连接”这个概念开线程也没有对应的连接需要服务。你只需要一个 recvfrom 循环所有客户端的消息都会排队进入缓冲区一次一个地取出来处理。如果非要用多线程就做成“接收线程 处理/发送线程”的模式中间用一个任务队列衔接。接收线程只负责把收到的报文push进队列处理线程从队列里取出报文执行广播逻辑。这种做法在你后续扩展成高并发消息转发中间件的时候很实用但现阶段会引入锁和条件变量对新手不够友好。Windows和Linux下的线程API还不一样如果一上来就多线程又要处理平台差异学习曲线陡峭。我的建议是第一版跑通单线程第二版再考虑优化并发模型。我见过很多新手第一版就纠结线程数和锁的性能问题最后连消息都收不到了。2.4 协议设计客户端和服务器之间的约定写Socket程序之前先设计好“协议”也就是双方通信时都遵守的消息格式。这是整个项目最容易被忽略但最重要的一步。TCP有粘包问题需要定义消息边界UDP虽然没有粘包但你必须决定一条消息里放什么、每条消息最大多大、要不要带消息类型。我做这个项目用的协议很简单消息整体是一个字符串不超过8192字节。字符串由两部分组成用户名 分隔符 聊天内容。服务器收到后原样转发但会在前面加上“服务器时间”和发送者的用户名这样别的客户端看起来是“张三: 今天天气不错”。这个协议能应付最基本的需求。如果后续扩展可以加一个消息类型字段例如0表示聊天、1表示上线通知、2表示下线通知。协议是灵活可变的关键是双方保持一致。3. 环境准备与VSCode配置3.1 在Windows上用VSCode配置C/C开发环境很多新手卡在“基于UDP协议的群聊服务器开发”第一步不是网络通信本身而是环境搭不起来。拿VSCode来说虽然它是个编辑器但配合MinGW编译器完全可以承担C/C的编译调试工作只是默认配置不会自动帮你建工程需要手动配置构建任务。首先安装MinGW-w64 GCC编译器。网上搜到的版本比较多我建议直接选带Win64字样的 x86_64-posix-seh 版本因为posix线程模型对std::thread支持更友好。安装的时候勾选“Add to PATH”这样后面就不用手动改环境变量了。装完验证一下。打开VSCode终端输入gcc --version g --version如果提示“gcc不是内部或外部命令”不要慌十有八九是PATH没配置好。去系统环境变量“Path”里添加MinGW的bin目录例如C:\mingw64\bin然后重新打开VSCode再试。这里有一个很坑的点VSCode是开机启动的旧进程时即使你改了环境变量它也不会自动刷新必须完全退出再打开。然后安装VSCode的C/C扩展搜索“C/C Extension Pack”微软官方出品它会带上IntelliSense、调试和代码格式化工具。这里顺带说一下“创建C/C索引文件”的问题装了扩展后VSCode会为整个工作区建立缓存索引方便跳转和智能提示。如果打开项目后速度很慢或者一直转圈可以在c_cpp_properties.json里手动指定编译器路径和include目录这样索引至少快一倍。3.2 配置编译任务与调试环境VSCode不会自动编译C/C你需要创建 tasks.json 来定义构建命令。在项目根目录建一个.vscode文件夹里面放tasks.json{ version: 2.0.0, tasks: [ { label: build, type: shell, command: g, args: [ -g, -stdc11, -o, server.exe, server.cpp, -lws2_32 ], group: { kind: build, isDefault: true }, problemMatcher: [$gcc] } ] }这里重点强调-lws2_32。Windows的Socket API不在C标准库里单独放在 ws2_32.dll 中所以编译时必须显式链接ws2_32库。很多人第一次写完代码编译报一堆“unresolved external symbol”错误其实就是少了这个链接参数。Linux下不需要这个参数但Windows下必须写跨平台代码可以用条件判断切分。调试配置放在 launch.json 里。如果只需要命令行调试可以不加但想看到断点处的变量就配置一下{ version: 0.2.0, configurations: [ { name: Debug Server, type: cppdbg, request: launch, program: ${workspaceFolder}/server.exe, args: [], stopAtEntry: false, cwd: ${workspaceFolder}, environment: [], externalConsole: true, MIMode: gdb, miDebuggerPath: C:/mingw64/bin/gdb.exe, setupCommands: [ { description: Enable pretty printing, text: -enable-pretty-printing, ignoreFailures: true } ], preLaunchTask: build } ] }调试器的路径填你本机实际安装路径不要照抄。虽然在IDE里调试文件很方便但我仍然推荐你至少要会命令行编译因为很多线上问题和面试题都是围绕g命令行参数展开的。3.3 一个容易踩的坑旧编译器版本与中文乱码MinGW的GCC版本最好选8以上老版本对C11标准支持不完整std::thread可能编译不过。我在项目里要同时支持Windows代码开头就要包含winsock2.h顺序还有个讲究必须放在 windows.h 之前否则会产生宏冲突。乱码问题也很磨人。Windows控制台默认代码页是GBK如果VSCode里用的UTF-8编码保存源码运行后输出中文就全是乱码。最简单的处理思路是在程序开头调用SetConsoleOutputCP(CP_UTF8)把控制台输出代码页切换成UTF-8。另一个思路是干脆把源码保存为GBK编码但这样会在Linux上编译时产生告警。我最终采用跨平台兼容写法关键代码是#ifdef _WIN32 #include winsock2.h #include ws2tcpip.h #pragma comment(lib, ws2_32.lib) #else #include sys/socket.h #include netinet/in.h #include arpa/inet.h #include unistd.h #endif注意 Windows 下需要用WSAStartup初始化Winsock库Linux不用。我在 main 函数开头这样做#ifdef _WIN32 WSADATA wsaData; if (WSAStartup(MAKEWORD(2, 2), wsaData) ! 0) { printf(WSAStartup failed\n); return 1; } #endif4. 核心代码实现详解4.1 服务器端创建套接字与绑定端口创建UDP套接字的参数很好记socket(AF_INET, SOCK_DGRAM, 0)。SOCK_DGRAM就是数据报套接字对应UDPSOCK_STREAM才是TCP。第三个参数协议用0让系统根据前两个参数自动选择。int serverSock socket(AF_INET, SOCK_DGRAM, 0); if (serverSock 0) { perror(socket creation failed); return -1; }然后设置端口复用。这一步很多人会漏但它影响的是开发体验如果不设置SO_REUSEADDR你停掉服务器进程后端口不会立刻释放短时间内重新启动就会报“Address already in use”。每次改代码都要等60秒才能重跑非常折磨。int reuse 1; setsockopt(serverSock, SOL_SOCKET, SO_REUSEADDR, (const char*)reuse, sizeof(reuse));绑定端口用 bind。地址我一般绑定到INADDR_ANY代表监听本机所有网卡的流量这样局域网内的其他机器也能连进来做测试。如果写成127.0.0.1那就只能本机自己跟自己聊天了。sockaddr_in serverAddr{}; serverAddr.sin_family AF_INET; serverAddr.sin_port htons(8888); // 8888端口 serverAddr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(serverSock, (sockaddr*)serverAddr, sizeof(serverAddr)) 0) { perror(bind failed); return -1; }htons和htonl是字节序转换函数。网络字节序是大端而x86机器是小端所以端口号8888在内存里的存储必须转换以后才能塞进结构体。忘了这一步的结果是你绑定的端口和实际监听的端口不是同一个客户端连不上或者连到一个完全不同的端口上。4.2 服务器端主循环接收与广播主循环是整个服务器的灵魂。recvfrom 是阻塞的没有消息时会一直挂起等待进程不会退出也不会空转char recvBuf[8192] {0}; sockaddr_in clientAddr{}; int addrLen sizeof(clientAddr); while (true) { int recvLen recvfrom(serverSock, recvBuf, sizeof(recvBuf) - 1, 0, (sockaddr*)clientAddr, addrLen); if (recvLen 0) { perror(recvfrom error); continue; } recvBuf[recvLen] \0; // 获取发送者的IP和端口字符串 char clientIP[INET_ADDRSTRLEN] {0}; inet_ntop(AF_INET, clientAddr.sin_addr, clientIP, sizeof(clientIP)); int clientPort ntohs(clientAddr.sin_port); printf([%s:%d] %s\n, clientIP, clientPort, recvBuf); // ...在这里把消息广播给其他客户端 }注意recvBuf大小减去1是为了给字符串结尾的\0留位置避免越界。UDP的 recvfrom 如果缓冲区太小多余的字节会被系统丢弃所以缓冲区尽量给大一点。8192对于聊天消息来说已经非常宽裕。广播逻辑我这样处理用一个std::vectorsockaddr_in clients保存所有在线客户端。每次收到消息后先检查这个地址是否已经存在不存在就加入并打印上线信息。然后遍历所有客户端跳过发送者自己把消息发给其他所有人。这里有个小决策要不要把消息回显给发送者本人聊天室通常不回显因为你本地输入框已经有这行字了再回显一遍反而重复。但如果做成“扣扣群公告”那种所有人可见的模式回显也可以。我自己倾向于不回显减少流量也降低屏幕刷屏。发送的关键代码std::string sendMsg [ getTimeString() ] std::string(recvBuf); for (const auto dest : clients) { // 跳过发送者自己 if (memcmp(dest, clientAddr, sizeof(sockaddr_in)) 0) { continue; } sendto(serverSock, sendMsg.c_str(), sendMsg.size(), 0, (sockaddr*)dest, sizeof(dest)); }4.3 客户端发送线程与接收线程客户端长这样int clientSock socket(AF_INET, SOCK_DGRAM, 0); sockaddr_in serverAddr{}; serverAddr.sin_family AF_INET; serverAddr.sin_port htons(8888); inet_pton(AF_INET, 127.0.0.1, serverAddr.sin_addr);然后开两个线程。发送线程走标准输入注意 getline 之后把\n去掉再 sendto。接收线程直接阻塞等待广播void recvThreadFunc() { char buf[8192]; sockaddr_in fromAddr; int len sizeof(fromAddr); while (true) { int n recvfrom(clientSock, buf, sizeof(buf) - 1, 0, (sockaddr*)fromAddr, len); if (n 0) { buf[n] \0; printf(\r%s\n , buf); // \r 回到行首避免干扰输入 fflush(stdout); } } }接收线程里打印消息的时候我加了一个\r和前缀这个小细节可以让终端上输入框和收到的消息看起来不串行。实际体验过你就会发现不做这个处理输入“你好”还没按回车时如果突然收到一条消息屏幕上的文字会是在同一行搅在一起的。客户端的退出逻辑我做得比较朴素收到用户输入quit就 break 出循环然后直接 exit(0)。严格来说应该先通知服务器“我要下线”让服务器把这条地址从在线列表移除但在练习版本里服务器可以通过超时机制自动清理。4.4 关键参数选择为什么是这些值很多新手照着教程抄代码但不理解为什么调数字我在这里统一说清楚缓冲区大小8192文本聊天一条消息很少超过几百字符8192完全够用。如果你的消息可能包含图片base64或长日志就要加大到65536。注意UDP单包上限是65507字节64KB减掉IP头和UDP头的208字节超过会直接报错。端口88881024以下端口通常需要root权限我们选8888属于高端口避开常见默认服务。UDP载荷建议控制在1400字节以内网络链路MTU默认1500扣掉IP和UDP头超过1472字节就会触发IP分片。分片包在公网环境丢一个就全废了。局域网练习无所谓但养成控制包大小的习惯很重要。INADDR_ANY与127.0.0.1前者“本机所有网卡”后者“本机回环”。做真机联机测试必须用前者因为手机或另一台电脑需要从局域网网卡进入服务器。这部分知识你研究得越细后面排查问题的定位速度越快。我遇到过不少同行代码写完了但只要换一个网络环境就出问题几乎全是IP绑定、防火墙、MTU这类基础功课没做好。5. 常见问题与排查技巧实录5.1 客户端收不到服务器的消息先查这三类问题这个问题出现的频率极高。我的排查顺序是防火墙。Windows防火墙默认会拦截程序监听端口。第一次运行服务器时弹窗提示是否允许如果点了取消后面就收不到任何外部客户端消息。去“控制面板-防火墙-允许应用”把server.exe加入例外。地址绑定。服务器如果忘记了设INADDR_ANY或者不小心填成127.0.0.1局域网里其他机器当然连不上。用netstat -an | findstr 8888查看监听地址是0.0.0.0还是127.0.0.1。port和地址的字节序。我曾经因为忘写htons导致服务器绑定到一个完全错误的随机端口上netstat 根本看不到8888。所以每次排查先检查 htons/htonl 是否用对。还要注意UDP客户端是用“服务器IP:端口”作为目标地址不是广播地址。多个人一起测试时同一台机器上的多个客户端要用不同的本地端口——正常情况下系统自动分配不会冲突但如果你显式 bind 了相同端口第二个进程必然失败。5.2 UDP不是没有“粘包”而是有“丢包”和“顺序乱”TCP的粘包问题很多人听过UDP因为保留消息边界一条 recvfrom 恰好对应一个 sendto 的数据报所以不存在TCP意义上的粘包。但UDP有两个让人头大的特性丢包和乱序。丢包在局域网测试中不常见但在Wi-Fi环境或者高负载路由器下非常明显。最常见的表现是客户端A发了两条消息B只收到一条。如何验证是真丢包还是代码逻辑问题写一个带序号的测试程序发1000条消息统计收到的序号的连续性一目了然。乱序通常在客户端使用多线程并发发送时出现单线程顺序发送很少乱序。如果真的对顺序有要求客户端可以在协议里加一个自增序号服务器端做一个滑动窗口缓冲按序号重排后再交给上层显示。这种机制在真实IM里很常见但这个练手项目我建议不做先感受UDP的不确定性再说。5.3 服务端退出了客户端还不知道TCP有连接断开通知UDP什么通知都没有。客户端登出后服务器下次发送消息时没有任何系统报错它只会默默丢掉这个包。时间久了服务器在线列表里堆积大量僵尸地址每个广播消息都白白发往不存在的客户端。解决办法就是心跳机制。核心逻辑很简单客户端每5秒主动向服务器发送一个心跳包比如内容为__heartbeat__。服务器为每个客户端记录lastSeenTime。服务器主循环每次收到消息后更新对应地址的最后活跃时间。每隔10秒遍历一次在线用户表把超过30秒没有活跃的地址移除并打印“xxx掉线”。在Windows下检查时间可以用GetTickCount64()毫秒Linux用time(NULL)秒。这个机制给服务器加上了“自我清洁”能力是工程化项目中必不可少的一部分。5.4 多线程下的输出混乱与资源回收客户端开了收发两个线程后终端输出会打架。比如发送线程正等待用户打字接收线程突然打印一条广播消息两段内容会交错。我在前面代码里用了\r把光标移回行首但这只是体验优化严格来说应该给控制台输出加一把锁std::mutex printMutex; void safePrint(const std::string text) { std::lock_guardstd::mutex lock(printMutex); printf(%s, text.c_str()); fflush(stdout); }服务器退出时还要注意资源回收关闭socket、调用WSACleanup()Windows下。虽然操作系统在进程退出时会自动释放socket句柄但养成清理习惯很重要尤其在写长驻服务的时候。我还见过有人不关socket导致程序“假死”实际是socket句柄耗尽这种情况Windows下特别容易出现。5.5 编译运行时出现的奇葩报错很多人会在VSCode里看到这么一条错误error: command c:\users\86181\appdata\local\programs\common\microsoft\visual c for python\9.0\vc\bin\amd64\cl.exe failed with exit status 2这个报错十有八九不是你的C项目问题而是某个Python包在尝试调用Visual C编译器。它和你用g编译UDP服务器没有关系。解决方法是在VSCode的构建任务里明确指定编译器为g或者干脆别在VSCode终端里跑Python的pip install命令。另外有个提醒VSCode里不小心切换到了“cl.exe”模式会导致IntelliSense完全不认识winsock2.h里的函数因为微软编译器头文件路径和MinGW不同。遇到“找不到ws2tcpip.h”的问题就去检查c_cpp_properties.json里的compilerPath是否指向了g.exe以及includePath是否包含MinGW的头文件目录{ configurations: [ { name: Win64, includePath: [${workspaceFolder}/**], compilerPath: C:/mingw64/bin/g.exe, cStandard: c11, cppStandard: cpp14, intelliSenseMode: windows-gcc-x64 } ] }实测下来配置这一步折腾明白了后面写Socket代码会顺很多。6. 项目扩展方向与我的实操体会6.1 从“能跑”到“好用”可以怎么扩展基础版跑通之后你有几个往上加功能的路径难度从低到高排列给消息加JSON格式。例如{user:zhangsan,content:hello,ts:1700000000}客户端收到后用简单的字符串解析或者第三方库解析方便后续扩展字段。增加聊天室频道。服务器的在线用户表变成房间ID - 用户列表的多层结构客户端发送时在协议里带上房间ID。增加私聊支持。协议里加target字段服务器根据目标用户名直接发送不做全局广播。加一个简单GUI。Windows下用Qt或者Win32原生窗口把终端里的输入框和消息列表搬进窗口。做消息持久化。把聊天记录写到文件中或者用SQLite存储方便回溯和统计。扩展的本质还是围绕“协议”做文章。协议字段设计得越合理扩展越容易。所以我建议在写第一版的时候就往消息格式里预留一个消息类型字段哪怕暂时不用未来也不用改所有代码。6.2 我在开发这个项目的过程中踩过的坑印象最深的一个坑是我在Windows上写完代码拿到Linux上一编译扑面而来一堆报错。问题主要集中在头文件和socket API的差异上。Windows用closesocket关闭socketLinux用closeWindows的Sleep(ms)Linux的usleep(us)Windows需要WSAStartupLinux不需要。这些差异不处理跨平台就是一场灾难。我最终用#ifdef _WIN32把差异全部隔离在同一个文件里主程序里不出现任何一个平台相关的函数这样的代码才真正具备了跨平台能力。另一个让我印象深刻的点是调试方式。纯文本聊天不好验证“广播”是否正确我写了个小脚本模拟两个虚拟客户端同时发消息各发50条。脚本跑完再去看服务器日志是否两条流都接受到了、是否互相交织正常。没有自动化测试的前提下这种“双客户端脚本验证法”非常可靠推荐给每一个刚开始写网络程序的人。6.3 最后分享一个小技巧如果想让服务器端更贴近真实场景就在主循环里加入一个 “当前在线人数” 的统计输出printf(当前在线: %zu 人\n, clients.size());别小看这一行它让你对“UDP无连接特性带来的地址表变化”有非常直观的掌控感。当客户端掉线、心跳超时、列表自动清理时能从终端上立刻观察到人数变化比任何日志都直观。我自己做这个项目时每次看到人数从1跳到2、再跳回1才会真正理解“地址不是连接连接需要维护”这句话到底在说什么。UDP群聊服务器是一个经典项目它没有TCP那一堆复杂的状态机要处理却把协议设计、多线程、网络字节序、超时管理这些核心能力全部覆盖了。做完一遍你对C/C网络编程的理解会有一个质的提升。