簡介面向具備一定 C 基礎(chǔ)、希望掌握 Qt 網(wǎng)絡(luò)編程的開發(fā)者這套 QTUDP 通信示例圍繞 UDP 無連接、低開銷、低延遲的特點演示客戶端與服務(wù)端之間的數(shù)據(jù)報收發(fā)可用于音視頻流、實時控制等場景的入門驗證。壓縮包共 12 個文件約 10KB含 4 個 cpp、2 個 h 源代碼及 2 個 ui 界面文件另有 2 個 pro 工程配置和 2 個 user 用戶配置便于導(dǎo)入 Qt Creator 對照運(yùn)行。資源已有 823 人學(xué)習(xí)讀者可借此理解 QUdpSocket 的端口綁定、數(shù)據(jù)報發(fā)送與接收、readyRead 信號處理及基礎(chǔ)錯誤檢查并梳理輕量 UDP Demo 的工程組織方式為后續(xù)擴(kuò)展多線程收發(fā)、編解碼與穩(wěn)定性處理打基礎(chǔ)。1. 局域網(wǎng)里那點事用 QUdpSocket 其實很短剛上手 Qt 網(wǎng)絡(luò)模塊的人往往是在一個局域網(wǎng)小工具里第一次碰到 QUdpSocket上位機(jī)要同時給十幾臺下位機(jī)推配置用 TCP 得為每臺維護(hù)一條連接、處理斷線重連換成 UDP 之后一次 writeDatagram 就把包扔出去了。這份 QTUDP通信Demo 就是這類需求的骨架它沒把協(xié)議做全而是把 Qt 下 UDP 通信的完整路徑攤開套接字初始化、端口綁定、數(shù)據(jù)報收發(fā)、廣播與組播以及在 readyRead 信號里把裸字節(jié)還原成業(yè)務(wù)消息。適合三類人剛上手 Qt 想找個能直接編譯運(yùn)行的起點、做過 TCP 被粘包和多連接折騰過、需要在局域網(wǎng)做設(shè)備發(fā)現(xiàn)和狀態(tài)上報。它真正回答的不是“怎么寫一個 UDP 程序”而是“UDP 這一層在你的工程里該長什么樣”。2. 工程結(jié)構(gòu)與技術(shù)選型三層拆分讓網(wǎng)絡(luò)代碼能離開界面活著一個能直接編譯的 Demo最容易寫壞的恰恰是結(jié)構(gòu)。所有邏輯塞進(jìn) MainWindow 的槽函數(shù)里二十行能跑通等到要加心跳、加廣播、加文件分片界面類會膨脹到八百行想抽出來復(fù)用的時候發(fā)現(xiàn)到處是 ui- 指針。這個 Demo 的價值一半在收發(fā)本身另一半在它把“界面”“網(wǎng)絡(luò)”“協(xié)議”這三件事拆開了。2.1 目錄拆分界面、協(xié)議、網(wǎng)絡(luò)各管一攤我一般會把這類項目擺成下面這個樣子src 下按職責(zé)分目錄而不是按文件類型分目錄QTUdpDemo/ ├── QTUdpDemo.pro qmake 工程文件 ├── CMakeLists.txt CMake 構(gòu)建Qt6 優(yōu)先 ├── src/ │ ├── main.cpp │ ├── ui/ │ │ ├── mainwindow.h │ │ ├── mainwindow.cpp 只負(fù)責(zé)輸入框、按鈕、日志展示 │ │ └── mainwindow.ui │ ├── net/ │ │ ├── udpreceiver.h 綁定端口、收包、拋信號 │ │ ├── udpreceiver.cpp │ │ ├── udpsender.h 組包、發(fā)送、解析目標(biāo)地址 │ │ └── udpsender.cpp │ ├── proto/ │ │ ├── packet.h 協(xié)議頭結(jié)構(gòu)體與常量 │ │ └── packet.cpp 打包 / 解包 / 校驗 │ └── model/ │ └── peerlist.h 在線對端列表IP、端口、最后活躍時間 └── res/ └── icons.qrcnet 層只認(rèn) QByteArray 和 QHostAddress不 include 任何界面頭文件proto 層只做字節(jié)層面的打包解包純函數(shù)可以單獨(dú)寫單元測試ui 層拿到的是已經(jīng)解析好的消息對象。這條邊界守住之后后面換成命令行程序、換成無界面服務(wù)net 和 proto 一行都不用改。這是我在自己項目里踩出來的規(guī)矩網(wǎng)絡(luò)層只要開始 emit 帶 QString 的“已經(jīng)格式化好的日志”基本就廢了它會被界面需求牽著走。具體到類的職責(zé)UdpReceiver 持有 QUdpSocket、負(fù)責(zé) bind 和 readyRead 槽UdpSender 持有另一個 QUdpSocket負(fù)責(zé) writeDatagram 和發(fā)送失敗的 errorString 上報Packet 提供 encode/decode 兩個靜態(tài)方法返回一個可選的業(yè)務(wù)消息結(jié)構(gòu)。PeerList 用 QHashQString, PeerInfo 存活躍對端key 用 “ip:port”定時器掃過期。這幾個類加起來不到五百行但每一塊都能單獨(dú)拎走。2.2 QUdpSocket 的能力邊界以及 Qt5 與 Qt6 的差異選 QUdpSocket 而不是裸 socket理由很實際它把 Qt 的事件循環(huán)接上了readyRead 信號天然和界面線程同頻不需要自己寫 select 循環(huán)也不需要處理 EINTR。跨平臺方面 Windows 的 Winsock 初始化和 Linux 的 socket 選項差異都被抹平了。代價是它只暴露 UDP 的傳輸層能力不幫你做任何可靠性保證這一點必須提前想清楚。維度QUdpSocketQTcpSocket連接模型無連接每次帶目標(biāo)地址先 connect之后只寫數(shù)據(jù)消息邊界一條數(shù)據(jù)報就是一條消息流式需要自己切包送達(dá)保證不保證到達(dá)、不保證順序保證有序到達(dá)單包上限約 65507 字節(jié)受 MTU 影響更小無上限典型場景設(shè)備發(fā)現(xiàn)、狀態(tài)上報、音視頻幀文件傳輸、命令通道Qt5 和 Qt6 在這塊 API 上的差異不大但有三個點要注意。第一QNetworkDatagram 是 Qt 5.8 才有的如果工程要兼容更老的版本接收側(cè)只能退回 readDatagram(char*, qint64, QHostAddress*, quint16*)。第二錯誤信號在 Qt 5.15 之前叫 error(QAbstractSocket::SocketError)5.15 起改名為 errorOccurredQt6 里只有后者寫 connect 的時候要么按版本做條件編譯要么直接用舊名字去連。第三Qt6 的 CMake 側(cè)需要用 qt_add_executable 和 qt_standard_project_setupqmake 的 .pro 則幾乎原樣能編。提示如果從 Qt5 工程遷到 Qt6先看 QTextCodec 相關(guān)的代碼Qt6 把它挪到了 core5compat 模塊而 UDP 本身的收發(fā)邏輯一般不需要改。2.3 兩份構(gòu)建配置.pro 與 CMakeListsqmake 那份是給習(xí)慣 Qt Creator 直接打開的人準(zhǔn)備的四行就夠QT core gui widgets network CONFIG c17 TARGET QTUdpDemo TEMPLATE app SOURCES src/main.cpp src/ui/mainwindow.cpp src/net/udpreceiver.cpp \ src/net/udpsender.cpp src/proto/packet.cpp HEADERS src/ui/mainwindow.h src/net/udpreceiver.h \ src/net/udpsender.h src/proto/packet.h FORMS src/ui/mainwindow.ui關(guān)鍵就在 QT network 這一行沒有它鏈接階段會報 QUdpSocket 未定義。CMake 那份對應(yīng) Qt6cmake_minimum_required(VERSION 3.16) project(QTUdpDemo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_AUTOMOC ON) # 有 Q_OBJECT 的類必須開 find_package(Qt6 REQUIRED COMPONENTS Core Gui Widgets Network) qt_standard_project_setup() qt_add_executable(QTUdpDemo src/main.cpp src/ui/mainwindow.cpp src/net/udpreceiver.cpp src/net/udpsender.cpp src/proto/packet.cpp ) target_link_libraries(QTUdpDemo PRIVATE Qt6::Core Qt6::Gui Qt6::Widgets Qt6::Network)參數(shù)上要留意 find_package 里的 Network 組件少寫一個就是編譯期找不到 QUdpSocket 頭文件。CMAKE_AUTOMOC 必須為 ON否則自定義類里繼承 QObject 的 Q_OBJECT 宏不會被處理鏈接時報 vtable 未定義這個錯誤提示對新手極不友好是典型的入門翻車點。Qt5 用戶把 Qt6:: 換成 Qt5::、find_package 里寫 Qt5 即可qt_add_executable 換成普通的 add_executable。3. 核心鏈路拆解從 bind 到 readyRead 的一次完整收發(fā)結(jié)構(gòu)擺好之后真正要讀透的是那一兩百行網(wǎng)絡(luò)代碼。UDP 的收發(fā)在 Qt 里被壓縮成了四五個函數(shù)但每個函數(shù)的參數(shù)都藏著坑尤其 bind 和 receiveDatagram 的參數(shù)含義寫法上差一點行為就差很遠(yuǎn)。3.1 構(gòu)造與綁定地址、端口和 BindMode 三件事接收端必須綁固定端口否則對端不知道往哪發(fā)。構(gòu)造函數(shù)里就該把 bind 和信號連接做完避免對象構(gòu)造成功但實際不可用的半殘狀態(tài)// src/net/udpreceiver.cpp UdpReceiver::UdpReceiver(quint16 port, QObject *parent) : QObject(parent) , m_socket(new QUdpSocket(this)) { // AnyIPv4 表示監(jiān)聽本機(jī)所有 IPv4 網(wǎng)卡用 Any 會同時嘗試 IPv6 const bool ok m_socket-bind(QHostAddress::AnyIPv4, port, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint); if (!ok) { qWarning() bind port failed: m_socket-errorString(); return; // 后續(xù) readyRead 不會觸發(fā)調(diào)用方需檢查 isListening() } connect(m_socket, QUdpSocket::readyRead, this, UdpReceiver::onReadyRead); } bool UdpReceiver::isListening() const { return m_socket-state() QAbstractSocket::BoundState; }參數(shù)逐個說。第一個參數(shù)是監(jiān)聽地址寫 QHostAddress::AnyIPv4 會綁到 0.0.0.0廣播和組播都能收寫成某個具體網(wǎng)卡地址就只有那塊網(wǎng)卡收得到本機(jī) 127.0.0.1 發(fā)來的包會被丟掉——這是“本機(jī)能發(fā)不能收”最常見的原因。第二個參數(shù)是端口0 表示讓系統(tǒng)分配但接收端絕不能用 0。第三個參數(shù)是 BindMode默認(rèn)值 DefaultForPlatform 在 Linux 上對應(yīng)獨(dú)占兩個進(jìn)程先后綁同一端口時第二個直接失敗加上 ShareAddress | ReuseAddressHint 之后同一臺機(jī)器上跑兩個實例調(diào)試才不會互相打架。工程上允許重復(fù)綁定是為了調(diào)試方便正式部署時一個端口只應(yīng)該有一個接收者。3.2 發(fā)送路徑writeDatagram 的返回值能告訴你什么發(fā)送端不一定要 bind因為 sendto 時內(nèi)核會自動分配源端口。但如果對端會回包就必須 bind 一個固定端口否則回包打到隨機(jī)端口上沒人收。發(fā)送邏輯本身很短難的是目標(biāo)地址的解析// src/net/udpsender.cpp qint64 UdpSender::sendText(const QString text, const QHostAddress to, quint16 port) { QByteArray packet Packet::encode(Packet::TypeText, text.toUtf8()); const qint64 written m_socket-writeDatagram(packet, to, port); if (written ! packet.size()) { // UDP 下要么整包寫入要么 -1出現(xiàn)部分寫入說明包超長 qWarning() send failed, want packet.size() got written m_socket-errorString(); } return written; } bool UdpSender::sendTextToHost(const QString text, const QString host, quint16 port) { QHostAddress addr; if (!addr.setAddress(host)) { // 先按 IP 字面量解析 // 域名解析是阻塞的示例里放主線程真實項目應(yīng)換成 lookupHost 異步版 const QHostInfo info QHostInfo::fromName(host); if (info.error() ! QHostInfo::NoError || info.addresses().isEmpty()) { return false; } addr info.addresses().first(); } return sendText(text, addr, port) 0; }writeDatagram 的返回值是實際寫入的字節(jié)數(shù)UDP 語義下它只有兩種結(jié)果等于數(shù)據(jù)報長度或者 -1。如果出現(xiàn)“小于包長”的返回值通常意味著數(shù)據(jù)報超過了協(xié)議棧允許的上限IPv4 下大約 65507 字節(jié)或者是緩沖區(qū)瞬間被打滿。返回值不是 -1 就以為發(fā)成功了是個常見的錯覺——UDP 發(fā)送成功只代表數(shù)據(jù)交給了內(nèi)核不代表對方收得到這一點在后面心跳和重傳設(shè)計里會再提。3.3 接收路徑readyRead 只說明“至少有一個包”readyRead 的語義是“有數(shù)據(jù)可讀”不是“你的消息到了”所以槽函數(shù)里一定要用 while 循環(huán)把緩沖區(qū)讀空否則剩下的包要等下一次數(shù)據(jù)到達(dá)才觸發(fā)信號// src/net/udpreceiver.cpp void UdpReceiver::onReadyRead() { while (m_socket-hasPendingDatagrams()) { const qint64 size m_socket-pendingDatagramSize(); if (size 0) { break; } QNetworkDatagram dg m_socket-receiveDatagram(static_castint(size)); if (!dg.isValid()) { continue; } const Packet::Message msg Packet::decode(dg.data()); if (!msg.valid) { qWarning() drop malformed packet from dg.senderAddress().toString(); continue; // 臟包直接丟棄不要讓異常數(shù)據(jù)進(jìn)業(yè)務(wù)層 } emit messageReceived(dg.senderAddress().toString(), dg.senderPort(), msg); } }三個函數(shù)的關(guān)系要理清hasPendingDatagrams 判斷隊列里還有沒有pendingDatagramSize 返回隊首那個包的長度receiveDatagram 按給定長度取出并返回一個 QNetworkDatagram里面同時帶 senderAddress、senderPort 和 data。傳參時把 pendingDatagramSize 的結(jié)果原樣傳進(jìn)去不要圖省事傳一個大值否則可能把后面的包截斷。emit 出去的是已經(jīng)解包并校驗過的結(jié)構(gòu)體界面層只負(fù)責(zé)展示不做字節(jié)操作。3.4 應(yīng)用層協(xié)議給每個數(shù)據(jù)報加個頭UDP 保留了消息邊界所以不需要像 TCP 那樣處理粘包。但實際項目里仍有兩種情況需要自己定協(xié)議一是同一個端口上要區(qū)分文本、心跳、文件塊等多種消息二是單條業(yè)務(wù)消息可能超過 MTU。這個 Demo 里我用一個固定八字節(jié)的頭來解耦字段類型字節(jié)數(shù)說明magicquint162固定 0x5154快速識別是不是本程序的包versionquint81協(xié)議版本方便后續(xù)兼容typequint811 文本 2 心跳 3 文件塊seqquint324遞增序號僅用于日志和丟失統(tǒng)計payloadSizequint324負(fù)載字節(jié)數(shù)用于校驗// src/proto/packet.cpp QByteArray Packet::encode(quint8 type, const QByteArray payload) { QByteArray out; QDataStream s(out, QIODevice::WriteOnly); s.setByteOrder(QDataStream::BigEndian); // 網(wǎng)絡(luò)字節(jié)序跨平臺必須顯式指定 s.setVersion(QDataStream::Qt_5_15); // 兩端版本要一致否則 QString 序列化格式不同 s quint16(0x5154) quint8(1) type quint32(m_seq) quint32(payload.size()); out.append(payload); return out; }參數(shù)上有兩個必須顯式設(shè)定的東西字節(jié)序和 QDataStream 版本號。默認(rèn)字節(jié)序在小端機(jī)器上是 LittleEndian接收方如果是大端設(shè)備就全亂QDataStream 的版本決定了 QString 等類型的序列化格式兩端不一致時讀出來的長度字段都是錯的。負(fù)載部分直接用 append 塞原始字節(jié)不經(jīng)過 QDataStream避免二次編碼帶來的額外開銷。單包建議控制在 1400 字節(jié)以內(nèi)這個數(shù)和以太網(wǎng) MTU 1500 減去 IP 頭 20 字節(jié)、UDP 頭 8 字節(jié)后的余量有關(guān)超過就要自己分片加序號重組那是另一個話題了。4. 廣播、組播與對端發(fā)現(xiàn)一份代碼覆蓋三種投遞方式單播只能發(fā)給一個已知地址但設(shè)備發(fā)現(xiàn)這類需求是一對多的Demo 里把廣播和組播都放進(jìn)來正是因為它倆是局域網(wǎng)場景下最省事的發(fā)現(xiàn)手段。4.1 廣播setBroadcast 與子網(wǎng)邊界廣播的寫法幾乎是單播加一行開關(guān)// 發(fā)送端允許廣播 m_socket-setBroadcast(true); QByteArray probe Packet::encode(Packet::TypeHeartbeat, QByteArray()); // QHostAddress::Broadcast 等價于 255.255.255.255 m_socket-writeDatagram(probe, QHostAddress::Broadcast, 45454);這里有兩個容易翻車的點。其一不調(diào)用 setBroadcast(true) 直接往廣播地址發(fā)writeDatagram 會返回 -1錯誤信息是“Permission denied”之類的措辭看著像權(quán)限問題實際是套接字沒開廣播選項。其二255.255.255.255 只在本地子網(wǎng)內(nèi)有效路由器不會轉(zhuǎn)發(fā)跨網(wǎng)段必須用子網(wǎng)定向廣播地址比如 192.168.1.255而且要提前算好掩碼。接收側(cè)就更簡單了只要 bind 的是 AnyIPv4 的對應(yīng)端口廣播包會正常觸發(fā) readyReadsenderAddress 拿到的是發(fā)送方的實際 IP。真要用廣播做設(shè)備發(fā)現(xiàn)節(jié)奏上建議“上電連發(fā)三次、間隔 300 毫秒”而不是一直刷。廣播包會被同一網(wǎng)段所有機(jī)器收到頻率高了純屬干擾別人。發(fā)現(xiàn)到對端之后立刻轉(zhuǎn)成單播繼續(xù)通信廣播只用在“我還不知道你是誰”的階段。4.2 組播joinMulticastGroup 與網(wǎng)卡選擇組播比廣播克制只有加入了同一個組地址的進(jìn)程才收得到。組地址范圍是 224.0.0.0 到 239.255.255.255其中 224.0.0.x 段被協(xié)議保留實際項目里習(xí)慣用 239.x.x.x// 接收端綁定任意地址后加入組播組 QUdpSocket *mc new QUdpSocket(this); mc-bind(QHostAddress::AnyIPv4, 45455, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint); bool joined mc-joinMulticastGroup(QHostAddress(239.255.43.21)); if (!joined) { qWarning() join multicast failed: mc-errorString(); } // 發(fā)送端組播包的 TTL 一般設(shè)小一點避免被路由器轉(zhuǎn)出本網(wǎng)段 QUdpSocket *ms new QUdpSocket(this); ms-setSocketOption(QAbstractSocket::MulticastTtlOption, 1); ms-writeDatagram(payload, QHostAddress(239.255.43.21), 45455);綁定地址寫 AnyIPv4 是必須的寫具體網(wǎng)卡地址在某些平臺上會讓 joinMulticastGroup 失敗。多網(wǎng)卡機(jī)器上筆記本同時開著有線和無線很常見joinMulticastGroup 的第二個參數(shù)可以指定 QNetworkInterface否則包可能從錯誤的網(wǎng)卡出去。TTL 設(shè) 1 表示只在本網(wǎng)段傳播這是局域網(wǎng)發(fā)現(xiàn)業(yè)務(wù)里最合理的值。判斷網(wǎng)卡是否選對可以遍歷 QNetworkInterface::allInterfaces() 打印每個接口的 flags看哪個帶 IsUp 和 IsRunning。4.3 心跳與在線列表用 QTimer 維護(hù)對端狀態(tài)UDP 沒有連接狀態(tài)對端什么時候下線你完全不知道所以在線列表只能靠心跳推出來// src/model/peerlist.cpp void PeerList::onHeartbeat(const QString ip, quint16 port) { const QString key QString(%1:%2).arg(ip).arg(port); PeerInfo info m_peers[key]; info.ip ip; info.port port; info.lastSeen QDateTime::currentMSecsSinceEpoch(); info.online true; } void PeerList::sweep() { const qint64 now QDateTime::currentMSecsSinceEpoch(); for (auto it m_peers.begin(); it ! m_peers.end(); ) { if (now - it-lastSeen kTimeoutMs) { // 三個心跳周期沒更新就摘掉 emit peerOffline(it-ip, it-port); it m_peers.erase(it); } else { it; } } }心跳間隔我一般設(shè) 2 秒超時閾值設(shè) 3 個周期即 6 秒容忍偶發(fā)丟包。這里有個細(xì)節(jié)超時不要只靠“最后一次心跳時間”還要考慮本地時鐘被系統(tǒng)校時改掉的情況用單調(diào)時鐘 QElapsedTimer 更穩(wěn)妥示例里用毫秒時間戳是為了好讀。另外心跳包要單獨(dú)一個 type不要和業(yè)務(wù)消息混用否則日志里滿屏都是心跳排查問題時根本看不清。5. 避坑與排查UDP 在真實網(wǎng)絡(luò)里的五條經(jīng)驗Demo 在本機(jī)上跑通不代表能上線局域網(wǎng)環(huán)境里的問題基本集中在端口、地址、編碼和性能這四塊。下面五條是我在類似項目里真真切切碰過的。5.1 現(xiàn)象第二個實例一啟動就收不到包現(xiàn)象同一個程序開兩個窗口做自測第二個窗口的日志一直為空bind 返回 falseerrorString 是“Address already in use”。原因QUdpSocket 的默認(rèn)綁定的綁定模式在多數(shù)平臺上對端口是獨(dú)占的第一個實例沒釋放之前第二個拿不到。解決接收端的 bind 調(diào)用統(tǒng)一加上 QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint兩個實例就能同時監(jiān)聽同一端口數(shù)據(jù)報會被復(fù)制給所有綁定者。需要注意這只適合調(diào)試正式場景里兩個進(jìn)程搶同一端口誰收到包是不確定的。5.2 現(xiàn)象本機(jī)自己發(fā)給自己一條都收不到現(xiàn)象發(fā)送端顯示 writeDatagram 返回了正數(shù)接收端 readyRead 就是不觸發(fā)換到局域網(wǎng)另一臺機(jī)器就正常。原因通常有兩個接收端 bind 的是某塊具體網(wǎng)卡的地址而發(fā)送端發(fā)往 127.0.0.1地址對不上或者目標(biāo)是 255.255.255.255 廣播但接收端綁定到了具體地址廣播包被網(wǎng)卡過濾掉了。解決接收端一律綁 QHostAddress::AnyIPv4讓它監(jiān)聽所有網(wǎng)卡包括回環(huán)自測時優(yōu)先往 127.0.0.1 單播確認(rèn)鏈路通了再試廣播。另外 Windows 上首次運(yùn)行會彈防火墻授權(quán)框點“取消”之后再想收包就得去防火墻規(guī)則里手動放行這個坑很隱蔽。5.3 現(xiàn)象中文消息到對端變成亂碼或者問號現(xiàn)象發(fā)“溫度異常”四個字對方收到的是一串亂碼或者長度對不上解析失敗。原因QString 轉(zhuǎn) char* 時用了隱式轉(zhuǎn)換走的是 Latin-1 編碼中文直接被替換成問號另一種情況是兩端 QDataStream 版本不一致長度字段按不同規(guī)則序列化。解決所有字符串出入都顯式走 toUtf8 / fromUtf8協(xié)議頭里的長度字段按字節(jié)數(shù)算而不是按字符數(shù)算QDataStream 在兩端寫死同一個版本號比如都寫 QDataStream::Qt_5_15。上線前用一段純中文加 emoji 的測試串跑一遍比看十遍代碼管用。5.4 現(xiàn)象高頻發(fā)送時界面卡成幻燈片現(xiàn)象壓測時每秒發(fā)幾百個包界面按鈕點不動日志窗口滾動有延遲。原因有兩個疊加一是每條數(shù)據(jù)報都 emit 一次信號、追加一次日志到 QTextEdit控件重繪成了瓶頸二是 readyRead 里沒把隊列讀空事件循環(huán)反復(fù)被喚醒。解決接收槽里用 while 循環(huán)一次讀光攢到一個 QVector 后再發(fā)一個批量信號界面?zhèn)扔?QTimer 每 100 毫秒合并刷新一次而不是來一條刷一條再不行就把網(wǎng)絡(luò)對象 moveToThread 到獨(dú)立線程用隊列連接把結(jié)果傳回界面。這個改法通常能把 CPU 占用從單核跑滿降到個位數(shù)。5.5 現(xiàn)象大包發(fā)出去了收到的卻是半截現(xiàn)象發(fā)一條幾十 KB 的 JSON接收端解析時報“數(shù)據(jù)不完整”pendingDatagramSize 拿到的長度比預(yù)期小。原因超過了鏈路 MTU 觸發(fā) IP 分片任何一個分片丟失整個數(shù)據(jù)報就作廢更極端的情況下超過 65507 字節(jié)writeDatagram 直接返回 -1。解決協(xié)議層強(qiáng)制單包不超過 1400 字節(jié)超出就按序號切片接收端做重組并設(shè)超時丟棄不完整的組或者干脆把大塊數(shù)據(jù)挪到 TCP 通道上UDP 只承載控制消息。這條屬于設(shè)計階段就要定下來的約束等上線再改代價很大。6. 二次開發(fā)把它抽成一個能復(fù)用的 UdpChannelDemo 里的 Sender 和 Receiver 分成兩個類是便于講解真到項目里我更愿意合成一個 UdpChannel收發(fā)同一個套接字接口窄一點用起來省心。6.1 封裝邊界與接口設(shè)計我的做法是把 bind、發(fā)送、批量接收、對端列表全收進(jìn)去對外只暴露四個東西// src/net/udpchannel.h class UdpChannel : public QObject { Q_OBJECT public: explicit UdpChannel(quint16 localPort, QObject *parent nullptr); bool start(); // bind 連接信號 qint64 sendTo(const QByteArray payload, const QHostAddress to, quint16 port); void enableBroadcast(bool on); signals: void messagesReady(const QVectorPacket::Message batch); // 批量上拋 void errorOccurred(const QString reason); };關(guān)鍵改動有三個。其一接收側(cè)不再逐條 emit攢夠一批或者定時器到點再發(fā)界面?zhèn)扔嗛?messagesReady 就夠了刷新頻率和解包頻率解耦。其二把在線列表也吃進(jìn)來start() 里順帶起心跳定時器和過期清掃定時器調(diào)用方只需要關(guān)心“誰在線”這個信號。其三錯誤統(tǒng)一走 errorOccurred 字符串而不是把 QAbstractSocket 的枚舉拋給上層界面層不該知道 SocketError 是什么。這套接口換到命令行程序或者后臺服務(wù)里照樣能用不依賴任何控件。6.2 驗證方法別急著開界面封裝完先別寫界面用兩個終端驗證鏈路更高效。Linux 或 macOS 上可以用 nc 直接發(fā)一條 UDP 包到本地端口看程序日志有沒有打印對端地址# 終端 1先跑起來你的接收端監(jiān)聽 45454 ./QTUdpDemo --listen 45454 # 終端 2發(fā)一條純文本 UDP 包到本機(jī) printf hello-udp | nc -u -w1 127.0.0.1 45454 # 終端 2 變體發(fā)廣播到當(dāng)前網(wǎng)段需要系統(tǒng)允許 printf probe | nc -u -w1 -b 255.255.255.255 45454看到日志里出現(xiàn) 127.0.0.1 和正確的負(fù)載長度說明 bind 和 readyRead 這條鏈通了再換到另一臺機(jī)器上重試通不過就按第 5 章的順序查網(wǎng)卡地址、防火墻、子網(wǎng)掩碼。之后再測組播用 ip maddr 看網(wǎng)卡有沒有真的加入組這一步能省掉很多“代碼明明沒錯”的爭論。壓測用 for 循環(huán)發(fā)一萬個包統(tǒng)計接收端實際收到的數(shù)量丟包率在局域網(wǎng)內(nèi)應(yīng)該很低如果掉得厲害先看接收端是不是在界面線程里同步處理。這套流程我后來固化成了習(xí)慣每加一個網(wǎng)絡(luò)模塊先寫一個不依賴界面的最小可執(zhí)行用命令行和 nc 打通再把界面接上去。從那以后我每次新建網(wǎng)絡(luò)通信相關(guān)的類都強(qiáng)制先跑一遍自環(huán)和跨機(jī)兩條驗證再動 UI 代碼。希望幫到你。本文還有配套的精品資源點擊獲取