簡(jiǎn)介面向WPF桌面應(yīng)用開發(fā)者的仿Word富文本編輯器開源示例適合希望在自己項(xiàng)目中實(shí)現(xiàn)格式化文本編輯、圖文混排與表格處理的中級(jí)開發(fā)者參考。項(xiàng)目拆分為富文本編輯核心組件與演示主程序并提供完整解決方案功能覆蓋基礎(chǔ)文本編輯、查找替換、HTML源碼查看、打印、導(dǎo)出純文本、插入圖片與表格便于理解編輯器界面與業(yè)務(wù)邏輯的分層組織。rar壓縮包共289個(gè)文件約753KB包含76個(gè)cs源碼、若干xaml與baml界面資源、gif/png圖片素材、dll與pdb程序集及配置文檔等其中cs源碼承載編輯核心邏輯xaml與baml對(duì)應(yīng)界面布局體量輕便卻保留較完整的工程結(jié)構(gòu)。已有2875人學(xué)習(xí)下載可據(jù)此研究WPF圖形模型下的復(fù)雜編輯操作、文本與圖像數(shù)據(jù)處理及.NET組件交互并在現(xiàn)有代碼上擴(kuò)展格式化選項(xiàng)或文件格式支持。1. 從「能輸入」到「能交付」一個(gè)仿 Word 的 WPF 富文本編輯器要跨過幾道坎很多人對(duì) WPF 富文本編輯器的第一印象是把 RichTextBox 拖進(jìn)窗口、綁上按鈕就完事。真做過一個(gè)仿 Word 的完整 demo 才知道「能輸入」和「能交付」之間隔著文檔模型、命令棧、分頁排版和一整層 Ribbon 界面。開源代碼 demo 的意義就在這它把一條已經(jīng)跑通的路先鋪好讓你看清每個(gè)模塊該放在哪、邊界劃在哪而不是從零開始一邊試錯(cuò)一邊猜。這套方案適合兩類讀者——畢設(shè)或課設(shè)要做桌面文檔編輯器的學(xué)生以及需要在產(chǎn)品里嵌一個(gè)輕量排版控件、又不想引入重型商業(yè)組件的開發(fā)者。2. 總體架構(gòu)設(shè)計(jì)以 FlowDocument 為唯一事實(shí)來源的六層結(jié)構(gòu)架構(gòu)這件事我一般不會(huì)一上來就畫框。先想清楚「誰是唯一事實(shí)來源」后面的分層才有意義。在這個(gè)編輯器里答案是 FlowDocument光標(biāo)、選區(qū)、格式、表格、圖片全部掛在它上面界面上任何一次點(diǎn)擊最終都要落到這棵樹上。定下這條剩下的事情就變成「誰能改它、怎么改、改完怎么存」。2.1 三條技術(shù)路線對(duì)比原生 RichTextBox、自繪排版、第三方控件WPF 做富文本繞不開三條路。第一條是原生路線RichTextBox 套 FlowDocument。好處是編輯器內(nèi)核、光標(biāo)移動(dòng)、拼寫檢查、無障礙支持全部白送你只需要補(bǔ)分頁、補(bǔ)導(dǎo)出、補(bǔ)界面。壞處也明顯FlowDocument 是流式模型天生不擅長(zhǎng)固定頁排版導(dǎo)出 docx 需要自己寫映射上萬段的長(zhǎng)文檔會(huì)明顯掉幀。第二條是自繪路線RichTextBox 只當(dāng)輸入法宿主文檔模型、排版、命中測(cè)試全部自己寫。這條路能做出完全可控的分頁和打印但對(duì)團(tuán)隊(duì)要求很高斷行算法、雙向文本、表格自動(dòng)布局每一項(xiàng)都是幾周的活。課程設(shè)計(jì)周期里基本走不完。第三條是引入商業(yè)控件。功能齊全但源碼不可見遇到「導(dǎo)出 docx 后表格邊框丟一半」這種問題只能等廠商排期和「開源代碼 demo」的定位也不搭。三條路的對(duì)比大致是這樣維度原生 RichTextBox自繪排版引擎商業(yè)控件起步成本低一天能出原型高兩周起步中接入 授權(quán)固定頁分頁需自己封裝 Paginator完全可控通常內(nèi)置docx 保真度中等需寫映射取決于實(shí)現(xiàn)深度高大文檔性能萬段級(jí)開始吃力可做到很好視產(chǎn)品而定可定制性高源碼在手最高低這個(gè) demo 走的是第一條路把 FlowDocument 當(dāng)成唯一事實(shí)來源所有擴(kuò)展圍繞它做。選型的判斷依據(jù)很樸素交付周期內(nèi)能不能把「表格 圖片 分頁 導(dǎo)出」四件事同時(shí)做扎實(shí)。原生的底子已經(jīng)解決了其中一半剩下的一半是可以靠封裝補(bǔ)上的自繪則是把已經(jīng)解決的那一半推倒重來。2.2 六層的職責(zé)劃分與依賴方向分層的關(guān)鍵不是層數(shù)多而是依賴方向單一。這個(gè)編輯器分成六層上層依賴下層反向一律通過接口或事件回調(diào)層職責(zé)關(guān)鍵類型文檔層承載唯一可信的文檔樹FlowDocument / Paragraph / Table編輯服務(wù)層所有修改以命令形式進(jìn)入IEditorCommand / UndoStack視圖層渲染、光標(biāo)、選區(qū)、分頁RichTextBox / DocumentPaginator界面層Ribbon、狀態(tài)欄、對(duì)話框RibbonTab / RoutedUICommand持久化層打開與保存各類格式DocumentIO / OpenXmlMapper擴(kuò)展層表格、圖片、查找替換、字?jǐn)?shù)統(tǒng)計(jì)IEditorPlugin一個(gè)容易翻車的地方是編輯服務(wù)層和界面層的邊界。如果 Ribbon 上的「加粗」按鈕直接去改TextElement.FontWeightProperty撤銷棧就永遠(yuǎn)記不到這一步用戶按 CtrlZ 會(huì)發(fā)現(xiàn)格式只回退一半。約定是界面層只發(fā)命令不碰文檔。Ribbon 按鈕把RoutedCommand拋出去由編輯服務(wù)層接收、執(zhí)行、入棧視圖層只負(fù)責(zé)把執(zhí)行結(jié)果畫出來。這條約定寫在代碼注釋里比寫在設(shè)計(jì)文檔里有用得多。擴(kuò)展層用插件接口收口是為了讓「查找替換」「字?jǐn)?shù)統(tǒng)計(jì)」這類功能不往主窗口里堆。每個(gè)插件實(shí)現(xiàn)三個(gè)方法初始化時(shí)掛菜單、文檔變更時(shí)刷新狀態(tài)、卸載時(shí)清理事件訂閱。少了第三條窗口關(guān)不掉、內(nèi)存不釋放這類問題會(huì)一直留著。public interface IEditorPlugin { string Name { get; } // host 暴露當(dāng)前文檔、命令總線和狀態(tài)欄插件只能通過這些入口操作 void Attach(IEditorHost host); void Detach(); } public interface IEditorHost { FlowDocument Document { get; } void Execute(IEditorCommand command); // 唯一允許修改文檔的入口 void SetStatus(string text); // 狀態(tài)欄提示避免插件直接抓控件 }Attach里掛事件、Detach里退訂是這個(gè)接口能成立的前提。我一般會(huì)要求插件在Detach之后不再持有任何TextPointer——TextPointer 會(huì)拖住整棵文檔樹一個(gè)泄漏就能讓幾十兆的內(nèi)存常駐。2.3 文檔模型拆解FlowDocument 的塊級(jí)與行內(nèi)結(jié)構(gòu)FlowDocument 是一棵樹塊級(jí)元素Block和行內(nèi)元素Inline兩套體系。塊級(jí)負(fù)責(zé)段落級(jí)結(jié)構(gòu)Paragraph、Table、List、Section、BlockUIContainer行內(nèi)負(fù)責(zé)字符級(jí)結(jié)構(gòu)Run、Span、Bold、Italic、Hyperlink、InlineUIContainer、LineBreak。FlowDocument xmlnshttp://schemas.microsoft.com/winfx/2006/xaml/presentation Paragraph FontSize16 FontWeightBold文檔標(biāo)題/Paragraph Paragraph 正文第一段其中 Bold加粗片段/Bold 與 Span ForegroundGray灰色說明/Span 可以混排。 /Paragraph List MarkerStyleDecimal ListItemParagraph列表項(xiàng)一/Paragraph/ListItem ListItemParagraph列表項(xiàng)二/Paragraph/ListItem /List Table CellSpacing0 TableRowGroup TableRowTableCellParagraph表頭/Paragraph/TableCell/TableRow /TableRowGroup /Table /FlowDocument理解這棵樹的關(guān)鍵是兩點(diǎn)。第一格式是屬性不是節(jié)點(diǎn)。Bold之所以存在只是Span上FontWeight的一個(gè)語法糖你寫run.FontWeight FontWeights.Bold和用Bold包裹最終樹結(jié)構(gòu)是一樣的。第二屬性有繼承。段落上的FontSize會(huì)被下面的Run繼承除非Run自己設(shè)了本地值。這解釋了一個(gè)高頻疑問為什么代碼里讀到的字號(hào)和用戶設(shè)的不一樣——GetValue拿到的是本地值TextRange.GetPropertyValue拿到的才是繼承后的有效值。遍歷時(shí)我一般用LogicalTreeHelper.GetChildren遞歸而不是遍歷Blocks集合本身因?yàn)镾ection和Table會(huì)嵌出多層只看一層會(huì)漏掉嵌套內(nèi)容。遍歷結(jié)果通常用來做字?jǐn)?shù)統(tǒng)計(jì)、全文替換和目錄生成這三件事的共同點(diǎn)是都需要對(duì)整棵樹做一次線性掃描。3. 核心編輯能力實(shí)現(xiàn)序列化、光標(biāo)、撤銷棧與表格圖片架構(gòu)定完落地就是四件事文檔怎么存、光標(biāo)怎么定位、改錯(cuò)了怎么退、復(fù)雜元素怎么插。這四件事做不扎實(shí)界面做得再像 Word 也只是個(gè)空殼。3.1 打開與保存XamlPackage、RTF 與 docx 的取舍WPF 提供了TextRange.Save/Load這個(gè)便捷入口但格式選擇上有坑。DataFormats.Xaml只保存 XAML 文本圖片以 URI 引用的形式存在文件一挪位置就變紅叉DataFormats.XamlPackage是 ZIP 容器把圖片等資源一起打包進(jìn)去這才是本地存檔該用的格式。public enum DocFormat { XamlPackage, Rtf, Text } public static class DocumentIO { public static void Save(FlowDocument doc, string path, DocFormat format) { using FileStream fs File.Create(path); TextRange range new TextRange(doc.ContentStart, doc.ContentEnd); DataFormat fmt format switch { DocFormat.XamlPackage DataFormats.XamlPackage, // 圖片隨包走推薦存檔 DocFormat.Rtf DataFormats.Rtf, // 便于和外部工具交換 DocFormat.Text DataFormats.Text, // 只留純文本用于預(yù)覽 _ throw new ArgumentOutOfRangeException(nameof(format)) }; range.Save(fs, fmt); } public static FlowDocument Load(string path, DocFormat format) { FlowDocument doc new FlowDocument(); using FileStream fs File.OpenRead(path); TextRange range new TextRange(doc.ContentStart, doc.ContentEnd); DataFormat fmt format DocFormat.XamlPackage ? DataFormats.XamlPackage : DataFormats.Rtf; range.Load(fs, fmt); doc.UndoCapacity 100; // 默認(rèn) 100 步夠用長(zhǎng)文檔可調(diào)到 200 return doc; } }TextRange的兩個(gè)參數(shù)是起點(diǎn)和終點(diǎn)取doc.ContentStart到doc.ContentEnd表示整篇。UndoCapacity是 RichTextBox 自帶撤銷棧的深度默認(rèn)值對(duì)短文檔夠用對(duì)動(dòng)輒幾十頁的文檔偏小編輯到中段就開始「按到某一步退不回去了」調(diào)大一些能緩解。docx 則沒有內(nèi)建通道。可行的做法是引入 OpenXML SDK寫一層OpenXmlMapper把WordprocessingDocument里的Paragraph、Table、Run逐節(jié)點(diǎn)映射成 FlowDocument 的對(duì)應(yīng)節(jié)點(diǎn)反向再寫一遍導(dǎo)出。映射過程中最耗時(shí)的不是文本是樣式字號(hào)要除以 2半磅轉(zhuǎn)磅、顏色要從 hex 轉(zhuǎn)SolidColorBrush、表格邊框要按邊的方向分別取BorderThickness。demo 里通常只覆蓋常用子集——標(biāo)題、正文、加粗斜體、表格、圖片——把「打開不崩、導(dǎo)出能看」作為及格線剩下的慢慢補(bǔ)。3.2 光標(biāo)與選區(qū)TextPointer 的定位與屬性讀寫TextPointer 是這套體系里最容易被低估的類型。它不是索引是「兩個(gè)字符之間的位置」帶一個(gè)LogicalDirection表示朝前還是朝后。這一句話沒理解透后面全是玄學(xué)。// 取光標(biāo)所在段落并讀取其有效對(duì)齊方式 TextPointer caret editor.CaretPosition; Paragraph? para caret.Paragraph; // 光標(biāo)不在段落里時(shí)為 null if (para is not null) { // GetValue 拿本地值TextRange.GetPropertyValue 拿繼承后的有效值 var range new TextRange(para.ContentStart, para.ContentEnd); object effective range.GetPropertyValue(Paragraph.TextAlignmentProperty); TextAlignment align (TextAlignment)effective; } // 選區(qū)兩端可能方向相反取 Start/End 更穩(wěn)妥 TextSelection sel editor.Selection; if (!sel.IsEmpty) { TextPointer from sel.Start; // 已按文檔順序歸一化 TextPointer to sel.End; int length from.GetOffsetToPosition(to); }三個(gè)參數(shù)值得單獨(dú)說。caret.Paragraph是向上找最近的Paragraph祖先光標(biāo)落在表格單元格或圖片容器里時(shí)返回的是所在段落不是 null這點(diǎn)和直覺一致。GetOffsetToPosition返回的是符號(hào)偏移量一個(gè)漢字算一個(gè)符號(hào)但一個(gè)\r\n在 FlowDocument 里算兩個(gè)所以字?jǐn)?shù)統(tǒng)計(jì)不能直接拿它當(dāng)年字?jǐn)?shù)用需要遍歷Run累加Text.Length。sel.Start/End已經(jīng)按文檔順序歸一化而AnchorPosition/FocusPosition保留用戶拖選方向做格式刷時(shí)前者夠用做選區(qū)擴(kuò)展時(shí)要用后者。還有一個(gè)小細(xì)節(jié)TextPointer會(huì)隨文檔變更失效。保存快照式的選區(qū)比如「記住上次編輯位置」必須在每次文檔變更后重新解析一遍否則下次跳轉(zhuǎn)就跳到別處去了。3.3 撤銷重做命令模式怎么和 RichTextBox 自帶棧共存RichTextBox 本身有撤銷為什么還要自己做一套因?yàn)樗徽J(rèn)自己視圖內(nèi)部的操作。你在 Ribbon 上插入一個(gè)表格、批量替換了二十處文字、用代碼改了一批段落的行距這些都不在它的棧里。用戶按 CtrlZ格式退回去了表格還在——這就是典型的撤銷斷層。public interface IEditorCommand { string Name { get; } void Execute(); void Undo(); } public sealed class UndoStack { private readonly StackIEditorCommand _undo new(); private readonly StackIEditorCommand _redo new(); private const int MaxDepth 100; public void Push(IEditorCommand cmd) { cmd.Execute(); _undo.Push(cmd); _redo.Clear(); // 新操作讓重做鏈?zhǔn)н@一步最常被漏掉 if (_undo.Count MaxDepth) TrimOldest(); } public void Undo() { if (_undo.Count 0) return; IEditorCommand cmd _undo.Pop(); cmd.Undo(); _redo.Push(cmd); } public void Redo() { if (_redo.Count 0) return; IEditorCommand cmd _redo.Pop(); cmd.Execute(); _undo.Push(cmd); } private void TrimOldest() { /* 棧底淘汰保持深度上限 */ } }Execute和Undo必須嚴(yán)格互逆這是命令模式能用的唯一前提。實(shí)現(xiàn)上有個(gè)務(wù)實(shí)的選擇與其為每個(gè)操作寫精細(xì)的逆操作不如在命令里存一份「操作前的選區(qū)文本 格式」快照撤銷時(shí)用快照覆蓋回去?？煺盏拇鷥r(jià)是內(nèi)存一個(gè) 300 字的段落快照不到 1 KB100 步也就幾百 KB換來的是不會(huì)出現(xiàn)「撤銷到一半文檔結(jié)構(gòu)錯(cuò)亂」這種噩夢(mèng)。另一件必須做的是合并。用戶連點(diǎn)十次加粗不應(yīng)該產(chǎn)生十條命令。常見做法是給命令加一個(gè)合并鍵操作類型 目標(biāo)范圍新命令入棧前和棧頂比對(duì)鍵相同就替換而不是追加再把一個(gè) 500ms 的時(shí)間窗作為額外條件超時(shí)就不合并。3.4 表格與圖片BlockUIContainer 與 Table 的插入邏輯表格是仿 Word 的必備項(xiàng)也是最容易做出「看起來能行、用起來全是洞」的模塊。public static Table BuildTable(int rows, int cols) { Table table new Table { CellSpacing 0, Margin new Thickness(0, 8, 0, 8) }; for (int c 0; c cols; c) table.Columns.Add(new TableColumn()); // 列寬留空交給自動(dòng)布局 TableRowGroup group new TableRowGroup(); table.RowGroups.Add(group); for (int r 0; r rows; r) { TableRow row new TableRow(); for (int c 0; c cols; c) { TableCell cell new TableCell(new Paragraph(new Run(string.Empty))) { BorderBrush Brushes.Gray, BorderThickness new Thickness(0.5), Padding new Thickness(4) }; row.Cells.Add(cell); } if (r 0) row.Background Brushes.LightGray; // 首行當(dāng)表頭 group.Rows.Add(row); } return table; }Columns里加空的TableColumn是必須的數(shù)量決定列數(shù)寬度留空才會(huì)自動(dòng)均分只往Cells里塞內(nèi)容而不加TableColumn渲染出來的列寬會(huì)塌成一條。CellSpacing 0關(guān)掉單元格間隙否則邊框是雙線和 Word 默認(rèn)樣式差很遠(yuǎn)。表頭底色放在TableRow.Background上而不是TableCell上導(dǎo)出時(shí)才能被識(shí)別成表頭行。圖片分兩種。整段獨(dú)占的圖走BlockUIContainer行內(nèi)小圖標(biāo)走InlineUIContainerBitmapImage bmp new BitmapImage(); bmp.BeginInit(); bmp.UriSource new Uri(imagePath, UriKind.Absolute); bmp.CacheOption BitmapCacheOption.OnLoad; // 立即讀進(jìn)內(nèi)存不長(zhǎng)期占用文件句柄 bmp.EndInit(); bmp.Freeze(); // 凍結(jié)后才能跨線程使用、參與打印 Image img new Image { Source bmp, Stretch Stretch.Uniform, MaxWidth 480 }; document.Blocks.Add(new BlockUIContainer(img));CacheOption.OnLoad和Freeze()這兩行不是可選項(xiàng)。不設(shè)OnLoad用戶刪掉原圖文件后文檔里的圖就沒了不Freeze打印或?qū)С龅胶笈_(tái)線程時(shí)直接拋異常。MaxWidth限制在正文寬度以內(nèi)否則一張 4000 像素的照片會(huì)把整頁撐爆。4. 仿 Word 界面層實(shí)現(xiàn)Ribbon、分頁視圖與格式刷界面層的目標(biāo)不是好看是「用戶不用學(xué)」。Word 用戶對(duì)功能區(qū)的位置有肌肉記憶字號(hào)在最左邊、加粗在旁邊、對(duì)齊方式在下一組照著排就對(duì)了。4.1 Ribbon 工具欄與 RoutedCommand 的綁定方式WPF 自帶EditingCommands加粗、斜體、下劃線、對(duì)齊、縮進(jìn)全都有現(xiàn)成的RoutedCommand前提是把CommandTarget指向編輯器。Ribbon x:NameMainRibbon AutomationProperties.Name主功能區(qū) RibbonTab Header開始 RibbonGroup Header字體 RibbonComboBox x:NameFontFamilyBox IsEditableTrue Width140 SelectionChangedOnFontFamilyChanged/ RibbonComboBox x:NameFontSizeBox IsEditableTrue Width70/ RibbonButton Label加粗 SmallImageSource/Icons/bold.png CommandEditingCommands.ToggleBold CommandTarget{Binding ElementNameEditor} FocusableFalse/ RibbonButton Label傾斜 SmallImageSource/Icons/italic.png CommandEditingCommands.ToggleItalic CommandTarget{Binding ElementNameEditor} FocusableFalse/ /RibbonGroup RibbonGroup Header段落 RibbonToggleButton Label左對(duì)齊 CommandEditingCommands.AlignLeft CommandTarget{Binding ElementNameEditor} FocusableFalse/ RibbonToggleButton Label居中 CommandEditingCommands.AlignCenter CommandTarget{Binding ElementNameEditor} FocusableFalse/ /RibbonGroup /RibbonTab /RibbonCommandTarget是這套綁定的命門。EditingCommands是路由命令不指定目標(biāo)就會(huì)沿著可視樹往上冒泡冒到 Ribbon 就斷了按鈕永遠(yuǎn)是灰的。FocusableFalse同樣關(guān)鍵——按鈕一旦能拿焦點(diǎn)點(diǎn)下去編輯器就失焦選區(qū)消失加粗作用在一個(gè)空選區(qū)上用戶看到的現(xiàn)象就是「點(diǎn)了沒反應(yīng)」。CanExecute也要接管。表格里選中整行時(shí)「項(xiàng)目符號(hào)」應(yīng)該禁用光標(biāo)在只讀區(qū)域時(shí)所有編輯命令都應(yīng)該變灰。做法是在CommandBinding的CanExecute里讀一次當(dāng)前上下文把判斷集中在一個(gè)方法里別散落到十幾個(gè)事件處理器里。4.2 分頁視圖與標(biāo)尺把流式文檔切成 A4 頁FlowDocument 是流式的天生沒有「頁」的概念。要做出 Word 那樣的分頁效果走DocumentPaginatorpublic static DocumentPaginator CreateAPaginator(FlowDocument doc) { // 96 DPI 下A4 210mm x 297mm ≈ 794 x 1123 設(shè)備無關(guān)像素 doc.PageWidth 794; doc.PageHeight 1123; doc.PagePadding new Thickness(72); // 1 英寸頁邊距對(duì)齊 Word 默認(rèn)值 doc.ColumnWidth double.PositiveInfinity; // 單欄防止自動(dòng)分欄 return ((IDocumentPaginatorSource)doc).DocumentPaginator; }三個(gè)參數(shù)的含義要說清。PageWidth/PageHeight用的是設(shè)備無關(guān)像素?fù)Q算基準(zhǔn)是 96 DPI所以 A4 是 794×1123 而不是 210×297。PagePadding是內(nèi)容區(qū)到紙邊的距離設(shè)成 72 就對(duì)應(yīng) 1 英寸和 Word 中文檔默認(rèn)頁邊距一致這樣導(dǎo)出后兩邊對(duì)得上。ColumnWidth設(shè)成PositiveInfinity是為了強(qiáng)制單欄——FlowDocument 在頁面夠?qū)挄r(shí)會(huì)自動(dòng)分欄屏幕上看著挺整齊打印出來就變成報(bào)紙排版。標(biāo)尺的實(shí)現(xiàn)思路是反過來的不畫紙畫內(nèi)容區(qū)。橫向標(biāo)尺對(duì)應(yīng)PagePadding.Left到PageWidth - PagePadding.Right這一段刻度按厘米換算1 厘米約等于 37.8 設(shè)備無關(guān)像素。縮進(jìn)標(biāo)記用Paragraph.Margin和TextIndent驅(qū)動(dòng)拖動(dòng)時(shí)直接改屬性改完再讓DocumentPaginator重新分頁。分頁視圖本身有兩種做法FlowDocumentPageViewer省事但不可控DocumentPageView配合自定義的翻頁容器靈活但要多寫幾十行。demo 里通常選后者因?yàn)橐幚怼疙撁婵s放」「雙頁并排」「頁間陰影」這些 Word 用戶期待的效果。4.3 格式刷與樣式聯(lián)動(dòng)屬性快照的正確抓法格式刷看著簡(jiǎn)單實(shí)現(xiàn)上有個(gè)容易忽略的點(diǎn)抓的是有效值不是本地值。private static readonly DependencyProperty[] CharProps { TextElement.FontFamilyProperty, TextElement.FontSizeProperty, TextElement.FontWeightProperty, TextElement.FontStyleProperty, TextElement.ForegroundProperty, TextElement.BackgroundProperty }; private DictionaryDependencyProperty, object? _snapshot; public void CaptureFormat(TextRange source) { // GetPropertyValue 返回繼承后的有效值比 GetValue 更貼近用戶看到的樣式 _snapshot CharProps.ToDictionary(p p, p source.GetPropertyValue(p)); } public void ApplyFormat(TextRange target) { if (_snapshot is null) return; foreach (KeyValuePairDependencyProperty, object kv in _snapshot) target.ApplyPropertyValue(kv.Key, kv.Value); }GetPropertyValue和GetValue的差別就在繼承上。用戶在段落上設(shè)了 14 號(hào)字光標(biāo)選中的Run本身沒有本地字號(hào)GetValue返回NaNGetPropertyValue返回 14。格式刷要復(fù)制的是「看起來的樣子」所以必須用后者。ApplyPropertyValue也有代價(jià)它會(huì)給選區(qū)內(nèi)每個(gè)元素打上本地值選區(qū)一長(zhǎng)元素的屬性表就膨脹撤銷棧也跟著漲。所以格式刷只作用在非空選區(qū)上且對(duì)超過一定長(zhǎng)度的選區(qū)給出提示別讓用戶一把刷完整篇。樣式聯(lián)動(dòng)是另一層。標(biāo)題 1、標(biāo)題 2、正文這些樣式應(yīng)該存成Style資源Ribbon 上的下拉框切換的是Paragraph.Style而不是逐個(gè)屬性去改。這樣改一次樣式定義全篇同類段落一起變才是 Word 的用法。5. 避坑與排查五類上線后才暴露的問題自測(cè)階段一切正常、交付后問題接踵而來是這類項(xiàng)目最常見的劇本。下面五條是踩過之后印象最深的按「現(xiàn)象 → 原因 → 解決」寫清楚遇到同類問題可以直接對(duì)照。5.1 渲染與持久化類圖片丟失、打印走樣、粘貼卡頓保存后圖片全變紅叉?，F(xiàn)象是文檔里圖片顯示正常關(guān)掉重開后全變成破圖占位符。原因多半是用了DataFormats.Xaml保存——這個(gè)格式存的是 XAML 文本圖片只留一個(gè)指向臨時(shí)目錄的 URI臨時(shí)目錄一清理就失效。解決是改用DataFormats.XamlPackage它是 ZIP 容器會(huì)把圖片字節(jié)一起打進(jìn)去如果出于兼容性必須用純 XAML就得自己維護(hù)一個(gè)資源字典把圖片 base64 內(nèi)嵌進(jìn) XAML 并用BitmapImage.StreamSource還原。打印出來的版式和屏幕上對(duì)不上行尾被切掉半行?，F(xiàn)象是預(yù)覽時(shí)好好的打出來右邊少一截或者頁腳文字被截?cái)唷Ｔ蛲ǔＪ瞧聊慌虐姘?96 DPI 算、打印機(jī)按物理尺寸算兩套坐標(biāo)系沒對(duì)齊再疊加PagePadding和PrintTicket頁邊距雙重扣減。解決是打印前用獨(dú)立的DocumentPaginator重新分頁把PageWidth/PageHeight設(shè)成紙張實(shí)際尺寸、PagePadding設(shè)成 0頁邊距只在PrintTicket里設(shè)一次屏幕預(yù)覽和打印走同一段分頁代碼別各寫一套。從 Word 粘貼一段帶格式的文字界面卡五秒以上?，F(xiàn)象是 CtrlV 之后整個(gè)窗口假死任務(wù)管理器里 CPU 拉滿。原因是剪貼板里帶過來的是完整的 HTML 或 RTF段落數(shù)量多、內(nèi)聯(lián)樣式多、還夾著內(nèi)嵌圖片逐段ApplyPropertyValue會(huì)觸發(fā)成百上千次布局重算。解決是先把剪貼板內(nèi)容Load到一個(gè)離屏的臨時(shí) FlowDocument在離屏文檔里做清洗去掉不認(rèn)識(shí)的樣式、壓縮連續(xù)空格、把圖片轉(zhuǎn)成BlockUIContainer清洗完再一次性合并進(jìn)主文檔內(nèi)容超過一定規(guī)模時(shí)用Dispatcher分批插入并給出進(jìn)度。5.2 交互與狀態(tài)類撤銷斷層、點(diǎn)工具欄選區(qū)消失按 CtrlZ 只能退一半格式回去了但表格還在。現(xiàn)象是用戶插了一個(gè)表格又改了字號(hào)撤銷一次字號(hào)變回去再按一次什么也不發(fā)生。原因是表格插入走的是自定義代碼路徑?jīng)]進(jìn)UndoStack只進(jìn)了 RichTextBox 自帶的棧而字號(hào)修改走的又是另一條路徑。解決是把「所有修改文檔的操作」統(tǒng)一收口到IEditorHost.Execute界面層不允許直接碰FlowDocumentRichTextBox 自帶的IsUndoEnabled關(guān)掉撤銷入口只保留一個(gè)。收口之后新加功能只要忘了走命令總線撤銷就會(huì)明顯不對(duì)反而容易發(fā)現(xiàn)。點(diǎn)了 Ribbon 上的加粗選區(qū)沒了字也沒變粗?，F(xiàn)象是選中一段文字鼠標(biāo)移到工具欄點(diǎn)一下選區(qū)高亮消失操作無效。原因是按鈕搶走了鍵盤焦點(diǎn)RichTextBox 失焦后選區(qū)被清空命令作用在一個(gè)空位置上。解決是給所有工具欄按鈕加FocusableFalse同時(shí)在PreviewMouseDown里保存一次Selection.Start/End快照命令執(zhí)行前用快照恢復(fù)選區(qū)。這兩步做完還要檢查RibbonComboBox這類可編輯控件——它必須能拿焦點(diǎn)那就得在DropDownOpened時(shí)存快照、DropDownClosed時(shí)恢復(fù)。6. 驗(yàn)收與答辯一份 20 分鐘能跑完的檢查表到了答辯或交付環(huán)節(jié)最怕的不是功能少是演示到一半翻車。我在驗(yàn)收時(shí)固定跑一張表按順序走一遍任何一項(xiàng)不過就先修再演示檢查項(xiàng)操作判定標(biāo)準(zhǔn)文檔打開打開一份含標(biāo)題、列表、表格、圖片的存檔無異常彈窗圖片正常顯示格式往返加粗、斜體、字號(hào)、顏色各設(shè)一次后保存再打開四項(xiàng)格式完全保留表格編輯插入 5×4 表格跨單元格選中后合并結(jié)構(gòu)正確邊框不斷線撤銷深度連續(xù)做 20 次不同操作按 20 次 CtrlZ回到初始狀態(tài)無殘影分頁一致性切到分頁視圖翻到最后一頁頁數(shù)與狀態(tài)欄顯示一致打印預(yù)覽打開打印預(yù)覽行尾不截?cái)囗撨吘嗯c屏幕一致粘貼壓力從外部粘貼一份 3000 字帶格式文本3 秒內(nèi)完成界面不假死長(zhǎng)文檔連續(xù)插入 200 個(gè)段落滾動(dòng)流暢輸入無明顯延遲答辯時(shí)的講述順序也有講究。別從技術(shù)棧開始講從「一個(gè)具體的使用場(chǎng)景」切進(jìn)去打開一份帶表格的文檔、改兩處格式、撤銷、導(dǎo)出、打印預(yù)覽五個(gè)動(dòng)作兩分鐘走完評(píng)委立刻知道這東西能干什么。然后再回頭講分層、講為什么選 FlowDocument、講撤銷棧為什么要自己維護(hù)——這時(shí)候技術(shù)細(xì)節(jié)才有落點(diǎn)。被問到「你這個(gè)和 Word 差在哪」誠實(shí)回答差在協(xié)同編輯、差在復(fù)雜域、差在排版引擎的精度但輕量嵌入、源碼可控、二次開發(fā)成本低這三條是它的位置。有個(gè)血淚教訓(xùn)值得說早些年我做類似的項(xiàng)目驗(yàn)收前一周才發(fā)現(xiàn)「保存后重新打開表格邊框丟了一半」追下去是導(dǎo)出映射里只處理了外邊框沒處理內(nèi)邊框。從那以后我每次動(dòng)持久化層都強(qiáng)制走一遍「改格式 → 保存 → 關(guān)程序 → 重開 → 逐項(xiàng)比對(duì)」這條鏈路哪怕只改了一行代碼。這份 demo 的工程結(jié)構(gòu)和上面的分層是一一對(duì)應(yīng)的把它當(dāng)參照物對(duì)照著自己的實(shí)現(xiàn)走一遍能省下不少返工。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取