簡介面向希望基于 WPF 構建類 Word 文本編輯環(huán)境的 .NET 開發(fā)者這套開源富文本編輯器示例提供可直接運行的解決方案與可復用核心組件覆蓋基礎文本編輯、查找替換、HTML 源碼查看、打印、純文本導出、插入圖片和表格等常見能力。壓縮包共 289 個文件約 753KB以 cs 源碼、xaml/baml 界面資源、gif/png 圖片素材和 dll 程序集為主并包含 sln、csproj 等工程配置便于梳理項目結構與依賴關系。已有 2875 人學習或下載。讀者可借助 HtmlEditor.Demo 了解編輯器界面與交互邏輯通過 HtmlEditor 組件研究富文本處理、圖像與表格數(shù)據(jù)的組織方式并在此基礎上擴展格式化選項、文件格式支持或第三方庫集成適合作為 WPF 桌面端文檔編輯功能的學習與二次開發(fā)起點。1. 從「原生控件能不能撐住」說起接到「仿 Word 的 WPF 富文本編輯器」需求時多數(shù)人第一反應是找商業(yè)控件覺得原生RichTextBox太玩具。我一開始也這么判斷直到用原生控件把一份帶編號列表、插圖、行距設置的文檔完整跑通才發(fā)現(xiàn)瓶頸從來不在控件本身而在于有沒有把FlowDocument這套文檔模型吃透。這份開源 demo 做的事情很樸素用 WPF 原生控件搭出一個能加粗、能調(diào)字號、能插圖片、能存 RTF 的編輯區(qū)工具欄和編輯區(qū)之間靠路由命令解耦沒有任何第三方依賴。它適合兩類人一類是想給桌面端產(chǎn)品加個簡易排版能力、又不想背商業(yè)授權包袱的開發(fā)者另一類是剛上手 WPF、想找一個完整例子把依賴屬性、命令綁定、文檔序列化串起來的新手。它不打算替代 Word它想做到的是把「編輯器」這件事拆到你能自己動手改的程度。2. 技術選型與工程結構原生控件撐起仿 Word 的殼2.1 RichTextBox 與第三方控件的取舍WPF 里做富文本可選路線其實只有三條原生RichTextBox加FlowDocument、嵌WebView2跑一段前端編輯器、買商業(yè)控件。三條路的差別不在功能多少而在你后續(xù)要付出什么代價。原生路線的能力邊界很清晰。FlowDocument是一棵可序列化的文檔樹段落、行內(nèi)元素、列表、表格都是強類型對象你能直接用 LINQ 遍歷、直接改屬性、直接掛事件。TextRange提供了對任意選區(qū)做屬性讀寫的能力EditingCommands自帶加粗、斜體、下劃線、項目符號、編號、縮進、對齊這一整套命令連撤銷棧都是控件內(nèi)置的。對一個「仿 Word 的 demo」來說這套東西的完成度已經(jīng)超出預期。它的短板同樣明顯。表格編輯能力弱合并單元格、跨頁表格基本要自己寫圖片只能靠InlineUIContainer塞進去排版控制粒度粗沒有分頁視圖長文檔滾動時是一次性布局幾萬字以上會明顯卡RTF 導出對圖片和復雜樣式的保真度有限。這些是原生控件的天花板選它之前得認。第三方控件的優(yōu)勢是這些坑別人已經(jīng)踩完了表格、分頁、頁眉頁腳、PDF 導出都是現(xiàn)成的。代價是授權費用、包體積以及最要命的一點——出問題時你只能提工單看不到源碼排查起來像個黑匣子。WebView2那條路則是把編輯能力交給前端生態(tài)功能上限最高但 WPF 側(cè)和 JS 側(cè)要維護一套消息協(xié)議文檔模型存在兩份序列化、撤銷、光標狀態(tài)同步都是長期成本。我一般的判斷標準是如果產(chǎn)品只需要「帶格式的文本 少量圖片 導出」原生控件完全夠用改起來也最自由如果文檔里表格占比超過三成或者需要嚴格的打印分頁趁早換路線別硬扛。這份 demo 走的是第一條路它的價值不在于功能齊全而在于每一個功能都攤開在你眼前沒有黑盒。2.2 目錄結構與三層分層工程結構上這類項目最常見的做法是按職責切成四塊應用層放窗口和啟動邏輯控件層放編輯區(qū)和工具欄這兩個UserControl核心層放命令定義、文檔讀寫、剪貼板清洗這些純邏輯樣式層單獨出一個資源字典項目方便換膚。這么切的好處是核心層不引用任何Window將來搬到別的宿主里比如嵌進插件不用改代碼。WpfRichEditor/ ├── WpfRichEditor.sln ├── src/ │ ├── WpfRichEditor.App/ # 啟動與主窗口 │ │ ├── App.xaml │ │ ├── MainWindow.xaml │ │ └── MainWindow.xaml.cs │ ├── WpfRichEditor.Controls/ # 可復用控件 │ │ ├── RichEditor.xaml # 編輯區(qū) UserControl │ │ ├── RichEditor.xaml.cs │ │ ├── EditorToolbar.xaml # 頂部工具欄 │ │ └── EditorToolbar.xaml.cs │ ├── WpfRichEditor.Core/ # 無 UI 依賴的邏輯 │ │ ├── Commands/EditorCommands.cs # 自定義 RoutedCommand │ │ ├── Documents/DocumentIO.cs # RTF / XAML 存取 │ │ └── Services/ClipboardSanitizer.cs │ └── WpfRichEditor.Themes/ # 資源字典 │ └── EditorStyles.xaml └── tests/ └── WpfRichEditor.Tests/RichEditor這個UserControl內(nèi)部只放一個RichTextBox對外暴露Document依賴屬性和幾個方法應用樣式、加載、保存工具欄不直接持有RichTextBox引用而是通過CommandTarget找目標。這條約束很關鍵它決定了后面加第二個編輯區(qū)時你要不要重寫工具欄。2.3 環(huán)境準備與第一次運行項目是標準的 WPF 工程目標框架寫net8.0-windows老一點的項目可能是net6.0-windows或net48關鍵是UseWPF必須為true否則 XAML 編譯器不會介入InitializeComponent直接找不到。!-- WpfRichEditor.Controls.csproj -- Project SdkMicrosoft.NET.Sdk PropertyGroup !-- WPF 必須鎖 windows 目標框架跨平臺 SDK 風格項目里這是硬性條件 -- TargetFrameworknet8.0-windows/TargetFramework UseWPFtrue/UseWPF Nullableenable/Nullable LangVersionlatest/LangVersion /PropertyGroup /Project命令行驗證比開 Visual Studio 快先確認 SDK 裝沒裝對再編譯運行# 確認本機有 8.0 或 6.0 的 SDK dotnet --list-sdks # 還原 編譯整個解決方案 dotnet build WpfRichEditor.sln -c Debug # 直接跑主程序不用開 IDE dotnet run --project src/WpfRichEditor.App/WpfRichEditor.App.csproj三個命令里最容易出問題的是第一條。如果dotnet --list-sdks只列出 6.0 而項目寫的是net8.0-windows編譯會報NETSDK1045提示當前 SDK 不支持目標框架反過來項目是net48的話就必須用 Visual Studio 的 MSBuilddotnet build會因為找不到Microsoft.NETFramework.ReferenceAssemblies失敗。這兩種報錯信息都很直白照著改目標框架或者補裝 SDK 即可不算坑。跑起來之后你會看到一個典型的工具欄加編輯區(qū)布局。工具欄從上到下依次是字體、字號、加粗斜體下劃線、字體顏色、對齊方式、列表、插入圖片、保存和打開。每一項都能點點到?jīng)]選區(qū)的狀態(tài)時按鈕會變灰——這個灰不是寫死的是命令的CanExecute在起作用第 4 章會講清楚它是怎么聯(lián)動起來的。3. 文檔模型拆解FlowDocument 樹、TextRange 與樣式落盤3.1 Block 與 Inline 樹的結構想改這個編輯器第一件事是把FlowDocument的樹結構在腦子里建起來。它只有兩層節(jié)點類型Block是塊級元素獨占一行Inline是行內(nèi)元素可以并排。FlowDocument.Blocks是整篇文檔的根集合里面裝Paragraph段落、Section分組、List列表、Table表格、BlockUIContainer塞任意控件。Paragraph.Inlines里裝Run一段同格式文本、Span可嵌套的容器、Bold/Italic/Underline語義化行內(nèi)元素、Hyperlink、InlineUIContainer塞圖片或任意 UI 元素、LineBreak。理解這層結構之后很多「為什么改不動」的問題就自解了。比如用戶選中一段文字點加粗實際發(fā)生的是TextRange把選區(qū)拆成若干Run把FontWeight屬性ApplyPropertyValue到每個Run上Bold元素只是FontWeightBold的語法糖。再比如你想給整篇文檔統(tǒng)一行距操作對象是Paragraph而不是Run因為行距是塊級屬性。遍歷這棵樹最常用的寫法是遞歸比如統(tǒng)計段落數(shù)、批量改對齊、導出純文本都會用到// 遞歸展開所有塊級容器只挑出 Paragraph private static IEnumerableParagraph WalkParagraphs(BlockCollection blocks) { foreach (var block in blocks) { switch (block) { case Paragraph p: yield return p; break; case Section section: // Section 是一層分組容器里面還能再套 Block foreach (var child in WalkParagraphs(section.Blocks)) yield return child; break; case List list: // 列表項的正文在 ListItem.Blocks 里注意別漏 foreach (var item in list.ListItems) foreach (var child in WalkParagraphs(item.Blocks)) yield return child; break; case Table table: foreach (var row in table.RowGroups.SelectMany(g g.Rows)) foreach (var cell in row.Cells) foreach (var child in WalkParagraphs(cell.Blocks)) yield return child; break; } } }這段代碼的關鍵在于「容器要展開葉子要產(chǎn)出」。Section、List、Table都是容器自身不承載文本必須繼續(xù)往下走Paragraph是葉子產(chǎn)出后不再遞歸。實際項目里我見過有人只遍歷Document.Blocks一層結果列表和表格里的段落全部漏掉導出純文本時內(nèi)容缺一半排查半天才發(fā)現(xiàn)是遍歷深度的問題。這個方法后續(xù)會被文檔大綱、查找替換、全文統(tǒng)計反復復用值得單獨抽成一個靜態(tài)工具類。3.2 選中文本改樣式ApplyPropertyValue 的完整鏈路工具欄上每個格式按鈕最終都落到同一個方法上TextRange.ApplyPropertyValue。它接收一個依賴屬性和一個值把屬性寫進選區(qū)覆蓋的所有TextElement。字體、字號、前景色、背景色、加粗、斜體、下劃線全走這條鏈路區(qū)別只是屬性名不同。// 統(tǒng)一的樣式應用入口工具欄所有格式按鈕都調(diào)它 private void ApplyToSelection(DependencyProperty property, object value) { var selection _editor.Selection; // 空選區(qū)時沒有可寫的 TextElement直接寫會靜默失敗 // 這里的處理是把值暫存等用戶真正輸入時再補避免「點了沒反應」的錯覺 if (selection.IsEmpty) { _pendingStyle (property, value); return; } // 整段操作包在 BeginChange/EndChange 里撤銷棧只留一個記錄點 _editor.BeginChange(); try { selection.ApplyPropertyValue(property, value); } finally { _editor.EndChange(); } // 焦點必須還給編輯區(qū)否則用戶按方向鍵發(fā)現(xiàn)光標不在文檔里 _editor.Focus(); } // 三個高頻調(diào)用的封裝 public void ToggleBold() ApplyToSelection(TextElement.FontWeightProperty, _editor.Selection.GetPropertyValue(TextElement.FontWeightProperty) is FontWeight w w FontWeights.Bold ? FontWeights.Normal : FontWeights.Bold); public void SetFontSize(double size) ApplyToSelection(TextElement.FontSizeProperty, size); public void SetForeground(Brush brush) ApplyToSelection(TextElement.ForegroundProperty, brush);逐段說清楚。_editor.Selection返回的是TextSelection它繼承自TextRange所以ApplyPropertyValue和GetPropertyValue都能直接用。加粗的切換邏輯先用GetPropertyValue讀回當前值再取反這是「按鈕狀態(tài)跟隨光標」的基礎——注意讀回的值可能是DependencyProperty.UnsetValue表示選區(qū)里格式不統(tǒng)一這時候按「未加粗」處理比較符合直覺。BeginChange/EndChange這一對很容易被忽略但它直接決定用戶體驗。不加的話一次「給整段設置字號」會在撤銷棧里留下幾十條記錄用戶按一次 CtrlZ 只回退一點點得連按十幾下才能回到原樣這屬于典型的「后悔藥不夠吃」。包起來之后整批操作合并成一個撤銷單元一次 CtrlZ 全部回退。最后那句_editor.Focus()是血淚經(jīng)驗。工具欄是獨立控件點按鈕時焦點會跑到按鈕上選區(qū)在視覺上還在但TextSelection的錨點可能已經(jīng)失效用戶接著敲字會插到奇怪的位置。所有修改文檔的命令執(zhí)行完都要把焦點還給編輯區(qū)。3.3 段落級排版對齊、行距、縮進與列表行內(nèi)屬性管字符段落屬性管整塊。對齊、行距、首行縮進、段前段后距這些屬性的宿主是Paragraph不是Run。所以設置方式有兩種選區(qū)跨段落時用ApplyPropertyValue屬性寫Paragraph.TextAlignmentProperty只處理光標所在段落時直接拿CaretPosition.Paragraph改。// 段落對齊選區(qū)覆蓋多個段落時每個 Paragraph 都會被寫一遍 public void SetAlignment(TextAlignment alignment) ApplyToSelection(Paragraph.TextAlignmentProperty, alignment); // 行距必須成對設置只改 LineHeight 不生效 public void SetLineHeight(double height) { var paragraph _editor.CaretPosition.Paragraph; if (paragraph is null) return; paragraph.LineHeight height; // 單位是 DIP24 約等于 18pt paragraph.LineStackingStrategy LineStackingStrategy.BlockLineHeight; // 按固定值堆疊 } // 首行縮進負值表示懸掛縮進 public void SetFirstLineIndent(double indent) ApplyToSelection(Paragraph.TextIndentProperty, indent);LineHeight的單位是設備無關像素DIP1 DIP 等于 1/96 英寸所以 24 大約是 18 磅中文正文常用 24 到 30 之間。真正需要注意的是LineStackingStrategy默認值是MaxHeight意思是行高取該行內(nèi)所有元素的最大高度此時LineHeight基本不起作用必須改成BlockLineHeight才會按你設的固定值算。這個屬性組合是個經(jīng)典陷阱不少人改完行距發(fā)現(xiàn)沒反應懷疑控件有 bug其實就差這一行。列表用的是內(nèi)置命令不用自己拼List對象// 項目符號和編號都由 EditingCommands 提供內(nèi)部會處理 List 容器的創(chuàng)建與拆分 public void ToggleBullets() EditingCommands.ToggleBullets.Execute(null, _editor); public void ToggleNumbering() EditingCommands.ToggleNumbering.Execute(null, _editor); // 增加/減少縮進同理 public void IncreaseIndent() EditingCommands.IncreaseIndentation.Execute(null, _editor);這幾個命令的第二個參數(shù)必須是RichTextBox本身傳null或者傳Window都會拋InvalidOperationException因為命令內(nèi)部要靠它拿Document和Selection。這是新手最常撞的一堵墻報錯信息只說「命令目標無效」不會告訴你要傳誰。3.4 RTF 與 XAML兩條存取路線的差別保存和打開是這類 demo 的必備功能WPF 提供了一條極簡的路徑TextRange.Save和TextRange.Load靠DataFormats決定序列化格式。整個實現(xiàn)不超過二十行。public static class DocumentIO { // 保存為 RTF兼容 Word / WPS但圖片和復雜樣式會丟 public static void SaveRtf(FlowDocument document, string path) { var range new TextRange(document.ContentStart, document.ContentEnd); using var stream File.Create(path); range.Save(stream, DataFormats.Rtf); } // 保存為 XAML 包圖片以資源形式打進 zip保真度最高 public static void SaveXamlPackage(FlowDocument document, string path) { var range new TextRange(document.ContentStart, document.ContentEnd); using var stream File.Create(path); range.Save(stream, DataFormats.XamlPackage); } // 加載時復用已有文檔實例不要 new 一個 FlowDocument 再賦值 public static void Load(FlowDocument document, string path) { var range new TextRange(document.ContentStart, document.ContentEnd); using var stream File.OpenRead(path); var format Path.GetExtension(path).ToLowerInvariant() switch { .rtf DataFormats.Rtf, .xaml DataFormats.XamlPackage, _ DataFormats.Text }; range.Load(stream, format); } }四種格式的取舍用一張表說清楚更省事格式常量是否帶圖片能否被 Word 打開體積適用場景RTFDataFormats.Rtf部分支持保真度低是中交付給外部、需要跨軟件打開XAMLDataFormats.Xaml否圖片直接丟否小內(nèi)部調(diào)試、看文檔結構XAML 包DataFormats.XamlPackage是圖片打進 zip否大本地存檔、二次加載純文本DataFormats.Text否是最小導出、復制到別處Save的第一個參數(shù)是Stream而不是路徑這個設計是有意的它內(nèi)部按字節(jié)寫不經(jīng)過字符串編碼轉(zhuǎn)換所以不會出現(xiàn)中文亂碼。反過來說如果你圖省事用StreamWriter包一層再傳進去中文必然亂碼因為 RTF 里的中文是\uNNNN轉(zhuǎn)義序列被編碼轉(zhuǎn)換一次就廢了。這一點在第 5 章還會展開。Load那段代碼里有一句注釋值得再強調(diào)一遍復用已有的FlowDocument實例。很多人寫_editor.Document new FlowDocument()再往里灌內(nèi)容看起來也能跑但撤銷棧會被整個重置用戶打開文件后按 CtrlZ 什么都不會發(fā)生。原因在第 5 章細說。4. 工具欄與命令層按鈕怎么真正驅(qū)動編輯區(qū)4.1 EditingCommands 直接綁定WPF 的命令系統(tǒng)是這套編輯器的骨架。加粗、斜體、下劃線、左對齊、居中、右對齊、兩端對齊、項目符號、編號、增加縮進、減少縮進、剪切、復制、粘貼、撤銷、重做——這些全都在EditingCommands和ApplicationCommands里預置好了工具欄按鈕只需要一行 XAML 就能接上。ToolBarTray DockPanel.DockTop ToolBar !-- CommandTarget 必須指向 RichTextBox否則命令找不到執(zhí)行目標按鈕全程灰 -- Button CommandEditingCommands.ToggleBold CommandTarget{Binding ElementNameEditor} ToolTip加粗 (CtrlB) TextBlock TextB FontWeightBold/ /Button Button CommandEditingCommands.ToggleItalic CommandTarget{Binding ElementNameEditor} TextBlock TextI FontStyleItalic/ /Button Button CommandEditingCommands.ToggleUnderline CommandTarget{Binding ElementNameEditor} TextBlock TextU TextDecorationsUnderline/ /Button Separator/ Button CommandEditingCommands.AlignLeft CommandTarget{Binding ElementNameEditor} Content左對齊/ Button CommandEditingCommands.AlignCenter CommandTarget{Binding ElementNameEditor} Content居中/ Button CommandEditingCommands.AlignJustify CommandTarget{Binding ElementNameEditor} Content兩端/ /ToolBar /ToolBarTrayCommandTarget是這段 XAML 的靈魂。WPF 的路由命令會從焦點元素開始往上冒泡找CommandBinding如果工具欄按鈕和編輯區(qū)不在同一條視覺樹路徑上或者焦點根本不在編輯區(qū)命令就找不到目標CanExecute返回false按鈕變灰。顯式寫CommandTarget等于告訴命令「去這個控件上執(zhí)行」繞開了焦點依賴。這套寫法的好處是零代碼。加粗、斜體、對齊、縮進、剪切粘貼、撤銷重做一行 XAML 頂幾十行事件處理。而且CanExecute是自動的光標在普通段落里ToggleBullets可用光標已經(jīng)在列表項里DecreaseIndentation才可用選區(qū)為空時Cut自動變灰。這些狀態(tài)全由控件內(nèi)部維護你不需要寫一行判斷邏輯。4.2 自定義 RoutedCommand 支撐字號、字體、顏色內(nèi)置命令覆蓋不到的地方就得自己定義。字號下拉框、字體下拉框、字體顏色選擇器這三個是剛需EditingCommands里沒有對應的命令得走自定義RoutedUICommand加CommandBinding的路子。// 自定義命令集中放一個靜態(tài)類方便 XAML 里用 x:Static 引用 public static class EditorCommands { public static readonly RoutedUICommand ApplyFontSize new RoutedUICommand(應用字號, nameof(ApplyFontSize), typeof(EditorCommands)); public static readonly RoutedUICommand ApplyFontFamily new RoutedUICommand(應用字體, nameof(ApplyFontFamily), typeof(EditorCommands)); public static readonly RoutedUICommand ApplyForeground new RoutedUICommand(應用字體顏色, nameof(ApplyForeground), typeof(EditorCommands)); public static readonly RoutedUICommand InsertImage new RoutedUICommand(插入圖片, nameof(InsertImage), typeof(EditorCommands), new InputGestureCollection { new KeyGesture(Key.I, ModifierKeys.Control | ModifierKeys.Shift) }); }命令定義好之后要在編輯區(qū)上掛CommandBindingExecuted負責干活CanExecute負責灰不灰RichTextBox x:NameEditor ... RichTextBox.CommandBindings CommandBinding Command{x:Static core:EditorCommands.ApplyFontSize} ExecutedOnApplyFontSize/ CommandBinding Command{x:Static core:EditorCommands.InsertImage} ExecutedOnInsertImage/ /RichTextBox.CommandBindings /RichTextBoxprivate void OnApplyFontSize(object sender, ExecutedRoutedEventArgs e) { // 參數(shù)從工具欄傳進來命令本身不關心 UI 長什么樣 if (e.Parameter is not double size || size 0) return; ApplyToSelection(TextElement.FontSizeProperty, size); } private void OnInsertImage(object sender, ExecutedRoutedEventArgs e) { var dialog new OpenFileDialog { Filter 圖片文件|*.png;*.jpg;*.jpeg;*.bmp, Multiselect false }; if (dialog.ShowDialog() ! true) return; var bitmap new BitmapImage(new Uri(dialog.FileName)); // 圖片必須包在 InlineUIContainer 里才能進入 FlowDocument 的行內(nèi)流 var image new Image { Source bitmap, Stretch Stretch.Uniform }; var container new InlineUIContainer(image, _editor.CaretPosition); container.BaselineAlignment BaselineAlignment.Center; _editor.CaretPosition container.ElementEnd; _editor.Focus(); }ExecutedRoutedEventArgs.Parameter這個口子很實用它讓同一個命令能接不同來源的參數(shù)字號下拉框傳double字體下拉框傳FontFamily顏色選擇器傳Brush。工具欄側(cè)只需要CommandParameter{Binding SelectedItem, ElementNameFontSizeBox}就接上了命令實現(xiàn)里做一次類型判斷即可。InlineUIContainer那段有個細節(jié)構造時傳CaretPosition會直接把圖片插到光標處不需要先操作Inlines.Add再調(diào)整位置。插入完把光標挪到container.ElementEnd用戶接著敲字就會在圖片后面而不是跑到圖片前面去。這是插入圖片最容易翻車的地方光標位置不對用戶體感就是「圖片插進去了但打字跑到奇怪的地方」。4.3 撤銷重做與命令可用狀態(tài)聯(lián)動RichTextBox自帶撤銷棧IsUndoEnabled默認是trueUndoLimit默認值是-1不限制實際項目里建議改成一個有限值比如 100否則長時間編輯超大文檔內(nèi)存會一路漲。撤銷棧的粒度由BeginChange/EndChange控制這對方法在第 3 章已經(jīng)用過這里補充幾個容易踩的點。// 撤銷重做直接轉(zhuǎn)發(fā)給控件不要自己維護棧 private void OnUndo(object sender, ExecutedRoutedEventArgs e) _editor.Undo(); private void OnRedo(object sender, ExecutedRoutedEventArgs e) _editor.Redo(); // 工具欄按鈕的可用狀態(tài)跟著控件的 CanUndo / CanRedo 走 private void RefreshUndoState() { BtnUndo.IsEnabled _editor.CanUndo; BtnRedo.IsEnabled _editor.CanRedo; }第一不要在BeginChange和EndChange之間再嵌套一對。WPF 支持嵌套但嵌套層數(shù)越多撤銷粒度越粗最后可能出現(xiàn)「改十個段落只留一個撤銷點」的情況用戶想單獨回退某一處就做不到了。批量操作包一層就夠。第二任何繞過TextRange直接改文檔對象的操作撤銷棧都記不住。比如遍歷所有Paragraph直接改TextAlignment控件不知道你改了CtrlZ 無法回退。要讓它可撤銷得把這段修改包在_editor.BeginChange()里要讓它不可撤銷比如加載文檔時批量規(guī)整格式就在加載前把IsUndoEnabled設為false加載完再打開順手_editor.Document保持不變。第三命令的可用狀態(tài)是自動的但工具欄如果是自繪按鈕而不是Button加Command綁定就要手動在SelectionChanged、TextChanged、CaretPosition變化時刷新?；煊脙煞N方式是最容易出 bug 的寫法一半按鈕自動灰一半按鈕永遠可點測試提的 bug 單上就寫「格式按鈕狀態(tài)混亂」。我一般統(tǒng)一走Command綁定實在需要自繪的地方才手動同步盡量減少狀態(tài)源。5. 避坑與排查五條踩出來的記錄5.1 從 Word 粘貼后整篇樣式崩掉現(xiàn)象用戶從 Word 復制一段帶樣式的文字粘進來編輯區(qū)里原本設置好的字號、字體、行距全部被覆蓋有時候還會冒出奇怪的頁邊距撤銷也回不到粘貼前的狀態(tài)。原因剪貼板里同時存在DataFormats.Rtf、DataFormats.Xaml、DataFormats.UnicodeText等多種格式RichTextBox默認會優(yōu)先挑格式最豐富的那種把外來 RTF 里的一堆樣式表和文檔級屬性一并吞進來。Word 導出的 RTF 帶著它自己的樣式定義進來之后和當前文檔的屬性打架誰后寫誰贏。解決攔截DataObject.Pasting事件在粘貼真正發(fā)生前把數(shù)據(jù)對象換掉只保留純文本或者只保留最基礎的格式。// 在編輯區(qū)的構造函數(shù)里掛一次 _editor.AddHandler(DataObject.PastingEvent, new DataObjectPastingEventHandler(OnPasting)); private void OnPasting(object sender, DataObjectPastingEventArgs e) { // 只接受純文本把外來的 RTF / XAML 全部丟掉 if (e.SourceDataObject.GetDataPresent(DataFormats.UnicodeText, true)) { var text (string)e.SourceDataObject.GetData(DataFormats.UnicodeText); e.DataObject new DataObject(DataFormats.UnicodeText, text); return; } // 連純文本都沒有直接取消這次粘貼 e.CancelCommand(); }如果想保留一部分格式就不要整體替換數(shù)據(jù)對象而是把 RTF 取出來做一次清洗去掉\paperw、\stylesheet這類文檔級控制字再用TextRange.Load手動插到光標處。這條路更細但代碼量翻好幾倍demo 階段用純文本方案完全夠。5.2 長文檔輸入明顯卡頓現(xiàn)象文檔寫到一兩萬字、段落數(shù)上千之后每次敲鍵都有幾百毫秒延遲滾動也發(fā)澀任務管理器里進程內(nèi)存一路漲。原因FlowDocument是流式布局沒有虛擬化任何一次內(nèi)容變更都會觸發(fā)受影響范圍內(nèi)重新測量和排版。如果RichTextBox被放在ScrollViewer里外層滾動容器給它的可用高度是無限大它會嘗試一次性布局整篇文檔性能直接崩。另一種常見情況是PageWidth沒設文檔寬度跟著宿主走窗口一拉寬所有段落重新折行。解決把RichTextBox從外層ScrollViewer里拿出來用自身的VerticalScrollBarVisibilityAuto給FlowDocument設一個固定的PageWidth和PagePadding讓折行結果穩(wěn)定段落數(shù)特別多時按章節(jié)拆文檔或者加一個「只渲染當前可見頁」的分頁視圖。這三條里第一條見效最快也最容易被忽略。!-- 錯誤寫法外層套 ScrollViewer編輯區(qū)高度無限布局全量跑 -- ScrollViewer RichTextBox x:NameEditor/ /ScrollViewer !-- 正確寫法讓編輯區(qū)自己管滾動文檔寬度固定 -- RichTextBox x:NameEditor VerticalScrollBarVisibilityAuto HorizontalScrollBarVisibilityDisabled FlowDocument PageWidth794 PagePadding72,56,72,56 Paragraph/ /FlowDocument /RichTextBoxPageWidth794對應 A4 紙在 96 DPI 下的寬度左右邊距 72 DIP 約等于 0.75 英寸這套數(shù)值和 Word 的默認版心基本對齊視覺上比較自然。5.3 打開文檔后撤銷鍵失效現(xiàn)象程序啟動后編輯幾下CtrlZ 正常點「打開」加載一個文件之后再編輯CtrlZ 就不動了撤銷按鈕也一直是灰的。原因加載時寫了_editor.Document new FlowDocument()把整個文檔對象換掉了。撤銷棧是掛在RichTextBox上、跟著Document實例走的文檔一換棧直接清空并重置舊內(nèi)容的歷史記錄全部丟失。解決復用同一個FlowDocument實例用TextRange覆蓋它的內(nèi)容如果確實需要重置撤銷棧比如加載后不希望用戶撤銷回上一個文件顯式在加載前后切IsUndoEnabled讓行為可控。private void OpenDocument(string path) { // 加載期間關掉撤銷避免「加載」本身變成一條可撤銷記錄 _editor.IsUndoEnabled false; try { DocumentIO.Load(_editor.Document, path); // 復用實例不清空棧引用 } finally { _editor.IsUndoEnabled true; _editor.CaretPosition _editor.Document.ContentStart; _editor.Focus(); } }5.4 中文輸入法期間選區(qū)丟失、字符順序錯亂現(xiàn)象用拼音輸入法打字時如果中途點了工具欄的加粗或者字號候選框會消失已經(jīng)輸入的拼音被打斷有時候字符還會插到光標前面去。原因輸入法組合字符串composition string還沒上屏時TextSelection處于一種中間狀態(tài)此時調(diào)用ApplyPropertyValue或讓編輯區(qū)失焦會強行結束組合導致輸入法緩沖區(qū)的內(nèi)容丟失或錯位。工具欄按鈕點擊本身也會讓RichTextBox失焦而 IME 對失焦非常敏感。解決在工具欄按鈕的命令執(zhí)行前判斷輸入法狀態(tài)組合期間直接拒絕執(zhí)行或者不判斷但保證命令執(zhí)行完立刻把焦點還回來讓 IME 有機會恢復。private void OnApplyFontSize(object sender, ExecutedRoutedEventArgs e) { // 輸入法正在組合時不要動文檔否則拼音會被打斷 if (InputMethod.Current.ImeState InputMethodState.On InputMethod.Current.ImeConversionMode.HasFlag(ImeConversionModeValues.Native)) { // 這里選擇直接返回也可以給個提示讓用戶先上屏 return; } if (e.Parameter is not double size) return; ApplyToSelection(TextElement.FontSizeProperty, size); }更穩(wěn)妥的做法是在工具欄的PreviewMouseDown里做判斷并e.Handled true從源頭阻止焦點轉(zhuǎn)移。這類問題在測試階段很容易漏因為測試同學多用英文輸入上線后中文用戶一多就集中爆發(fā)。5.5 導出 RTF 后中文亂碼、圖片消失現(xiàn)象存成.rtf用 Word 打開中文全變成問號或者方塊帶圖片的文檔打開后圖片位置是空白有時文件能打開但格式全亂。原因中文亂碼十有八九是中間經(jīng)過了一次字符編碼轉(zhuǎn)換。TextRange.Save應該直接接收FileStream如果為了「保險」先Save到MemoryStream再用StreamReader讀成字符串寫文件RTF 里的\uNNNN轉(zhuǎn)義就被破壞掉了。圖片消失則是 RTF 格式本身的限制WPF 的 RTF 序列化對InlineUIContainer里的圖片支持很弱很多情況下直接跳過。解決中文問題保證Save的Stream是從文件直接打開的中間不做任何字符串轉(zhuǎn)換圖片問題改存DataFormats.XamlPackage它是 zip 包圖片作為資源打進去加載時能完整還原。必須交付 RTF 的話就把圖片單獨導出成文件正文里留占位符接收方自己插圖——聽起來笨但比導出一個「圖片全丟」的 RTF 更可靠。// 正確流直接來自文件不經(jīng)過任何編碼轉(zhuǎn)換 using (var stream File.Create(path)) { range.Save(stream, DataFormats.Rtf); } // 錯誤示范中間轉(zhuǎn)了一次字符串中文必亂 using var memory new MemoryStream(); range.Save(memory, DataFormats.Rtf); var content Encoding.UTF8.GetString(memory.ToArray()); // 這里就毀了 File.WriteAllText(path, content);6. 二次開發(fā)把 demo 改成能用的編輯器拿到這份代碼之后最值得先做的一件事是把編輯區(qū)徹底組件化。demo 里RichEditor已經(jīng)把RichTextBox包了一層但對外暴露的還是控件本身宿主窗口可以直接摸到Editor.Document。我一般會再收一層對外只留Document依賴屬性、LoadAsync、SaveAsync和幾個格式操作方法內(nèi)部RichTextBox標成internal。這樣將來加第二個編輯區(qū)比如批注面板、對比視圖時工具欄的CommandTarget只要換綁定源邏輯一行不用改。第二個改造點是樣式預設?，F(xiàn)在工具欄是「點一下改一下」的即時模式用戶想統(tǒng)一全文格式得全選再點。加一套ResourceDictionary里的段落樣式標題一、標題二、正文、引用用Style加BasedOn定義字號、行距、段前段后距工具欄改成下拉選擇選中后對光標所在段落paragraph.Style ...。FlowDocument對Style的支持是完整的這套改造成本很低但對「像 Word」這件事的提升立竿見影。第三個是查找替換。FlowDocument沒有內(nèi)置查找得自己遍歷Run用TextRange定位再高亮。核心思路是從Document.ContentStart開始用GetTextInRun逐個取文本塊命中后new TextRange(start, end).ApplyPropertyValue(TextElement.BackgroundProperty, highlightBrush)。要注意跨Run的匹配比如「富文本」三個字被加粗拆成兩段穩(wěn)妥的做法是先拼全文再算偏移然后用GetPositionAtOffset反查這條路徑慢但準幾千字的文檔完全夠用。最容易被低估的改造點是文檔大綱。FlowDocument沒有「標題」概念得靠Paragraph.Style或者自定義附加屬性標記段落級別然后遍歷一遍生成樹。這一步做完左側(cè)掛一個TreeView點擊節(jié)點滾到對應段落paragraph.BringIntoView()整個編輯器的體感就從「能打字的框」變成了「能寫文章的軟件」。驗證這塊我給個實用建議編輯器這類控件不要只靠手點?？梢栽跍y試項目里起一個 STA 線程創(chuàng)建RichTextBox加載一段構造好的 RTF跑一遍格式應用再斷言GetPropertyValue的返回值。WPF 控件必須在 STA 線程上創(chuàng)建測試框架默認是 MTA忘了加[STAThread]或者線程 ApartmentState 設置測試會直接拋InvalidOperationException報錯信息還不明顯。// 測試里創(chuàng)建 WPF 控件的標準姿勢 [Fact] public void ApplyBold_ShouldChangeFontWeight() { Exception? captured null; var thread new Thread(() { try { var editor new RichTextBox(); editor.Document.Blocks.Add(new Paragraph(new Run(測試文本))); // 全選后應用加粗再讀回驗證 editor.Selection.Select(editor.Document.ContentStart, editor.Document.ContentEnd); editor.Selection.ApplyPropertyValue(TextElement.FontWeightProperty, FontWeights.Bold); var weight editor.Selection.GetPropertyValue(TextElement.FontWeightProperty); Assert.Equal(FontWeights.Bold, weight); } catch (Exception ex) { captured ex; } }); thread.SetApartmentState(ApartmentState.STA); thread.Start(); thread.Join(); if (captured is not null) throw captured; }最后說個心態(tài)上的事。這個 demo 最容易讓人上頭的地方是它讓你覺得「再補幾個功能就能上線」——表格、分頁、頁眉頁腳、PDF 導出每一項看起來都不難。我從那以后每次接編輯器需求都先把「文檔模型」和「視圖」的邊界畫一遍再動手哪些數(shù)據(jù)必須進FlowDocument哪些只存在于宿主序列化時怎么保證兩邊對得上。邊界畫不清楚功能補得越多后面重構越疼。希望幫到你。本文還有配套的精品資源點擊獲取