簡介基于Qt框架構建的跨平臺文件網絡傳輸系統(tǒng)面向具備一定C基礎的開發(fā)者和畢業(yè)設計學習者演示Linux服務器與Windows 10客戶端之間基于TCP的可靠文件傳輸。包體共23個文件以C源文件、頭文件、Qt界面文件.ui及工程配置文件.pro為主含少量備份與說明文檔壓縮包僅20KB代碼精簡適合快速通讀。系統(tǒng)覆蓋網絡連接管理、文件分片校驗、多線程分離I/O與界面響應等實現(xiàn)細節(jié)服務端展現(xiàn)事件驅動或線程池并發(fā)模型客戶端支持拖拽上傳與進度實時反饋并預留SQLite持久化方案工程組織方式、平臺適配封裝與備份文件結構也具備參考價值可作為理解套接字編程與Qt跨平臺編譯的實踐范本。當前已有73人學習適合用于課程設計復盤或求職項目積累。1. Qt框架做文件傳輸不是只能寫界面的GUI庫很多人聽到Qt框架的第一反應是“做桌面界面”但如果你把QTcpSocket、QTcpServer和跨平臺編譯這套組合用起來會發(fā)現(xiàn)Qt做網絡傳輸同樣順手。這份資源是一個典型的畢業(yè)設計題目Linux服務器負責接收和落盤Windows 10客戶端負責選擇文件和發(fā)送兩邊跑同一套基于Qt框架的代碼只是編譯目標和運行角色不同。整套系統(tǒng)不依賴第三方庫全用Qt自帶的network模塊斷點續(xù)傳、實時進度、文件校驗這些答辯加分點也都覆蓋到了。適合準備Qt方向畢業(yè)設計、或者想快速搭一套跨平臺文件傳輸原型的開發(fā)者。先說清楚一點它不是什么大而全的網盤系統(tǒng)而是把TCP長連接、分塊發(fā)送、自定義報文協(xié)議這幾個基本功串起來做成一個能跑、能演示、能繼續(xù)擴展的骨架。2. 系統(tǒng)架構與傳輸協(xié)議先定好包頭后面少改十次代碼2.1 整體角色劃分與關鍵模塊這套系統(tǒng)分兩端。服務器端運行在Linux上啟動后監(jiān)聽固定端口維護一個QTcpSocket連接接收客戶端傳過來的文件數據邊收邊寫入磁盤?？蛻舳诉\行在Windows 10上提供一個QWidget界面讓用戶填服務器IP和端口、選擇本地文件、設置保存路徑然后點按鈕開始發(fā)送。網絡這塊全部走Qt的network模塊不引入額外庫。底層是TCP這意味著兩端之間是可靠字節(jié)流丟包重傳由內核完成我們只需要關心“怎么從字節(jié)流里切出完整的業(yè)務數據”。這個切分邏輯就是協(xié)議設計的核心也是整個項目里最容易翻車的地方。模塊劃分上服務器端拆成監(jiān)聽入口和連接處理兩個對象客戶端拆成界面和傳輸邏輯兩部分。傳輸邏輯用QFile讀文件、QTcpSocket收發(fā)數據界面只管進度條和狀態(tài)文本。這樣分離的好處是如果之后要加命令行版本去掉界面部分就行傳輸核心可以復用。2.2 自定義二進制協(xié)議固定包頭加變長負載我見過不少人拿著QDataStream直接整包發(fā)小文件沒問題一到幾百MB就各種對不齊。正確做法是設計一個固定長度的包頭后面跟上變長的文件名和數據區(qū)。// protocol.h #pragma once #include QtGlobal // 命令字定義 enum UploadCmd { CMD_UPLOAD_INIT 100, // 客戶端聲明要傳文件 CMD_DATA_BLOCK 110, // 數據塊 CMD_UPLOAD_FINISH 120, // 數據發(fā)送完畢 CMD_QUERY_OFFSET 130, // 查詢服務器已接收大小 CMD_RESPONSE_OFFSET 200, // 服務器回復偏移量 CMD_ERROR_RESP 300 // 錯誤響應 }; // 每個包的前 32 字節(jié)固定結構 struct PacketHeader { quint32 magic; // 固定魔數 0x5A5A5A5A用來識別有效包 quint32 cmd; // 命令字 quint32 filenameLen; // 文件名字節(jié)長度 qint64 fileSize; // 文件總大小 quint32 blockIndex; // 塊序號從 0 開始 quint32 blockLen; // 本塊數據長度 quint32 blockCrc32; // 塊內數據 CRC32 校驗 qint64 fileOffset; // 本塊在文件中的偏移量 };代碼說明包頭一共32字節(jié)其中magic是固定值0x5A5A5A5A。接收端每次先從緩沖區(qū)里讀32字節(jié)檢查magic如果對不上就說明后續(xù)解析狀態(tài)已經錯亂直接斷開連接重新來。filenameLen和fileSize都是發(fā)文件時已知的信息服務器端拿到后可以先檢查磁盤空間。blockCrc32是每個數據塊的校驗值接收端算一遍不一致就把整個塊丟掉并請求重傳。參數說明blockIndex從0遞增配合fileOffset就能支持亂序和續(xù)傳。實際發(fā)送時按順序發(fā)但服務器端仍然以fileOffset為準來決定寫入位置。CRC32這里承擔的是“塊級校驗”文件級別的完整性另用MD5在收尾時做詳見后面章節(jié)。2.3 為什么不用現(xiàn)成協(xié)議這個項目是畢業(yè)設計場景。用HTTP上傳文件很簡單但答辯時你很難展示自己對網絡傳輸的理解因為HTTP協(xié)議把分塊、響應、狀態(tài)碼這些事情全部封裝掉了。FTP同樣是個選項不過FTP有控制連接和數據連接兩條通道還要處理被動模式端口協(xié)商跨平臺時兩個被動模式命令互相不兼容的情況很常見。自定義二進制協(xié)議的好處是你能明確說出“這一塊是包頭解析這一塊是粘包處理這一塊是校驗邏輯”每段代碼對應一個技術點階段驗收時很容易講清楚。代價是需要自己處理分包和粘包這個坑在下面的服務器端實現(xiàn)里會專門說到。3. Linux服務器端實現(xiàn)QTcpServer接收與落盤3.1 服務器主流程與監(jiān)聽初始化服務器端入口代碼很直接創(chuàng)建QTcpServer監(jiān)聽0.0.0.0:8899然后進入Qt事件循環(huán)。// main.cpp #include QCoreApplication #include QTcpServer #include fileServer.h int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); FileServer server; if (!server.listen(QHostAddress::Any, 8899)) { qCritical() 監(jiān)聽失敗: server.errorString(); return 1; } qInfo() 服務器已啟動監(jiān)聽端口 8899; return a.exec(); }邏輯說明監(jiān)聽地址用QHostAddress::Any而不是127.0.0.1這兩個的差別很關鍵。Any表示綁定到本機所有網卡地址這樣Windows客戶端從局域網訪問時才不會出現(xiàn)“連接被拒絕”。如果只監(jiān)聽127.0.0.1只有本機自己連得上。3.2 客戶端接入與文件數據塊接收QTcpServer有一個newConnection信號在信號里取出連接的socket描述符交給一個接收處理對象。注意這里不能用局部變量接socket因為socket生命周期必須跨越整個接收過程。// fileReceiver.h #pragma once #include QObject #include QTcpSocket #include QFile class FileReceiver : public QObject { Q_OBJECT public: explicit FileReceiver(qintptr socketDescriptor, QObject *parent nullptr); private slots: void onReadyRead(); // 可讀數據時觸發(fā) void onDisconnected(); // 客戶端斷開 private: bool parsePacket(const QByteArray rawData); // 解析一個完整數據包 void writeBlock(const char *data, qint64 len, qint64 offset); QTcpSocket *m_socket; QFile m_file; // 正在接收的文件句柄 QByteArray m_buffer; // 粘包/半包緩沖 bool m_headerDone false; };// fileReceiver.cpp 部分實現(xiàn) void FileReceiver::onReadyRead() { m_buffer.append(m_socket-readAll()); // 循環(huán)處理緩沖區(qū)內完整的數據包 while (true) { if (!m_headerDone) { if ((int)m_buffer.size() (int)sizeof(PacketHeader)) return; // 包頭都湊不齊繼續(xù)等 // 從緩沖區(qū)取出包頭這里需要用 memcpy 防止對齊問題 PacketHeader header; memcpy(header, m_buffer.constData(), sizeof(PacketHeader)); if (header.magic ! 0x5A5A5A5A) { m_socket-abort(); return; } // 根據包頭建立接收文件 if (header.cmd CMD_UPLOAD_INIT) { if ((int)m_buffer.size() (int)sizeof(PacketHeader) (int)header.filenameLen) return; // 文件名部分還沒到位 QByteArray fileNameBytes m_buffer.mid(sizeof(PacketHeader), header.filenameLen); QString fileName QString::fromUtf8(fileNameBytes); m_file.setFileName(/srv/uploads/ fileName); m_file.open(QIODevice::WriteOnly | QIODevice::Truncate); m_buffer.remove(0, sizeof(PacketHeader) header.filenameLen); m_headerDone true; continue; } } if (m_buffer.size() (int)sizeof(PacketHeader)) return; PacketHeader header; memcpy(header, m_buffer.constData(), sizeof(PacketHeader)); if (header.cmd CMD_DATA_BLOCK) { if (m_buffer.size() (int)sizeof(PacketHeader) (int)header.blockLen) return; // 數據塊內容沒到齊 const char *payload m_buffer.constData() sizeof(PacketHeader); quint32 crc qChecksum(payload, header.blockLen); if (crc ! header.blockCrc32) { // CRC 不一致跳過這個塊日志記錄 qWarning() CRC32 mismatch, block index: header.blockIndex; } else { writeBlock(payload, header.blockLen, header.fileOffset); // 每寫滿一個塊就 flush避免崩潰丟數據 m_file.flush(); } m_buffer.remove(0, sizeof(PacketHeader) header.blockLen); continue; } if (header.cmd CMD_UPLOAD_FINISH) { m_file.close(); m_socket-flush(); // 這里可以觸發(fā) MD5 計算見第 6 章 m_socket-disconnectFromHost(); return; } break; } }邏輯說明這個循環(huán)體就是協(xié)議解析的狀態(tài)機。每次readAll拿到新數據后追加到m_buffer然后循環(huán)從緩沖區(qū)頭部判斷先看包頭來沒來齊再根據包頭里的filenameLen和blockLen判斷整個包的數據來沒來齊。沒來齊就return等下一輪readyRead再繼續(xù)來齊了就把這段從緩沖區(qū)中移除避免殘留。參數說明塊CRC32用qChecksum計算它返回quint16。實際上qChecksum只能算CRC-16我的協(xié)議頭里聲明的是quint32所以這里存在參數寬度不匹配。實際項目中要么把協(xié)議頭里的blockCrc32改成quint16要么自己寫一個CRC32函數。畢業(yè)設計代碼里改成quint16最省事我給出的代碼按quint16使用qChecksum的返回值協(xié)議頭字段保持quint32但不影響功能。3.3 斷點續(xù)傳支持查詢已接收文件大小斷點續(xù)傳的實現(xiàn)思路是客戶端發(fā)送前先詢問服務器“這個文件你收了多少字節(jié)”服務器根據文件名找到本地文件返回文件大小客戶端從那個位置繼續(xù)讀文件、繼續(xù)發(fā)包。// 服務器收到 CMD_QUERY_OFFSET 時 else if (header.cmd CMD_QUERY_OFFSET) { // 從緩沖區(qū)取文件名 if (m_buffer.size() (int)sizeof(PacketHeader) (int)header.filenameLen) return; QByteArray fileNameBytes m_buffer.mid(sizeof(PacketHeader), header.filenameLen); QString fileName QString::fromUtf8(fileNameBytes); QFileInfo info(QString(/srv/uploads/) fileName); qint64 existLen info.exists() ? info.size() : 0; PacketHeader respHeader; memset(respHeader, 0, sizeof(respHeader)); respHeader.magic 0x5A5A5A5A; respHeader.cmd CMD_RESPONSE_OFFSET; respHeader.fileSize existLen; // 這里按 QDataStream 大端序寫出去 QByteArray respBuf; respBuf.append((const char *)respHeader, sizeof(PacketHeader)); m_socket-write(respBuf); // 清理緩沖 m_buffer.remove(0, sizeof(PacketHeader) header.filenameLen); continue; }邏輯說明服務器通過QFileInfo::size拿到已存在文件的字節(jié)數返回給客戶端。如果文件不存在返回0客戶端從0開始傳。這里有一點要特別注意斷點續(xù)傳不能沿用之前的WriteOnly打開方式應該用Append或者用QFile::seek定位到偏移位置再寫入。3.4 磁盤路徑與寫入權限的幾個細節(jié)服務器端保存路徑寫死為 /srv/uploads/這個目錄在普通Linux機器上默認不存在需要手動創(chuàng)建并改權限。常見做法是一行命令解決sudo mkdir -p /srv/uploads sudo chmod 777 /srv/uploads然后啟動服務器程序。這里有兩個低頻率但一踩就卡的坑一是目錄有了但進程以普通用戶運行無寫權限QFile::open返回false但qWarning不顯示二是磁盤滿了write失敗QFile可以繼續(xù)緩存但flush會報錯。我的習慣是每次open和flush之后都檢查返回值失敗就立刻abort連接并打日志。4. Windows 10客戶端實現(xiàn)UI、進度與斷點續(xù)傳4.1 MainWindow布局與信號槽連接客戶端的界面用QWidget搭一套就夠了。界面放四個主要控件服務器地址輸入框QLineEdit、端口輸入框QSpinBox、文件選擇按鈕QPushButton、發(fā)送按鈕QPushButton外加一個進度條QProgressBar和一個狀態(tài)標簽QLabel。// mainwindow.h #pragma once #include QMainWindow #include QTcpSocket #include QFile #include QProgressBar #include QLabel #include QLineEdit #include QPushButton #include QSpinBox class MainWindow : public QMainWindow { Q_OBJECT public: explicit MainWindow(QWidget *parent nullptr); private slots: void chooseFile(); // 選擇本地文件 void startTransfer(); // 開始傳輸 void onReadyRead(); // 接收服務器響應 void onConnected(); // 連接建立 private: void sendInitPacket(); void sendNextBlock(); QTcpSocket *m_socket; QFile m_file; QString m_fileName; qint64 m_fileSize; // 完整文件大小 qint64 m_sentBytes; // 已發(fā)送字節(jié)數 qint64 m_remoteOffset; // 服務器已有的數據長度 QLineEdit *m_serverIpEdit; QSpinBox *m_portSpinBox; QProgressBar *m_progressBar; QLabel *m_statusLabel; };構造函數里把按鈕的clicked信號連到對應的槽函數布局用一個QVBoxLayout從上到下排。這段UI代碼不長但信號槽綁定一定要在創(chuàng)建socket之前完成否則網絡事件回調里訪問空指針就是最常見的段錯誤現(xiàn)場。4.2 連接建立與初始化報文發(fā)送用戶點擊發(fā)送按鈕之后第一步是連接服務器然后發(fā)送一個CMD_UPLOAD_INIT包聲明文件名和大小等服務器確認完再進入數據塊循環(huán)。void MainWindow::startTransfer() { m_socket-connectToHost(m_serverIpEdit-text(), m_portSpinBox-value()); // 連接成功后由 onConnected 槽繼續(xù) } void MainWindow::onConnected() { QFileInfo info(m_file.fileName()); m_fileSize info.size(); m_socket-write(serializeInitPacket(m_fileName, m_fileSize)); }邏輯說明serializeInitPacket函數內部構造PacketHeader頭然后把文件名轉UTF-8后拼接在后面。發(fā)送這個包之后客戶端要等服務器的響應。這里的響應不是必須的但加上之后能做一個握手確認防止服務器還沒準備好人就開始發(fā)數據塊數據直接丟掉。4.3 分塊循環(huán)讀取與發(fā)送節(jié)奏控制分塊發(fā)送是整個客戶端性能的核心。千萬不能一次性把幾百MB讀進內存再write正確做法是固定64KB一個塊邊讀邊發(fā)。void MainWindow::sendNextBlock() { char block[64 * 1024]; qint64 readLen m_file.read(block, sizeof(block)); if (readLen 0) { // 讀完了發(fā) FINISH 包 PacketHeader header; memset(header, 0, sizeof(header)); header.magic 0x5A5A5A5A; header.cmd CMD_UPLOAD_FINISH; m_socket-write((const char *)header, sizeof(header)); m_statusLabel-setText(發(fā)送完成等待服務器確認); return; } PacketHeader header; memset(header, 0, sizeof(header)); header.magic 0x5A5A5A5A; header.cmd CMD_DATA_BLOCK; header.blockLen readLen; header.fileOffset m_file.pos() - readLen; // 讀一個塊后 pos 會前進要回退 m_sentBytes readLen; QByteArray packet; packet.append((const char *)header, sizeof(PacketHeader)); packet.append(block, readLen); m_socket-write(packet); m_progressBar-setValue((m_remoteOffset m_sentBytes) * 100 / m_fileSize); // 等下一次觸發(fā)后繼續(xù)發(fā)下一塊 }這里發(fā)送節(jié)奏由bytesWritten信號驅動每次write成功之后在bytesWritten槽里再次調用sendNextBlock形成“讀一塊、發(fā)一塊、再讀一塊”的鏈條。這個寫法的好處是發(fā)送緩沖區(qū)不會無限堆積內存占用始終在幾個塊左右。參數說明分塊大小64KB是一個兼顧吞吐和實時性的經驗值。設成1MB對大文件傳輸更快但單個網絡錯誤需要重傳的數據量也更大設成4KB則包數量太密QSocketNotifier頻繁觸發(fā)反而把CPU吃滿。我測試下來64KB在局域網Wi-Fi下比較穩(wěn)。4.4 斷點續(xù)傳的客戶端邏輯發(fā)送數據塊之前客戶端先發(fā)一個CMD_QUERY_OFFSET包帶上文件名從服務器響應里解析出remoteOffset。然后打開本地文件調用m_file.seek(remoteOffset)進度條初始值設為remoteOffset再進入正常的分塊發(fā)送循環(huán)。后續(xù)包的fileOffset字段以seek之后的實際值計算。關鍵點是發(fā)送完最后一個塊之后的FINISH包不能帶offset參數。服務器收到FINISH就會執(zhí)行MD5校驗如果此時文件size比預期少一個塊校驗必然失敗這個文件會被標記為錯誤狀態(tài)。5. 跨平臺編譯與避坑qmake差異和四個高頻故障5.1 工程文件與兩端構建命令這個項目涉及兩端編譯Linux服務器端是無界面的console程序Windows客戶端是帶QWidget界面的程序。兩套工程文件不需要分開維護用qmake的QT變量做條件判斷就行。QT core gui network greaterThan(QT_MAJOR_VERSION, 4): QT widgets TARGET FileTransfer TEMPLATE app CONFIG c11 SOURCES \ main.cpp \ fileServer.cpp HEADERS \ fileServer.h \ protocol.h # Windows 客戶端額外編譯 UI 相關文件 win32 { SOURCES mainwindow.cpp HEADERS mainwindow.h }Linux上編譯命令是傳統(tǒng)的三連qmake FileTransfer.pro make -j$(nproc) ./FileTransferWindows客戶端用Qt Creator打開工程文件選擇MSVC 2019 64bit套件點擊構建。這里有一個在Qt 5.15之后經常讓人卡住的問題如果Qt下載時沒勾選MSVC組件或者系統(tǒng)沒裝Windows 10 SDK編譯時會報“Cannot find MSVC toolset”。解決辦法是重裝Qt時勾全MSVC組件或者改用MinGW套件。我不建議混用這兩套MinGW編譯的插件和MSVC編譯的插件互不兼容到時候在工程里很難排查。5.2 中文文件名與GBK/UTF-8編碼差異現(xiàn)象Windows客戶端選了“測試報告.txt”Linux服務器上保存的名字是亂碼。原因Windows 10中文版的文件系統(tǒng)默認使用GBK編碼而協(xié)議里定義文件名按UTF-8傳輸。Linux端QString::fromUtf8能正確處理UTF-8但Windows端把QString轉字節(jié)時如果直接用QFile::encodeName它內部用的是本地編碼不是UTF-8所以發(fā)出去就是GBK服務器按UTF-8解就亂套了。解決客戶端發(fā)文件名時強制用QString::toUtf8接收文件名后用QString::fromUtf8。兩端同一套代碼里所有文件名都不經過QFile::encodeName和fromLocal8Bit。Qt 6里QTextCodec被移除了但QStringConverter功能一樣重點是明確指定UTF-8不依賴系統(tǒng)語言環(huán)境的默認編碼。5.3 防火墻與監(jiān)聽地址組合導致連接失敗現(xiàn)象Windows客戶端連接Linux服務器時一直提示“遠程主機拒絕連接”。原因服務器監(jiān)聽了0.0.0.0客戶端IP也對但Linux服務器上iptables規(guī)則攔截了8899端口。這是最常見的一類原因。反過來如果Linux服務器連Windows上的客戶端Windows防火墻入站規(guī)則默認不放開。解決Linux端臨時放行一個端口sudo iptables -I INPUT -p tcp --dport 8899 -j ACCEPTWindows端更省事的做法是在防火墻面板里新建入站規(guī)則允許TCP 8899端口不限遠程IP。調通后再按最小權限收緊。驗證連接是否通可以直接用nc去測nc -vz 192.168.1.100 8899返回succeeded說明端口通否則就得回頭檢查防火墻和監(jiān)聽地址。5.4 接收文件大小始終對不上現(xiàn)象傳1GB的文件服務器上落盤只有850MB左右但客戶端顯示發(fā)送完成。檢查日志發(fā)現(xiàn)客戶端把文件讀完之前就把FINISH包發(fā)掉了。原因最典型的場景是最后一次read返回了部分塊但客戶端讀寫循環(huán)里沒有仔細處理QFile::read的返回值以為這次讀完就結束了直接發(fā)FINISH。另一種情況是write只是把數據放到了Qt發(fā)送緩沖區(qū)沒有等待數據真正寫到網卡進程退出后緩沖區(qū)內數據被丟棄。解決客戶端發(fā)送循環(huán)以read返回值是否小于等于0作為結束條件并且讀到數據后先檢查read結果與預期長度是否一致。發(fā)送完成后調用m_socket-waitForBytesWritten(3000)確保數據全部離開發(fā)送緩沖區(qū)再退出。服務器端則在寫盤截止后自行核對文件大小和包頭里的fileSize一致才允許FINISH成功不一致就發(fā)CMD_ERROR_RESP斷開連接。5.5 斷點續(xù)傳失效且文件尾出現(xiàn)臟數據現(xiàn)象中斷傳輸后重新發(fā)送服務器會把新數據接到錯誤位置文件尾部有重復的舊數據。原因續(xù)傳時直接用WriteOnly模式打開文件客戶端seek到offset發(fā)送但服務器文件句柄還在文件開始處write寫進去的位置和客戶端聲明的位置錯位。解決服務器在收到QUERY_OFFSET之后文件打開方式改成QIODevice::WriteOnly | QIODevice::Append并且把文件指針seek到服務器返回給客戶端的那條offset上。續(xù)傳期間不再用Truncate。6. 驗證方法與進階技巧每秒塊計數與MD5閉環(huán)6.1 從回環(huán)到局域網的驗證路徑拿到這套代碼后我建議按三個層次順序驗證不要一上來就跨機器傳大文件出了問題很難定位。第一步是Windows客戶端連接Linux服務器傳一個幾百KB的小文本文件驗證協(xié)議包和落盤路徑按預期工作。第二步是在同一臺Linux服務器上自連自傳跑一次2GB的隨機文件監(jiān)控內存占用和磁盤寫入速度這一步能暴露大部分內存和flush問題。第三步才到Windows真機訪問Linux服務器兩個設備接同一路由器或交換機確認防火墻規(guī)則都放行。驗證時記錄三組數據總耗時、峰值內存、落盤文件與源文件MD5一致性。手動算MD5可以用Linux的md5sumWindows的certutil -hashfile MD5。把兩端算出來的結果對比一致才算這輪通過。6.2 傳輸結束后自動生成MD5校驗文件服務器在收到FINISH包之后用QCryptographicHash掃描一遍落盤文件算出MD5值寫入同名文件加后綴result的文件里。客戶端拿到這個結果文件后和本地算出的MD5比對可以快速確認文件完整性。// 服務器端收到 CMD_UPLOAD_FINISH 后 void FileReceiver::verifyAndfinish() { m_file.close(); QFile checkFile(m_file.fileName()); if (!checkFile.open(QIODevice::ReadOnly)) { m_socket-write(errorPacket(cannot open received file)); return; } QCryptographicHash hash(QCryptographicHash::Md5); QByteArray buf; while (!checkFile.atEnd()) { buf checkFile.read(1024 * 1024); // 1MB 緩沖讀避免大文件占滿內存 hash.addData(buf); } QByteArray md5Result hash.result().toHex(); QFile resultFile(m_file.fileName() .md5); resultFile.open(QIODevice::WriteOnly); resultFile.write(md5Result); resultFile.close(); }參數說明這里按1MB緩沖讀取大文件避免一次性把整個文件讀進內存。QCryptographicHash支持Md5和Sha256畢業(yè)設計用Md5夠用如果要更強的完整性訴求可以換Sha256。這樣服務器落盤目錄里每個文件旁邊都有一個md5文件客戶端可以事后拉取校驗。6.3 雙向傳輸擴展當前這套結構是單方向的服務器只接收。如果你想把Linux上的文件下載回Windows不需要改協(xié)議只要把服務器端的接收邏輯改成發(fā)送邏輯、把客戶端的發(fā)送邏輯改成接收邏輯即可。關鍵點是PacketHeader里的cmd字段增加兩個命令字例如CMD_DOWNLOAD_INIT和CMD_DOWNLOAD_BLOCK服務器收到請求后打開Linux本地文件分塊發(fā)給客戶端客戶端接收后落盤到Windows指定目錄。整個過程沿用同一個包頭結構代碼復用率很高。從那以后我每次給新機器編譯這套系統(tǒng)都會先跑一遍小文件回環(huán)測試再傳大文件強制把MD5校驗結果也過目一遍。這個習慣救過我好幾次有一次就是UTF-8編碼沒統(tǒng)一導致文件名亂碼小文本文件看不出來傳中文名壓縮包才暴露。整套代碼的做法和邊界我已經拆得很清楚剩下的就是你自己動手把這幾處坑都踩一遍踩完理解就牢固了。希望幫到你。本文還有配套的精品資源點擊獲取