簡介基于Qt框架的輕量級記事本源碼項目面向Qt、C初學者完整展示從窗口創(chuàng)建、菜單布局到文件打開保存的基礎(chǔ)實現(xiàn)思路。界面刻意保持極簡未添加狀態(tài)欄與查找替換等附加功能適合快速了解跨平臺桌面應(yīng)用的工程組織方式和界面事件處理流程。壓縮包共十五個文件整體大小約一百四十三KB其中包含C源文件、頭文件、用戶界面文件、工程配置文件、資源文件以及圖標和說明圖片目錄結(jié)構(gòu)清晰便于按模塊對照學習。目前已有三百零二人學習下載。源碼將主窗口類與對話框類分離可直觀體會控件信號與槽機制通過編譯運行可驗證基礎(chǔ)編輯功能后續(xù)也容易自行擴展狀態(tài)欄或查找替換能力適合作為課程設(shè)計或自學練手項目。1. 用 Qt 寫一個簡單記事本先別急著寫代碼“Notepad_QT_簡單記事本_”這個工程名字看起來平平無奇但它背后指向的是每個 Qt 初學者都會做一遍的經(jīng)典練習把打開、保存、查找替換、字數(shù)統(tǒng)計這些最熟悉的桌面操作用 Qt Widgets 重新實現(xiàn)一遍。做這個小項目的價值不在“記事本”本身而在于把 QMainWindow、QPlainTextEdit、QFileDialog、QTextCursor 這四樣核心組件串起來等于把 Qt 桌面開發(fā)的主干走了一遍。這篇筆記直接按可編譯的 Qt 5.15 LTS 工程來寫適合剛學完信號與槽的初學者也適合想快速產(chǎn)出內(nèi)部文本小工具、又不想引入復(fù)雜框架的工程師。你會發(fā)現(xiàn)記事本雖小但編碼、換行符、部署這些真正折磨人的問題一個都少不了。2. 編輯器核心選型與主窗口骨架為什么是 QPlainTextEdit 而不是 QTextEdit2.1 QPlainTextEdit、QTextEdit、QTextBrowser記事本為什么鎖死 QPlainTextEdit很多第一次動手的人會順手放一個 QTextEdit因為教程里出現(xiàn)得最多。QTextEdit 是富文本編輯器默認支持一部分 HTML可以插入圖片、修改字體顏色、設(shè)置表格QPlainTextEdit 則是為純文本場景設(shè)計的內(nèi)部按塊block組織文本繪制和滾動都針對大段文字做過優(yōu)化。同樣是打開一個幾 MB 的日志文件QTextEdit 會明顯卡頓QPlainTextEdit 在多數(shù)機器上依然能流暢翻頁。記事本只需要處理純文本所以核心組件鎖死 QPlainTextEdit這是性能和實現(xiàn)成本雙重考慮下來的結(jié)論。QTextBrowser 則是 QTextEdit 的只讀子類適合做幫助文檔、富文本查看器不適合做編輯器。如果你的目標是“能打字的記事本”不需要考慮它。還有一個容易忽略的選項如果只是做日志監(jiān)控可以在 QPlainTextEdit 上調(diào)用setMaximumBlockCount(5000)讓文本區(qū)只保留最近 5000 行這樣長時間運行也不會把內(nèi)存吃滿——這個參數(shù)對記事本同樣有意義打開的日志文件再大界面也不會拖死。提示QPlainTextEdit 的setMaximumBlockCount是行數(shù)上限超出后自動丟棄舊塊對“打開一個大日志文件”的場景很實用但對普通 txt 建議設(shè)為 00 表示不限制。2.2 最小可運行的 QMainWindow 工程菜單、工具欄、狀態(tài)欄一起搭我一般用 Qt Creator 新建 Qt Widgets Application但不用它自動生成的 MainWindow.ui而是全部手寫界面。這樣做的原因是手寫代碼能把“菜單、工具欄、狀態(tài)欄、中心組件”的關(guān)系交代清楚用 Qt Designer 拖界面雖然快但新手很容易被.ui編譯機制帶偏。以下是整個工程的入口文件。#include QApplication #include MainWindow.h int main(int argc, char *argv[]) { QApplication app(argc, argv); app.setApplicationName(SimpleNotepad); // 這個名字影響第 6 章 QSettings 的存儲路徑 app.setOrganizationName(DevWorkshop); MainWindow w; w.show(); return app.exec(); // 進入事件循環(huán)直到窗口關(guān)閉 }邏輯說明QApplication 是每個 Qt GUI 程序必須創(chuàng)建的對象它負責事件循環(huán)和全局設(shè)置setApplicationName和setOrganizationName看起來是元數(shù)據(jù)實際上決定第 6 章 QSettings 默認寫入的注冊表或配置文件位置不設(shè)置的話 QSettings 可能無法正常工作。MainWindow 的構(gòu)造里把菜單、工具欄、狀態(tài)欄和中心編輯區(qū)一次性搭好。MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent) { setWindowTitle(tr(記事本 - 未命名)); resize(1000, 680); editor new QPlainTextEdit(this); setCentralWidget(editor); // 編輯區(qū)占滿主窗口剩余空間 connect(editor, QPlainTextEdit::textChanged, this, MainWindow::onTextChanged); // 文本變化后刷新狀態(tài)欄和標題標記 statusBar()-showMessage(tr(就緒), 3000); createActions(); createMenus(); createToolBar(); }參數(shù)說明resize(1000, 680)是初始窗口尺寸沒有設(shè)置最小尺寸用戶仍可自由拖拽statusBar()-showMessage(msg, 3000)的第二個參數(shù)是顯示毫秒數(shù)3000 表示 3 秒后自動清空。createActions、createMenus、createToolBar三個方法按名字拆分避免構(gòu)造函數(shù)寫得太長。動作和菜單的完整代碼如下void MainWindow::createActions() { openAction new QAction(tr(打開...), this); openAction-setShortcut(QKeySequence::Open); // 自動映射 CtrlO connect(openAction, QAction::triggered, this, MainWindow::openFile); saveAction new QAction(tr(保存), this); saveAction-setShortcut(QKeySequence::Save); // 自動映射 CtrlS connect(saveAction, QAction::triggered, this, MainWindow::saveFile); quitAction new QAction(tr(退出), this); quitAction-setShortcut(QKeySequence::Quit); connect(quitAction, QAction::triggered, this, QWidget::close); } void MainWindow::createMenus() { QMenu *fileMenu menuBar()-addMenu(tr(文件(F))); fileMenu-addAction(openAction); fileMenu-addAction(saveAction); fileMenu-addSeparator(); fileMenu-addAction(quitAction); } void MainWindow::createToolBar() { QToolBar *toolBar addToolBar(tr(常用)); toolBar-setMovable(false); toolBar-addAction(openAction); toolBar-addAction(saveAction); }QKeySequence::Open 和 QKeySequence::Save 是 Qt 內(nèi)置的標準快捷鍵枚舉在 Windows 上映射為 CtrlO、CtrlS在 macOS 上自動變成 Command 鍵比硬編碼QKeySequence(CtrlO)更穩(wěn)。QToolBar 的setMovable(false)是給工具欄上鎖防止用戶不小心把它拖出來變成懸浮窗口如果是高級用戶使用的工具可以把這行去掉允許自由排版。2.3 字體與縮進的 3 個常用參數(shù)Monospace 字體和 Tab 距離記事本的核心體驗是“代碼和配置文件的縮進要整齊”因此字體必須選等寬字體Tab 鍵距離要固定。以下是三個必調(diào)參數(shù)QFont mono(Courier New); mono.setStyleHint(QFont::Monospace); // 系統(tǒng)沒有 Courier New 時自動替換為其他等寬字體 mono.setPointSize(10); editor-setFont(mono); editor-setLineWrapMode(QPlainTextEdit::WidgetWidth); editor-setTabStopDistance(4 * QFontMetricsF(editor-font()).horizontalAdvance(QLatin1Char( )));參數(shù)說明setStyleHint(QFont::Monospace)很關(guān)鍵在 Linux 或 macOS 上沒有 Courier New 時Qt 會根據(jù)這個提示自動選擇 DejaVu Sans Mono、Menlo 等系統(tǒng)等寬字體避免回退到中文字體導(dǎo)致對齊失敗。setLineWrapMode(QPlainTextEdit::WidgetWidth)是自動換行文本超過窗口寬度時自動折行如果做日志工具很多人喜歡NoWrap加水平滾動條記事本默認用自動換行更貼近 Windows 記事本的行為。setTabStopDistance在 Qt 5.10 以后是重載函數(shù)參數(shù)是像素寫成 4 個空格寬度按下 Tab 后光標正好跳 4 個空格老代碼里的setTabStopWidth在 Qt 5.10 起被標記廢棄不要混用。到這里一個能打字、能顯示菜單欄和狀態(tài)欄的記事本骨架已經(jīng)跑起來了。剩下的問題全部集中在“文件怎么打開、怎么保存、怎么防止亂碼”上這是記事本項目里最容易翻車的一段。3. 打開與保存的完整實現(xiàn)編碼探測、換行符統(tǒng)一與 BOM 處理3.1 打開文件時怎么判斷 UTF-8 還是 GBKBOM 優(yōu)先非法 UTF-8 兜底記事本最常見的翻車現(xiàn)場就是亂碼。Qt 5 之后內(nèi)部字符串默認是 UTF-8但 Windows 舊版記事本保存中文時默認用 ANSI也就是 GBK/GB18030網(wǎng)上下載的配置文件可能是 UTF-8 無 BOMLinux 過來的文件換行符還是 LF。所以打開文件不能只做QFile::readAll()加toUtf8()要先做編碼探測和換行符統(tǒng)一。下面是完整的 openFile 實現(xiàn)。bool MainWindow::openFile(const QString filePath) { QFile file(filePath); if (!file.open(QIODevice::ReadOnly)) { QMessageBox::warning(this, tr(打開失敗), file.errorString()); return false; } QByteArray data file.readAll(); // 一次性讀入文件不大時最簡單 file.close(); // 先把三類換行符統(tǒng)一成 \n后面所有邏輯只處理 \n data.replace(\r\n, \n); data.replace(\r, \n); QByteArray utf8Bom QByteArray::fromHex(efbbbf); QTextCodec *codec nullptr; if (data.startsWith(utf8Bom)) { data.remove(0, 3); // 去掉 BOM 后再解碼否則首行會出現(xiàn)不可見字符 codec QTextCodec::codecForName(UTF-8); } else { QString utf8Guess QString::fromUtf8(data); // 按 UTF-8 嘗試解碼 if (!utf8Guess.contains(QChar::ReplacementCharacter)) { codec QTextCodec::codecForName(UTF-8); } else { codec QTextCodec::codecForName(GB18030); // 兼容 GBK/GB2312 } } editor-setPlainText(codec-toUnicode(data)); editor-document()-setModified(false); setWindowModified(false); setWindowTitle(tr(%1 - 記事本).arg(QFileInfo(filePath).fileName())); return true; }邏輯說明data.replace(\r\n, \n)必須寫在replace(\r, \n)之前因為如果先把\r替換成\n原來的\r\n會變成\n\n這就翻車了。這段代碼先處理 CRLF再處理單獨的 CR能把 Windows、Unix、老 Mac 三種換行符統(tǒng)一成 LF。編碼探測的核心是QString::fromUtf8(data)如果字節(jié)流不是合法的 UTF-8解碼結(jié)果里會出現(xiàn) UFFFD 替換符通過判斷替換符是否存在來決定是否切到 GB18030。這個方案比“帶 BOM 就 UTF-8不帶就當 GBK”更穩(wěn)因為很多 Linux 生成的文本是沒有 BOM 的 UTF-8。需要注意的差異QTextCodec 在 Qt 6 中被移到了 Qt5Compat 模塊使用 Qt 6 時需要在 .pro 文件里加QT core5compat否則#include QTextCodec會報找不到頭文件。GB18030 是 GBK 的超集向下兼容所以用它做兜底不會損失舊文件。這個方案還有個理論盲區(qū)如果原文件本身就是 UTF-8 編碼的替換符字符 UFFFD會被誤判成 GB18030實際工程中概率極低不必為此增加復(fù)雜度。3.2 保存成 Windows 記事本能認的文件寫回時統(tǒng)一換行符和可選 BOM保存同樣不能只寫toPlainText().toUtf8()。原因是 QPlainTextEdit 內(nèi)部的換行符統(tǒng)一是\n但 Windows 記事本默認用\r\n如果直接寫文件Windows 老版本記事本會把整個文本顯示成一行。另外要不要寫 UTF-8 BOM決定了文件在 Windows 記事本里能否被正確識別為 UTF-8。bool MainWindow::saveFile(const QString filePath) { QFile file(filePath); if (!file.open(QIODevice::WriteOnly | QIODevice::Truncate)) { QMessageBox::warning(this, tr(保存失敗), file.errorString()); return false; } QByteArray data editor-toPlainText().toUtf8(); #ifdef Q_OS_WIN data.replace(\n, \r\n); // 僅 Windows 下把 LF 轉(zhuǎn)回 CRLF #endif data.prepend(QByteArray::fromHex(efbbbf)); // 寫入 UTF-8 BOM兼容老版 Windows 記事本 file.write(data); file.close(); editor-document()-setModified(false); setWindowModified(false); setWindowTitle(tr(%1 - 記事本).arg(QFileInfo(filePath).fileName())); return true; }參數(shù)說明QIODevice::WriteOnly | QIODevice::Truncate表示只寫并清空原文件缺了 Truncate 時如果新內(nèi)容比原文件短文件末尾會殘留舊數(shù)據(jù)。#ifdef Q_OS_WIN是編譯期判斷在 Windows 上才做\n到\r\n的轉(zhuǎn)換交叉編譯到 Linux 或 macOS 時不會誤轉(zhuǎn)。data.prepend(...)是往字節(jié)數(shù)組頭部插入 BOMEF BB BF。新版 Windows 10/11 記事本已經(jīng)能自動識別無 BOM 的 UTF-8但老版本和部分第三方編輯器不行所以保存時默認帶 BOM 最穩(wěn)。這套默認策略對絕大多數(shù)場景夠用。如果你的工具要給程序員用可以在保存對話框里加一個“編碼”下拉框提供 UTF-8 with BOM、UTF-8 without BOM、GB18030 三個選項然后在 saveFile 里用 QTextCodec 按選擇轉(zhuǎn)碼。簡單記事本不必做這么細但存儲這個設(shè)計點后續(xù)擴展有方向。3.3 文件打開失敗的 4 個邊界只讀、大文件、占用、空文件打開文件失敗不是只有“路徑不存在”一種情況實際使用中更常遇到下面四種每一種的提示方式都不同。場景現(xiàn)象處理方式文件被其他程序占用QFile::open 返回 falseerrorString 是 Permission denied彈窗提示文件正被占用不要直接覆蓋保存文件只讀能打開但保存會失敗打開前用 QFileInfo::isWritable() 檢測彈窗告知以只讀方式打開超大型文件幾十 MB 的 txt 打開時界面卡頓數(shù)秒超過 10MB 時提示用戶并提供分塊讀取或“繼續(xù)打開”選項空文件readAll 返回空字節(jié)編輯器殘留上一次內(nèi)容setPlainText 空字符串即可打開前先確認當前未保存修改只讀檢測可以放在 openFile 前面代碼就一行if (!QFileInfo(filePath).isWritable()) { QMessageBox::information(this, tr(提示), tr(文件為只讀打開后保存可能失敗。)); }這里容易忽略的問題是第一次打開文件成功后用戶沒關(guān)窗口又打開另一個文件前一個文件的未保存內(nèi)容會直接丟掉。正確做法是在 openFile 開始時先判斷editor-document()-isModified()為真就先走保存確認流程再加載新文件。這個邏輯雖然聽起來啰嗦但它是“記事本會不會丟用戶數(shù)據(jù)”的分水嶺建議在寫打開功能時第一時間帶上。4. 查找替換與字數(shù)統(tǒng)計直接把 QTextCursor 用成一套可復(fù)用方法4.1 查找下一個這次與下次的高亮與光標處理查找功能是記事本里復(fù)雜度最高的交互核心是 QTextDocument::find 和 QTextCursor 的配合。容易踩的坑是“連續(xù)點擊查找下一個”時光標停留在匹配文本中間下次查找會原地返回同一個結(jié)果看起來像卡住了。下面是能正確循環(huán)查找的實現(xiàn)。bool MainWindow::findNext(const QString keyword, bool caseSensitive, bool backward) { QTextDocument *doc editor-document(); if (keyword.isEmpty()) return false; QTextCursor cursor editor-textCursor(); QTextDocument::FindFlags flags; if (caseSensitive) flags | QTextDocument::FindCaseSensitively; if (backward) flags | QTextDocument::FindBackward; // 關(guān)鍵處理從選區(qū)末尾開始找避免連續(xù)點擊時卡在同一個匹配上 QTextCursor searchStart cursor; int fromPos backward ? cursor.selectionStart() : cursor.selectionEnd(); searchStart.setPosition(fromPos); QTextCursor found doc-find(keyword, searchStart, flags); if (found.isNull()) { // 找不到時從文檔另一頭再找一次實現(xiàn)循環(huán)查找 QTextCursor restart backward ? QTextCursor(doc-end()) : QTextCursor(doc-begin()); found doc-find(keyword, restart, flags); if (found.isNull()) { statusBar()-showMessage(tr(找不到%1).arg(keyword), 3000); return false; } statusBar()-showMessage(backward ? tr(已循環(huán)到文檔末尾) : tr(已循環(huán)到文檔開頭), 3000); } editor-setTextCursor(found); editor-ensureCursorVisible(); return true; }邏輯說明QTextCursor::setPosition是移動到指定字符位置這里用selectionEnd()作為向前查找起點、selectionStart()作為向后查找起點本質(zhì)是“跳過當前選區(qū)”。如果用戶沒有選區(qū)selectionEnd 和 selectionStart 都是光標當前位置行為正常。doc-find(keyword, searchStart, flags)的重載從 searchStart 位置開始搜索找到后返回一個新的光標指向匹配文本并選中它。循環(huán)查找的 restart 分支用QTextCursor(doc-end())作為向后查找的起點注意這個光標的構(gòu)造方式直接在位置構(gòu)造比doc-end()返回的迭代器再轉(zhuǎn)光標要簡潔。這里還有一個小坑如果 keyword 是空字符串QTextDocument::find 會返回無效光標所以函數(shù)開頭做了 empty 判斷。statusBar 提示不要用tr(找不到%1)的字符串拼接代替argQt 的翻譯機制依賴 arg 方式硬拼接會導(dǎo)致中文環(huán)境下翻譯失效。4.2 全部替換與高亮所有匹配ExtraSelection 的正確用法替換功能通常分兩步先查找目標再點擊替換。批量替換直接遍歷 QTextDocument 最高效。下面是一組“替換一個”和“高亮所有匹配”的代碼。bool MainWindow::replaceOne(const QString findText, const QString replaceText) { QTextCursor cursor editor-textCursor(); if (!cursor.hasSelection() || cursor.selectedText() ! findText) return false; cursor.insertText(replaceText); findNext(findText, caseSensitiveChecked, backwardChecked); return true; } void MainWindow::highlightAll(const QString keyword) { QListQTextEdit::ExtraSelection selections; editor-setExtraSelections(selections); if (keyword.isEmpty()) return; QTextDocument *doc editor-document(); QTextCursor it; int count 0; while ((it doc-find(keyword, it, QTextDocument::FindCaseSensitively)).isNull() false) { if (count 1000) break; // 防止匹配過多導(dǎo)致界面卡頓 QTextEdit::ExtraSelection sel; sel.cursor it; sel.format.setBackground(QColor(#FFF2A8)); sel.format.setForeground(Qt::black); selections.append(sel); } editor-setExtraSelections(selections); }參數(shù)說明doc-find(keyword, it)的第二個參數(shù)是查找起點。第一次傳入默認構(gòu)造的 QTextCursor等價于從文檔開頭找每次匹配后返回的光標已經(jīng)移動到匹配文本后面所以循環(huán)不會無限重復(fù)。QTextEdit::ExtraSelection包含一個 cursor 和一個 format代表“文檔中一塊要被特殊渲染的選區(qū)”。setExtraSelections是一次性替換全部所以每次重新搜索前要先清空上一次的列表否則舊高亮會疊加。這里要特別注意cursor.selectedText() ! findText的比較QTextCursor::selectedText 會把段落分隔符轉(zhuǎn)成 U2029直接和普通字符串比較遇到跨行匹配會不相等。不過記事本的查找串一般不含換行這個判斷夠用。替換后調(diào)用insertText會自動重寫選區(qū)光標保持在插入位置下一步要繼續(xù)查找的話需要像 4.1 那樣從選區(qū)末尾接著搜。4.3 狀態(tài)欄字數(shù)、行數(shù)、行列號統(tǒng)計的顯示策略文本統(tǒng)計是記事本最直觀的反饋。很多實現(xiàn)用editor-toPlainText().length()數(shù)字符這會把段落符也算進去導(dǎo)致行尾多一個字符。正確做法是基于 QTextDocument 的 characterCount。void MainWindow::refreshStatusBar() { QTextDocument *doc editor-document(); int chars doc-characterCount() - 1; // characterCount 包含最后一個隱式段落符 int lines doc-lineCount(); int words countWords(editor-toPlainText()); statusBar()-showMessage(tr(字符%1 字數(shù)%2 行數(shù)%3) .arg(chars).arg(words).arg(lines)); } int MainWindow::countWords(const QString text) { QRegularExpression re([A-Za-z0-9_]|[\\u4e00-\\u9fa5]); QRegularExpressionMatchIterator it re.globalMatch(text); int count 0; while (it.hasNext()) { it.next(); count; } return count; }說明characterCount() - 1是去掉文檔末尾隱藏的段落標記得到真正的字符數(shù)。lineCount 直接讀取文檔結(jié)構(gòu)比text.split(\n).size()更高效尤其在大文件上優(yōu)勢明顯。countWords 用正則把“連續(xù)英文數(shù)字下劃線”算一個詞單個漢字算一個詞這符合中文軟件的常見習慣但不適合統(tǒng)計中文詞組。這個函數(shù)里正則表達式每次調(diào)用都會編譯性能敏感時可以把它定義為靜態(tài)成員變量。refreshStatusBar 掛在編輯器的 textChanged 信號上每次按鍵都會觸發(fā)對于 10MB 級大文件會有輕微開銷真碰到超大文件可以改成 QTimer 300ms 去抖只在用戶停止輸入 300ms 后才刷新。5. Qt 記事本最容易踩的 5 個坑版本混用、平臺插件與閃退排查5.1 fatal: cannot mix incompatible qt library (version ex50601) with this librar這是 Qt 開發(fā)里出現(xiàn)頻率極高的編譯期報錯完整提示是cannot mix incompatible qt library (version ex50601) with this librar。現(xiàn)象是編譯鏈接時報錯甚至可能在運行qmake后就立刻出現(xiàn)。原因基本可以鎖定為“編譯工具鏈看到了兩套 Qt”最常見的情況是系統(tǒng) PATH 里先排到了舊版本的 Qt bin 目錄而 Qt Creator 的 Kit 用的是新版本或者你手動安裝了 Qt 5.6 和 Qt 5.15qmake.exe 被環(huán)境變量指到了舊的那一份。還有一種發(fā)生在庫文件層面鏈接器先找到了 Qt5Core.dll又找到另一個目錄的 Qt5Widgets.dll版本號一個 5.6 一個 5.15于是直接罷工。排查辦法是在命令行里先確認實際生效的 qmakewhere qmake qmake -vWindows 用whereLinux 用which。如果 qmake 的路徑和 Qt Creator Kit 里選的版本對不上那就把環(huán)境變量 PATH 里舊 Qt 的 bin 目錄刪掉。還有一類是“同一個 Qt 安裝目錄下既有 MSVC 構(gòu)建的庫又有 MinGW 構(gòu)建的庫”這種情況最容易發(fā)生在反復(fù)重裝之后。遇到它沒什么優(yōu)雅解法我一般直接卸載 Qt刪除安裝目錄清掉殘留的環(huán)境變量然后重裝一套 5.15 LTS并固定用同一套編譯器。這套操作看起來像玄學但確實比手動改一處漏一處省時間。5.2 qt.qpa.plugin: Could not find the qt platform plugin linuxfb把 Qt 程序部署到樹莓派或 ARM 嵌入式板上運行時終端經(jīng)常會打出qt.qpa.plugin: Could not find the qt platform plugin linuxfb然后程序直接退出。這個報錯的本質(zhì)是 Qt 的 QPA 插件沒加載到。Qt 的 GUI 在 Linux 上依賴平臺插件來對接不同的顯示系統(tǒng)xcb 對應(yīng) X11linuxfb 對應(yīng)對接幀緩沖。運行時 Qt 會去 plugins/platforms 目錄查找插件找不到就報這個錯。解決方法是給程序指定插件路徑和平臺類型export QT_QPA_PLATFORM_PLUGIN_PATH/opt/Qt/5.15.2/plugins/platforms export QT_QPA_PLATFORMlinuxfb ./your_app如果只想在代碼里兜底可以在 main 函數(shù)最前面加qputenv(QT_QPA_PLATFORM_PLUGIN_PATH, /opt/Qt/5.15.2/plugins/platforms);注意 qputenv 必須在 QApplication 構(gòu)造之前執(zhí)行否則插件加載已經(jīng)走完了再設(shè)置就來不及。交叉編譯場景下還要檢查一件事libqlinuxfb.so 依賴的 libQt5Gui、libQt5Core 是否也一起拷到板子上可以用ldd libqlinuxfb.so查看。很多樹莓派部署翻車不是因為路徑?jīng)]寫對而是依賴庫不全導(dǎo)致加載插件時靜默失敗。5.3 Windows 11 打開舊文件中文亂碼編碼探測比事后轉(zhuǎn)碼省事很多人在 Windows 10/11 上用自寫的 Qt 記事本打開以前 Windows 記事本保存的 txt發(fā)現(xiàn)中文全是亂碼。原因很明確Windows 老版本記事本“另存為”時的默認編碼是 ANSI中文環(huán)境下就是 GBK而 Qt 5 內(nèi)部默認按 UTF-8 解碼字符串。高版本 Windows 記事本本身已經(jīng)默認 UTF-8但歷史遺留的老文件編碼不會因此自動升級。解決思路不在事后轉(zhuǎn)碼而是在打開文件時做編碼探測也就是第 3.1 節(jié)那段邏輯BOM 優(yōu)先其次按 UTF-8 嚴格解碼出現(xiàn)替換符再退回 GB18030。很多教程直接教QTextCodec::codecForLocale()這在 Qt 5 的多語言環(huán)境里不可靠codecForLocale 返回的編碼隨系統(tǒng)區(qū)域設(shè)置變化并不是一個穩(wěn)定的“中文編碼”。自己寫探測邏輯反而更可控。保存時默認帶 BOM 也是配合這個策略帶 BOM 的文件再次打開時不需要猜測編碼直接走 UTF-8 分支能在很大程度上降低亂碼概率。5.4 雙擊 exe 崩潰 0xc0000005dll 沒打包全的踩坑記錄Qt 程序在開發(fā)機 Qt Creator 里跑得好好的把 exe 拷到別的機器雙擊后直接閃退Windows 事件日志里記錄異常代碼0xc0000005這是 Access Violation。這個錯誤在 Qt 開發(fā)里的排名極高根源九成是依賴的 Qt 動態(tài)庫沒有部署完整。Qt 的 Release 模式 exe 依賴 Qt5Core.dll、Qt5Gui.dll、Qt5Widgets.dll還依賴 platforms/qwindows.dll缺任何一個都可能閃退。更隱蔽的是把 Debug 版本的 Qt5Cored.dll 當成 Release 庫復(fù)制了過去文件名帶 d 結(jié)尾和 Release exe 一起用就會出問題。解決辦法是使用 Qt 官方提供的部署工具 windeployqt在 Qt 命令行里執(zhí)行windeployqt --release --no-translations your_app.exe它會自動分析 exe 的依賴把需要的 Qt dll 和 platforms 插件復(fù)制到 exe 旁邊。執(zhí)行完后檢查 exe 同目錄下是否有platforms/qwindows.dll和 Qt5Core.dll、Qt5Widgets.dll。最重要的經(jīng)驗是不要從別的機器或別的編譯器環(huán)境手工拷貝 dllMinGW 構(gòu)建的 dll 和 MSVC 構(gòu)建的 dll 混用后續(xù)大概率會引出 5.1 那種版本不兼容報錯。如果程序還依賴第三方庫比如 OpenSSL用 windeployqt 部署后還要再單獨處理。5.5 關(guān)閉前提示保存closeEvent 與 windowModified 的組合記事本最容易流失的數(shù)據(jù)不是文件損壞而是用戶改了一堆內(nèi)容后直接點關(guān)閉按鈕走人。默認情況下 QMainWindow 關(guān)閉不會詢問保存所以必須重寫 closeEvent。void MainWindow::closeEvent(QCloseEvent *event) { if (!editor-document()-isModified()) { event-accept(); return; } QMessageBox::StandardButton ret QMessageBox::question( this, tr(未保存), tr(文件內(nèi)容已修改是否保存), QMessageBox::Save | QMessageBox::Discard | QMessageBox::Cancel); if (ret QMessageBox::Save) { if (saveFile()) { event-accept(); } else { event-ignore(); } } else if (ret QMessageBox::Discard) { event-accept(); } else { event-ignore(); } }邏輯說明editor-document()-isModified()是 Qt 內(nèi)置的文檔修改標記編輯器內(nèi)容一旦變化就自動置真調(diào)用setModified(false)會復(fù)位不需要自己維護 bool 變量。QMessageBox 的三個按鈕對應(yīng)保存、不保存、取消保存失敗時不能關(guān)閉窗口所以調(diào)用event-ignore()用戶選取消同樣必須忽略關(guān)閉事件。這段代碼配合標題欄的setWindowModified使用標題會顯示一個星號讓用戶在視覺上也知道當前處于未保存狀態(tài)。6. 把換行符替換與編碼選擇做成可切換功能跨系統(tǒng)不亂碼的收尾技巧6.1 換行符替換菜單只用一次遍歷完成 CRLF、LF、CR 互相轉(zhuǎn)換不同來源的文本換行符不一致是很多人搜“notepad 換行符替換”的真正需求。Windows 記事本老版本認 CRLFLinux 工具鏈和 Git 默認 LF老 Mac 用 CR。在記事本里做成一個“換行符轉(zhuǎn)換”菜單項只需一個函數(shù)void MainWindow::convertLineEnding(const QString target) { QString text editor-toPlainText(); text.replace(\r\n, \n); // 先把 CRLF 統(tǒng)一成 LF text.replace(\r, \n); // 再處理單獨 CR if (target QLatin1String(CRLF)) text.replace(\n, \r\n); else if (target QLatin1String(CR)) text.replace(\n, \r); editor-setPlainText(text); }參數(shù)說明這個函數(shù)先統(tǒng)一成 LF再按目標格式轉(zhuǎn)換避免\r\n被二次替換。比如直接replace(\r\n, \r)會把一個 CRLF 變成一個單獨的 CR邏輯沒問題如果反過來先替換單獨的\r就會翻車。函數(shù)不做 undo因為它直接操作純文本QPlainTextEdit 的撤銷棧會被清空如果一定要支持撤銷可以改用編輯器提供的 replace 接口或者 QTextCursor 的 beginEditBlock/endEditBlock 包一層。6.2 記錄上次目錄與編碼QSettings 讓記事本記住用戶習慣每次打開文件都從頭翻目錄體驗并不好。QSettings 能記住上次打開的目錄這個細節(jié)能讓工具顯得成熟很多QSettings settings; QString lastDir settings.value(lastOpenDir, QDir::homePath()).toString(); QString path QFileDialog::getOpenFileName( this, tr(打開), lastDir, tr(文本文件 (*.txt);;所有文件 (*))); if (!path.isEmpty()) { settings.setValue(lastOpenDir, QFileInfo(path).absolutePath()); openFile(path); }注意QSettings 默認構(gòu)造要求 QApplication 已經(jīng)設(shè)置了 organizationName 和 applicationName否則會找到無效的存儲位置。第 2.2 節(jié)里 main 函數(shù)那兩行setApplicationName和setOrganizationName在這里才真正發(fā)揮作用。保存路徑也一樣記錄用戶在“打開→修改→保存”之后第二次打開自動停在同一個目錄。這個交互微不足道但實際使用頻率極高屬于典型的低成本高收益功能。6.3 發(fā)布前自測清單用 4 個樣本文件驗證編碼和換行符記事本最怕的問題是小樣本看著正常換一批文件就亂碼。我每次做完這類工具都會準備 4 個測試樣本UTF-8 無 BOM 中文文本、GBK 編碼中文文本可以用 Windows 記事本“另存為 ANSI”生成、CRLF 換行的 Windows 文本、LF 換行的 Linux 文本。驗證順序是用自寫記事本打開第一個文件中文不亂碼且字數(shù)正確打開第二個文件不亂碼打開第三個文件狀態(tài)欄行數(shù)與源文件一致保存后到“記事本”里重新打開顯示正常。如果四個樣本全過就再測一次 10MB 級大文件打開是否卡死以及只讀文件打開時是否給出提示。這一套走完基本可以放心把程序發(fā)給同事用了。我自己的習慣是把“打開前檢測未保存修改”和“關(guān)閉前詢問保存”這兩段邏輯最先寫好因為它們決定工具會不會害人丟數(shù)據(jù)至于界面多漂亮、動畫多流暢反而是最后才考慮的事。文本工具這種日用品穩(wěn)定性永遠排在功能前面。希望這份筆記能幫你在做記事本類 Qt 工具時少走幾個彎路。本文還有配套的精品資源點擊獲取