簡介這份《QT學習之路2-2020整理版》面向希望系統(tǒng)掌握Qt框架的C開發(fā)者與初學者基于豆子博客內(nèi)容整理并補全了2016年后更新的15章共94章覆蓋從環(huán)境搭建、Hello world、信號槽機制到多線程、國際化、數(shù)據(jù)庫與網(wǎng)絡編程等進階主題。資源為單一PDF文件壓縮包約5.79MB內(nèi)容按章節(jié)編排目錄清晰便于按模塊檢索學習。目前已有870人學習下載。讀者可借此完整梳理Qt5核心知識體系理解信號槽、事件處理、布局管理、MainWindow與對話框數(shù)據(jù)傳遞等關鍵機制并借助Qt Creator使用技巧與調(diào)試方法將理論落到實際項目開發(fā)中適合從入門到進階的持續(xù)學習。1. Qt 學習之路2為什么 445 頁的教程值得逐行啃很多人第一次接觸 Qt是從拖控件開始的。打開 Qt Creator拖幾個按鈕連一下信號槽跑起來覺得“不過如此”。但一旦遇到界面卡死、事件不響應、多線程里對象莫名崩潰就徹底懵了。問題的根源在于你用的是 Qt 的“表面 API”卻沒搞懂它背后的對象模型、事件循環(huán)和元對象系統(tǒng)。這份《Qt 學習之路2》2020 整理版把豆子從 2012 年到 2016 年寫的 94 章內(nèi)容完整收進來共 445 頁從 Hello World 一路講到線程、XML、數(shù)據(jù)庫、QML。它最大的價值不是教你“怎么調(diào) API”而是把 Qt 為什么這么設計、底層怎么跑通一層層拆開給你看。如果你已經(jīng)會寫幾行 Qt 代碼卻總覺得心里沒底這份資料就是幫你把地基補上的那塊磚。2. 信號槽為什么一個 connect 能跨線程、跨對象地傳消息2.1 從函數(shù)調(diào)用到元對象信號槽不是 C 原生語法普通 C 函數(shù)調(diào)用編譯期就確定了地址直接跳轉就行。但信號槽不一樣你寫connect(sender, Sender::signal, receiver, Receiver::slot)編譯時并不知道誰會觸發(fā)、什么時候觸發(fā)、甚至接收者在不在同一個線程。Qt 能實現(xiàn)這套機制靠的是三樣東西元對象系統(tǒng)Meta-Object System、mocMeta-Object Compiler和 QObject 的對象樹。每個繼承 QObject 并聲明Q_OBJECT宏的類moc 會為它生成一份額外的 C 代碼里面包含信號函數(shù)的實現(xiàn)、qt_metacall() 分發(fā)邏輯以及一張字符串到函數(shù)索引的映射表。信號本身沒有函數(shù)體moc 生成的代碼會調(diào)用QMetaObject::activate()由它去查連接表找到所有連到這個信號的槽然后逐個調(diào)用。常見的實現(xiàn)思路是QObject 內(nèi)部維護一個 QObjectPrivate 結構里面有一個connectionLists按信號索引組織。每個連接記錄發(fā)送者、接收者、槽的索引、連接類型。當信號被激活activate()遍歷這個列表根據(jù)連接類型決定是直接調(diào)用、排隊調(diào)用還是阻塞調(diào)用。2.2 連接類型Auto、Direct、Queued 到底怎么選Qt 定義了五種連接類型最常用的是 Auto、Direct 和 Queued。Auto 是默認值它的行為取決于發(fā)送者和接收者是否在同一個線程同線程就退化成 Direct跨線程就退化成 Queued。Direct 連接意味著槽函數(shù)在信號發(fā)出的線程里立刻執(zhí)行相當于一次普通函數(shù)調(diào)用但多了查表開銷。Queued 連接則把調(diào)用包裝成一個 QMetaCallEvent通過QCoreApplication::postEvent()投遞到接收者所在線程的事件隊列等那個線程的事件循環(huán)處理到這個事件時再調(diào)用槽函數(shù)。這里有一個血淚經(jīng)驗如果你在跨線程時用了 Direct槽函數(shù)會在發(fā)送者線程執(zhí)行但操作的是接收者線程的對象輕則數(shù)據(jù)競爭重則直接崩潰。Qt 文檔里反復強調(diào)“Queued 連接參數(shù)必須是可拷貝的”就是因為參數(shù)要被復制到事件對象里等事件循環(huán)處理時再還原。// 跨線程必須用 Queued或者依賴 Auto 自動判定 connect(workerThread, Worker::resultReady, guiObject, Gui::handleResult, Qt::QueuedConnection); // 如果寫成 DirecthandleResult 會在 workerThread 里跑 // 此時 guiObject 的成員變量可能被兩個線程同時訪問上面代碼里Qt::QueuedConnection強制把調(diào)用排隊到 guiObject 所屬線程。參數(shù)resultReady攜帶的數(shù)據(jù)會被 QMetaCallEvent 拷貝一份所以自定義類型必須用qRegisterMetaType()注冊否則運行時會報 “Cannot queue arguments of type”。2.3 對象樹與線程親和性為什么 moveToThread 之后不能直接調(diào)槽QObject 有一個“線程親和性”thread affinity的概念用thread()返回它所屬的線程。默認情況下對象屬于創(chuàng)建它的線程。moveToThread()可以改變這個歸屬但只能由當前所屬線程調(diào)用而且不能對有父對象的對象調(diào)用——因為父子關系意味著對象樹管理跨線程移動會破壞析構順序。很多人踩過的坑是把 worker 對象 moveToThread 之后直接調(diào)用它的方法以為這樣就在新線程里跑了。實際上直接調(diào)用是普通函數(shù)調(diào)用還是在當前線程執(zhí)行。只有通過信號槽Queued或QMetaObject::invokeMethod()并指定 Queued 連接才會真正切到目標線程的事件循環(huán)里執(zhí)行。// 正確做法用 invokeMethod 排隊調(diào)用 QMetaObject::invokeMethod(worker, doWork, Qt::QueuedConnection, Q_ARG(QString, data)); // 錯誤做法直接調(diào)還在當前線程 worker-doWork(data); // 線程親和性沒變執(zhí)行線程也沒變invokeMethod的 Queued 模式會把方法調(diào)用包裝成事件投遞到 worker 所屬線程。參數(shù)用Q_ARG宏包裝類型必須已注冊元類型。如果方法有返回值Queued 模式下拿不到只能通過信號回傳。3. 事件循環(huán)為什么你的界面會卡死以及事件過濾器怎么救場3.1 QEventLoop 的本質(zhì)一個不停取事件的 while 循環(huán)Qt 程序啟動后QApplication::exec()會進入一個死循環(huán)不斷從事件隊列里取出事件分發(fā)給對應的 QObject。這個循環(huán)就是 QEventLoop。每個線程可以有自己的事件循環(huán)GUI 線程的事件循環(huán)由 QApplication 啟動工作線程可以用QThread::exec()啟動。事件的分發(fā)路徑是QCoreApplication::notify()→QObject::event()→ 具體的事件處理函數(shù)如mousePressEvent()。notify()是虛函數(shù)可以重寫但更常見的做法是裝事件過濾器。界面卡死的根本原因通常是你在 GUI 線程里干了耗時的事——比如讀一個大文件、等網(wǎng)絡響應、跑復雜計算。事件循環(huán)被你的代碼占住沒法取下一個事件界面自然不刷新。解決思路只有兩個把耗時操作挪到工作線程或者在耗時操作里手動調(diào)用QCoreApplication::processEvents()讓事件循環(huán)喘口氣。后者是權宜之計容易引發(fā)重入問題不推薦。3.2 事件過濾器在 event() 之前截胡事件過濾器event filter是一個 QObject通過installEventFilter()裝到目標對象上。當目標對象收到事件時QCoreApplication::notify()會先調(diào)用過濾器的eventFilter()函數(shù)。如果返回 true事件就被吃掉不再往下傳返回 false繼續(xù)正常分發(fā)。這個機制常用來做全局快捷鍵、鼠標懸停預覽、輸入框內(nèi)容實時校驗。比如你想讓某個 QLineEdit 只接受數(shù)字可以裝一個過濾器在 KeyPress 事件到達輸入框之前攔截非數(shù)字鍵。bool NumericFilter::eventFilter(QObject *watched, QEvent *event) { if (event-type() QEvent::KeyPress) { auto *keyEvent static_castQKeyEvent *(event); if (keyEvent-key() Qt::Key_0 || keyEvent-key() Qt::Key_9) { return true; // 吃掉非數(shù)字鍵 } } return QObject::eventFilter(watched, event); // 放行 }watched是裝過濾器的目標對象event是待處理事件。返回 true 表示“已處理別再往下走”。注意過濾器對象本身必須活得比目標對象久否則目標對象析構時可能訪問懸空指針。3.3 自定義事件與 sendEvent/postEvent 的區(qū)別Qt 允許你定義自己的事件類型繼承 QEvent用一個大于QEvent::User的枚舉值。發(fā)送自定義事件有兩種方式sendEvent()同步發(fā)送事件立刻被處理相當于直接調(diào)用notify()postEvent()異步發(fā)送事件被放進隊列等事件循環(huán)下一輪再處理。同步發(fā)送適合需要立刻拿到結果的場景但要注意重入——如果接收者在處理事件時又發(fā)了同樣的事件可能無限遞歸。異步發(fā)送更安全但事件對象必須用new分配在堆上Qt 處理完后會自動 delete你不能手動刪。// 自定義事件類型 class MyEvent : public QEvent { public: MyEvent(const QString msg) : QEvent(static_castQEvent::Type(QEvent::User 1)), m_msg(msg) {} QString message() const { return m_msg; } private: QString m_msg; }; // 異步發(fā)送事件對象由 Qt 管理 QCoreApplication::postEvent(receiver, new MyEvent(hello));postEvent之后事件對象的所有權轉移給 Qt你不能再碰它。接收者重寫customEvent()來處理或者重寫event()做更通用的分發(fā)。4. 避坑與排查信號槽、事件、線程里最容易翻車的幾個點4.1 信號槽連接成功但槽不執(zhí)行現(xiàn)象connect返回 true編譯運行都沒報錯但槽函數(shù)死活不進。原因最常見的是接收者對象在信號發(fā)出前已經(jīng)被析構Qt 會自動斷開連接但如果你用的是函數(shù)指針語法且對象已銷毀行為未定義。另一個原因是連接類型是 Queued但接收者線程沒有事件循環(huán)事件永遠排隊沒人處理。解決檢查接收者是否還活著用QPointer或QObject::isSignalConnected()確認。如果是跨線程 Queued確保接收者線程調(diào)用了exec()或QThread::run()里有事件循環(huán)。4.2 在槽函數(shù)里 delete 發(fā)送者導致崩潰現(xiàn)象槽函數(shù)執(zhí)行到一半程序段錯誤。原因信號發(fā)出后Qt 會遍歷連接列表調(diào)用槽。如果某個槽把發(fā)送者 delete 了后續(xù)槽再訪問發(fā)送者就是野指針。Direct 連接下這個問題尤其明顯。解決用deleteLater()代替delete。deleteLater()會投遞一個 DeferredDelete 事件等當前事件循環(huán)回到最外層時才真正析構保證所有槽都執(zhí)行完。4.3 moveToThread 之后定時器不觸發(fā)現(xiàn)象QTimer 在 moveToThread 之后不走了。原因QTimer 依賴事件循環(huán)。如果對象被移到新線程但新線程沒有啟動事件循環(huán)沒調(diào)exec()定時器事件沒人處理。解決在 QThread 的run()里調(diào)用exec()或者用QThread::started信號連接到工作對象的初始化槽確保事件循環(huán)先跑起來。4.4 事件過濾器返回 true 導致界面無響應現(xiàn)象裝了事件過濾器后某個控件完全點不動。原因eventFilter()里對所有事件都返回了 true把鼠標、鍵盤事件全吃了。解決只攔截你關心的事件類型其余一律返回QObject::eventFilter(watched, event)。不要圖省事直接return true。4.5 跨線程信號槽傳自定義類型報錯現(xiàn)象運行時報 “Cannot queue arguments of type MyType”。原因Queued 連接需要把參數(shù)拷貝到事件對象里Qt 必須知道怎么構造、析構、拷貝這個類型。自定義類型默認沒注冊元類型。解決在main()里或類定義后調(diào)用qRegisterMetaTypeMyType(MyType)并且 MyType 要有默認構造函數(shù)、拷貝構造函數(shù)和析構函數(shù)。5. 從 94 章到工程實踐怎么用這份資料把 Qt 底層吃透這份 445 頁的資料章節(jié)編排本身就是一條從表層到底層的路徑。前 15 章講基礎控件和信號槽用法第 16 章“深入 Qt5 信號槽新語法”開始往元對象系統(tǒng)里鉆第 18 到 23 章集中講事件機制第 71 到 75 章把線程和 QObject 的關系徹底攤開。如果你只是順著讀很容易停在“會用”的層面。更有效的方式是每讀到一個機制就自己寫一個最小復現(xiàn)然后故意制造錯誤看 Qt 報什么、怎么崩。比如讀到“隱式數(shù)據(jù)共享”那一章你可以寫一個 QString用constData()拿指針然后拷貝一份修改原對象觀察指針地址變不變。Qt 的隱式共享用引用計數(shù)實現(xiàn)拷貝時只增計數(shù)寫時才真正復制copy-on-write。這個機制在容器類里普遍存在理解它能幫你避開大量無謂的性能損耗。再比如 model/view 架構第 41 到 50 章用了大量篇幅。很多人覺得 model/view 比 QTableWidget 麻煩不如直接填表格。但當你需要展示十萬行數(shù)據(jù)、還要排序過濾時QTableWidget 會直接卡死而 QAbstractItemModel 配合 QSortFilterProxyModel 可以做到只渲染可見區(qū)域。這份資料把自定義只讀模型、可編輯模型、布爾表達式樹模型都拆了一遍跟著寫一遍基本就能掌握 model/view 的骨架。最后一章落到設計取舍上。Qt 的信號槽比普通函數(shù)調(diào)用慢大約一個數(shù)量級這是 Qt 4 文檔里明確寫的。但換來的是解耦和跨線程安全。你在做高頻交易系統(tǒng)或?qū)崟r渲染時可能得避開信號槽直接用回調(diào)或虛函數(shù)。但在常規(guī)桌面應用里這點開銷完全可以接受。Qt 的跨平臺策略是 GUI 模擬不是 API 映射所以它的界面不是原生風格但換來了外觀的高度可定制。這些取舍沒有絕對的對錯只有場景匹配。我自己的習慣是每次接手一個 Qt 項目先看它的線程模型和事件循環(huán)怎么組織的再看信號槽連接類型有沒有用錯。從那以后我每次寫跨線程代碼都強制走一遍moveToThreadQueuedConnectionqRegisterMetaType三件套再也沒遇到過玄學崩潰。希望這份資料也能幫你把 Qt 的底層邏輯理清楚少踩幾個坑。本文還有配套的精品資源點擊獲取