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