WPF原生控件仿Word富文本编辑器：FlowDocument与命令绑定-北京尧图网络

简介面向希望基于 WPF 构建类 Word 文本编辑环境的 .NET 开发者这套开源富文本编辑器示例提供可直接运行的解决方案与可复用核心组件覆盖基础文本编辑、查找替换、HTML 源码查看、打印、纯文本导出、插入图片和表格等常见能力。压缩包共 289 个文件约 753KB以 cs 源码、xaml/baml 界面资源、gif/png 图片素材和 dll 程序集为主并包含 sln、csproj 等工程配置便于梳理项目结构与依赖关系。已有 2875 人学习或下载。读者可借助 HtmlEditor.Demo 了解编辑器界面与交互逻辑通过 HtmlEditor 组件研究富文本处理、图像与表格数据的组织方式并在此基础上扩展格式化选项、文件格式支持或第三方库集成适合作为 WPF 桌面端文档编辑功能的学习与二次开发起点。1. 从「原生控件能不能撑住」说起接到「仿 Word 的 WPF 富文本编辑器」需求时多数人第一反应是找商业控件觉得原生RichTextBox太玩具。我一开始也这么判断直到用原生控件把一份带编号列表、插图、行距设置的文档完整跑通才发现瓶颈从来不在控件本身而在于有没有把FlowDocument这套文档模型吃透。这份开源 demo 做的事情很朴素用 WPF 原生控件搭出一个能加粗、能调字号、能插图片、能存 RTF 的编辑区工具栏和编辑区之间靠路由命令解耦没有任何第三方依赖。它适合两类人一类是想给桌面端产品加个简易排版能力、又不想背商业授权包袱的开发者另一类是刚上手 WPF、想找一个完整例子把依赖属性、命令绑定、文档序列化串起来的新手。它不打算替代 Word它想做到的是把「编辑器」这件事拆到你能自己动手改的程度。2. 技术选型与工程结构原生控件撑起仿 Word 的壳2.1 RichTextBox 与第三方控件的取舍WPF 里做富文本可选路线其实只有三条原生RichTextBox加FlowDocument、嵌WebView2跑一段前端编辑器、买商业控件。三条路的差别不在功能多少而在你后续要付出什么代价。原生路线的能力边界很清晰。FlowDocument是一棵可序列化的文档树段落、行内元素、列表、表格都是强类型对象你能直接用 LINQ 遍历、直接改属性、直接挂事件。TextRange提供了对任意选区做属性读写的能力EditingCommands自带加粗、斜体、下划线、项目符号、编号、缩进、对齐这一整套命令连撤销栈都是控件内置的。对一个「仿 Word 的 demo」来说这套东西的完成度已经超出预期。它的短板同样明显。表格编辑能力弱合并单元格、跨页表格基本要自己写图片只能靠InlineUIContainer塞进去排版控制粒度粗没有分页视图长文档滚动时是一次性布局几万字以上会明显卡RTF 导出对图片和复杂样式的保真度有限。这些是原生控件的天花板选它之前得认。第三方控件的优势是这些坑别人已经踩完了表格、分页、页眉页脚、PDF 导出都是现成的。代价是授权费用、包体积以及最要命的一点——出问题时你只能提工单看不到源码排查起来像个黑匣子。WebView2那条路则是把编辑能力交给前端生态功能上限最高但 WPF 侧和 JS 侧要维护一套消息协议文档模型存在两份序列化、撤销、光标状态同步都是长期成本。我一般的判断标准是如果产品只需要「带格式的文本少量图片导出」原生控件完全够用改起来也最自由如果文档里表格占比超过三成或者需要严格的打印分页趁早换路线别硬扛。这份 demo 走的是第一条路它的价值不在于功能齐全而在于每一个功能都摊开在你眼前没有黑盒。2.2 目录结构与三层分层工程结构上这类项目最常见的做法是按职责切成四块应用层放窗口和启动逻辑控件层放编辑区和工具栏这两个UserControl核心层放命令定义、文档读写、剪贴板清洗这些纯逻辑样式层单独出一个资源字典项目方便换肤。这么切的好处是核心层不引用任何Window将来搬到别的宿主里比如嵌进插件不用改代码。WpfRichEditor/ ├── WpfRichEditor.sln ├── src/ │ ├── WpfRichEditor.App/ # 启动与主窗口 │ │ ├── App.xaml │ │ ├── MainWindow.xaml │ │ └── MainWindow.xaml.cs │ ├── WpfRichEditor.Controls/ # 可复用控件 │ │ ├── RichEditor.xaml # 编辑区 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内部只放一个RichTextBox对外暴露Document依赖属性和几个方法应用样式、加载、保存工具栏不直接持有RichTextBox引用而是通过CommandTarget找目标。这条约束很关键它决定了后面加第二个编辑区时你要不要重写工具栏。2.3 环境准备与第一次运行项目是标准的 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 即可不算坑。跑起来之后你会看到一个典型的工具栏加编辑区布局。工具栏从上到下依次是字体、字号、加粗斜体下划线、字体颜色、对齐方式、列表、插入图片、保存和打开。每一项都能点点到没选区的状态时按钮会变灰——这个灰不是写死的是命令的CanExecute在起作用第 4 章会讲清楚它是怎么联动起来的。3. 文档模型拆解FlowDocument 树、TextRange 与样式落盘3.1 Block 与 Inline 树的结构想改这个编辑器第一件事是把FlowDocument的树结构在脑子里建起来。它只有两层节点类型Block是块级元素独占一行Inline是行内元素可以并排。FlowDocument.Blocks是整篇文档的根集合里面装Paragraph段落、Section分组、List列表、Table表格、BlockUIContainer塞任意控件。Paragraph.Inlines里装Run一段同格式文本、Span可嵌套的容器、Bold/Italic/Underline语义化行内元素、Hyperlink、InlineUIContainer塞图片或任意 UI 元素、LineBreak。理解这层结构之后很多「为什么改不动」的问题就自解了。比如用户选中一段文字点加粗实际发生的是TextRange把选区拆成若干Run把FontWeight属性ApplyPropertyValue到每个Run上Bold元素只是FontWeightBold的语法糖。再比如你想给整篇文档统一行距操作对象是Paragraph而不是Run因为行距是块级属性。遍历这棵树最常用的写法是递归比如统计段落数、批量改对齐、导出纯文本都会用到// 递归展开所有块级容器只挑出 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; } } }这段代码的关键在于「容器要展开叶子要产出」。Section、List、Table都是容器自身不承载文本必须继续往下走Paragraph是叶子产出后不再递归。实际项目里我见过有人只遍历Document.Blocks一层结果列表和表格里的段落全部漏掉导出纯文本时内容缺一半排查半天才发现是遍历深度的问题。这个方法后续会被文档大纲、查找替换、全文统计反复复用值得单独抽成一个静态工具类。3.2 选中文本改样式ApplyPropertyValue 的完整链路工具栏上每个格式按钮最终都落到同一个方法上TextRange.ApplyPropertyValue。它接收一个依赖属性和一个值把属性写进选区覆盖的所有TextElement。字体、字号、前景色、背景色、加粗、斜体、下划线全走这条链路区别只是属性名不同。// 统一的样式应用入口工具栏所有格式按钮都调它 private void ApplyToSelection(DependencyProperty property, object value) { var selection _editor.Selection; // 空选区时没有可写的 TextElement直接写会静默失败 // 这里的处理是把值暂存等用户真正输入时再补避免「点了没反应」的错觉 if (selection.IsEmpty) { _pendingStyle (property, value); return; } // 整段操作包在 BeginChange/EndChange 里撤销栈只留一个记录点 _editor.BeginChange(); try { selection.ApplyPropertyValue(property, value); } finally { _editor.EndChange(); } // 焦点必须还给编辑区否则用户按方向键发现光标不在文档里 _editor.Focus(); } // 三个高频调用的封装 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读回当前值再取反这是「按钮状态跟随光标」的基础——注意读回的值可能是DependencyProperty.UnsetValue表示选区里格式不统一这时候按「未加粗」处理比较符合直觉。BeginChange/EndChange这一对很容易被忽略但它直接决定用户体验。不加的话一次「给整段设置字号」会在撤销栈里留下几十条记录用户按一次 CtrlZ 只回退一点点得连按十几下才能回到原样这属于典型的「后悔药不够吃」。包起来之后整批操作合并成一个撤销单元一次 CtrlZ 全部回退。最后那句_editor.Focus()是血泪经验。工具栏是独立控件点按钮时焦点会跑到按钮上选区在视觉上还在但TextSelection的锚点可能已经失效用户接着敲字会插到奇怪的位置。所有修改文档的命令执行完都要把焦点还给编辑区。3.3 段落级排版对齐、行距、缩进与列表行内属性管字符段落属性管整块。对齐、行距、首行缩进、段前段后距这些属性的宿主是Paragraph不是Run。所以设置方式有两种选区跨段落时用ApplyPropertyValue属性写Paragraph.TextAlignmentProperty只处理光标所在段落时直接拿CaretPosition.Paragraph改。// 段落对齐选区覆盖多个段落时每个 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意思是行高取该行内所有元素的最大高度此时LineHeight基本不起作用必须改成BlockLineHeight才会按你设的固定值算。这个属性组合是个经典陷阱不少人改完行距发现没反应怀疑控件有 bug其实就差这一行。列表用的是内置命令不用自己拼List对象// 项目符号和编号都由 EditingCommands 提供内部会处理 List 容器的创建与拆分 public void ToggleBullets() EditingCommands.ToggleBullets.Execute(null, _editor); public void ToggleNumbering() EditingCommands.ToggleNumbering.Execute(null, _editor); // 增加/减少缩进同理 public void IncreaseIndent() EditingCommands.IncreaseIndentation.Execute(null, _editor);这几个命令的第二个参数必须是RichTextBox本身传null或者传Window都会抛InvalidOperationException因为命令内部要靠它拿Document和Selection。这是新手最常撞的一堵墙报错信息只说「命令目标无效」不会告诉你要传谁。3.4 RTF 与 XAML两条存取路线的差别保存和打开是这类 demo 的必备功能WPF 提供了一条极简的路径TextRange.Save和TextRange.Load靠DataFormats决定序列化格式。整个实现不超过二十行。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否图片直接丢否小内部调试、看文档结构XAML 包DataFormats.XamlPackage是图片打进 zip否大本地存档、二次加载纯文本DataFormats.Text否是最小导出、复制到别处Save的第一个参数是Stream而不是路径这个设计是有意的它内部按字节写不经过字符串编码转换所以不会出现中文乱码。反过来说如果你图省事用StreamWriter包一层再传进去中文必然乱码因为 RTF 里的中文是\uNNNN转义序列被编码转换一次就废了。这一点在第 5 章还会展开。Load那段代码里有一句注释值得再强调一遍复用已有的FlowDocument实例。很多人写_editor.Document new FlowDocument()再往里灌内容看起来也能跑但撤销栈会被整个重置用户打开文件后按 CtrlZ 什么都不会发生。原因在第 5 章细说。4. 工具栏与命令层按钮怎么真正驱动编辑区4.1 EditingCommands 直接绑定WPF 的命令系统是这套编辑器的骨架。加粗、斜体、下划线、左对齐、居中、右对齐、两端对齐、项目符号、编号、增加缩进、减少缩进、剪切、复制、粘贴、撤销、重做——这些全都在EditingCommands和ApplicationCommands里预置好了工具栏按钮只需要一行 XAML 就能接上。ToolBarTray DockPanel.DockTop ToolBar !-- CommandTarget 必须指向 RichTextBox否则命令找不到执行目标按钮全程灰 -- 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如果工具栏按钮和编辑区不在同一条视觉树路径上或者焦点根本不在编辑区命令就找不到目标CanExecute返回false按钮变灰。显式写CommandTarget等于告诉命令「去这个控件上执行」绕开了焦点依赖。这套写法的好处是零代码。加粗、斜体、对齐、缩进、剪切粘贴、撤销重做一行 XAML 顶几十行事件处理。而且CanExecute是自动的光标在普通段落里ToggleBullets可用光标已经在列表项里DecreaseIndentation才可用选区为空时Cut自动变灰。这些状态全由控件内部维护你不需要写一行判断逻辑。4.2 自定义 RoutedCommand 支撑字号、字体、颜色内置命令覆盖不到的地方就得自己定义。字号下拉框、字体下拉框、字体颜色选择器这三个是刚需EditingCommands里没有对应的命令得走自定义RoutedUICommand加CommandBinding的路子。// 自定义命令集中放一个静态类方便 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) }); }命令定义好之后要在编辑区上挂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) { // 参数从工具栏传进来命令本身不关心 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 的行内流 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这个口子很实用它让同一个命令能接不同来源的参数字号下拉框传double字体下拉框传FontFamily颜色选择器传Brush。工具栏侧只需要CommandParameter{Binding SelectedItem, ElementNameFontSizeBox}就接上了命令实现里做一次类型判断即可。InlineUIContainer那段有个细节构造时传CaretPosition会直接把图片插到光标处不需要先操作Inlines.Add再调整位置。插入完把光标挪到container.ElementEnd用户接着敲字就会在图片后面而不是跑到图片前面去。这是插入图片最容易翻车的地方光标位置不对用户体感就是「图片插进去了但打字跑到奇怪的地方」。4.3 撤销重做与命令可用状态联动RichTextBox自带撤销栈IsUndoEnabled默认是trueUndoLimit默认值是-1不限制实际项目里建议改成一个有限值比如 100否则长时间编辑超大文档内存会一路涨。撤销栈的粒度由BeginChange/EndChange控制这对方法在第 3 章已经用过这里补充几个容易踩的点。// 撤销重做直接转发给控件不要自己维护栈 private void OnUndo(object sender, ExecutedRoutedEventArgs e) _editor.Undo(); private void OnRedo(object sender, ExecutedRoutedEventArgs e) _editor.Redo(); // 工具栏按钮的可用状态跟着控件的 CanUndo / CanRedo 走 private void RefreshUndoState() { BtnUndo.IsEnabled _editor.CanUndo; BtnRedo.IsEnabled _editor.CanRedo; }第一不要在BeginChange和EndChange之间再嵌套一对。WPF 支持嵌套但嵌套层数越多撤销粒度越粗最后可能出现「改十个段落只留一个撤销点」的情况用户想单独回退某一处就做不到了。批量操作包一层就够。第二任何绕过TextRange直接改文档对象的操作撤销栈都记不住。比如遍历所有Paragraph直接改TextAlignment控件不知道你改了CtrlZ 无法回退。要让它可撤销得把这段修改包在_editor.BeginChange()里要让它不可撤销比如加载文档时批量规整格式就在加载前把IsUndoEnabled设为false加载完再打开顺手_editor.Document保持不变。第三命令的可用状态是自动的但工具栏如果是自绘按钮而不是Button加Command绑定就要手动在SelectionChanged、TextChanged、CaretPosition变化时刷新。混用两种方式是最容易出 bug 的写法一半按钮自动灰一半按钮永远可点测试提的 bug 单上就写「格式按钮状态混乱」。我一般统一走Command绑定实在需要自绘的地方才手动同步尽量减少状态源。5. 避坑与排查五条踩出来的记录5.1 从 Word 粘贴后整篇样式崩掉现象用户从 Word 复制一段带样式的文字粘进来编辑区里原本设置好的字号、字体、行距全部被覆盖有时候还会冒出奇怪的页边距撤销也回不到粘贴前的状态。原因剪贴板里同时存在DataFormats.Rtf、DataFormats.Xaml、DataFormats.UnicodeText等多种格式RichTextBox默认会优先挑格式最丰富的那种把外来 RTF 里的一堆样式表和文档级属性一并吞进来。Word 导出的 RTF 带着它自己的样式定义进来之后和当前文档的属性打架谁后写谁赢。解决拦截DataObject.Pasting事件在粘贴真正发生前把数据对象换掉只保留纯文本或者只保留最基础的格式。// 在编辑区的构造函数里挂一次 _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(); }如果想保留一部分格式就不要整体替换数据对象而是把 RTF 取出来做一次清洗去掉\paperw、\stylesheet这类文档级控制字再用TextRange.Load手动插到光标处。这条路更细但代码量翻好几倍demo 阶段用纯文本方案完全够。5.2 长文档输入明显卡顿现象文档写到一两万字、段落数上千之后每次敲键都有几百毫秒延迟滚动也发涩任务管理器里进程内存一路涨。原因FlowDocument是流式布局没有虚拟化任何一次内容变更都会触发受影响范围内重新测量和排版。如果RichTextBox被放在ScrollViewer里外层滚动容器给它的可用高度是无限大它会尝试一次性布局整篇文档性能直接崩。另一种常见情况是PageWidth没设文档宽度跟着宿主走窗口一拉宽所有段落重新折行。解决把RichTextBox从外层ScrollViewer里拿出来用自身的VerticalScrollBarVisibilityAuto给FlowDocument设一个固定的PageWidth和PagePadding让折行结果稳定段落数特别多时按章节拆文档或者加一个「只渲染当前可见页」的分页视图。这三条里第一条见效最快也最容易被忽略。!-- 错误写法外层套 ScrollViewer编辑区高度无限布局全量跑 -- ScrollViewer RichTextBox x:NameEditor/ /ScrollViewer !-- 正确写法让编辑区自己管滚动文档宽度固定 -- RichTextBox x:NameEditor VerticalScrollBarVisibilityAuto HorizontalScrollBarVisibilityDisabled FlowDocument PageWidth794 PagePadding72,56,72,56 Paragraph/ /FlowDocument /RichTextBoxPageWidth794对应 A4 纸在 96 DPI 下的宽度左右边距 72 DIP 约等于 0.75 英寸这套数值和 Word 的默认版心基本对齐视觉上比较自然。5.3 打开文档后撤销键失效现象程序启动后编辑几下CtrlZ 正常点「打开」加载一个文件之后再编辑CtrlZ 就不动了撤销按钮也一直是灰的。原因加载时写了_editor.Document new FlowDocument()把整个文档对象换掉了。撤销栈是挂在RichTextBox上、跟着Document实例走的文档一换栈直接清空并重置旧内容的历史记录全部丢失。解决复用同一个FlowDocument实例用TextRange覆盖它的内容如果确实需要重置撤销栈比如加载后不希望用户撤销回上一个文件显式在加载前后切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 中文输入法期间选区丢失、字符顺序错乱现象用拼音输入法打字时如果中途点了工具栏的加粗或者字号候选框会消失已经输入的拼音被打断有时候字符还会插到光标前面去。原因输入法组合字符串composition string还没上屏时TextSelection处于一种中间状态此时调用ApplyPropertyValue或让编辑区失焦会强行结束组合导致输入法缓冲区的内容丢失或错位。工具栏按钮点击本身也会让RichTextBox失焦而 IME 对失焦非常敏感。解决在工具栏按钮的命令执行前判断输入法状态组合期间直接拒绝执行或者不判断但保证命令执行完立刻把焦点还回来让 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); }更稳妥的做法是在工具栏的PreviewMouseDown里做判断并e.Handled true从源头阻止焦点转移。这类问题在测试阶段很容易漏因为测试同学多用英文输入上线后中文用户一多就集中爆发。5.5 导出 RTF 后中文乱码、图片消失现象存成.rtf用 Word 打开中文全变成问号或者方块带图片的文档打开后图片位置是空白有时文件能打开但格式全乱。原因中文乱码十有八九是中间经过了一次字符编码转换。TextRange.Save应该直接接收FileStream如果为了「保险」先Save到MemoryStream再用StreamReader读成字符串写文件RTF 里的\uNNNN转义就被破坏掉了。图片消失则是 RTF 格式本身的限制WPF 的 RTF 序列化对InlineUIContainer里的图片支持很弱很多情况下直接跳过。解决中文问题保证Save的Stream是从文件直接打开的中间不做任何字符串转换图片问题改存DataFormats.XamlPackage它是 zip 包图片作为资源打进去加载时能完整还原。必须交付 RTF 的话就把图片单独导出成文件正文里留占位符接收方自己插图——听起来笨但比导出一个「图片全丢」的 RTF 更可靠。// 正确流直接来自文件不经过任何编码转换 using (var stream File.Create(path)) { range.Save(stream, DataFormats.Rtf); } // 错误示范中间转了一次字符串中文必乱 using var memory new MemoryStream(); range.Save(memory, DataFormats.Rtf); var content Encoding.UTF8.GetString(memory.ToArray()); // 这里就毁了 File.WriteAllText(path, content);6. 二次开发把 demo 改成能用的编辑器拿到这份代码之后最值得先做的一件事是把编辑区彻底组件化。demo 里RichEditor已经把RichTextBox包了一层但对外暴露的还是控件本身宿主窗口可以直接摸到Editor.Document。我一般会再收一层对外只留Document依赖属性、LoadAsync、SaveAsync和几个格式操作方法内部RichTextBox标成internal。这样将来加第二个编辑区比如批注面板、对比视图时工具栏的CommandTarget只要换绑定源逻辑一行不用改。第二个改造点是样式预设。现在工具栏是「点一下改一下」的即时模式用户想统一全文格式得全选再点。加一套ResourceDictionary里的段落样式标题一、标题二、正文、引用用Style加BasedOn定义字号、行距、段前段后距工具栏改成下拉选择选中后对光标所在段落paragraph.Style ...。FlowDocument对Style的支持是完整的这套改造成本很低但对「像 Word」这件事的提升立竿见影。第三个是查找替换。FlowDocument没有内置查找得自己遍历Run用TextRange定位再高亮。核心思路是从Document.ContentStart开始用GetTextInRun逐个取文本块命中后new TextRange(start, end).ApplyPropertyValue(TextElement.BackgroundProperty, highlightBrush)。要注意跨Run的匹配比如「富文本」三个字被加粗拆成两段稳妥的做法是先拼全文再算偏移然后用GetPositionAtOffset反查这条路径慢但准几千字的文档完全够用。最容易被低估的改造点是文档大纲。FlowDocument没有「标题」概念得靠Paragraph.Style或者自定义附加属性标记段落级别然后遍历一遍生成树。这一步做完左侧挂一个TreeView点击节点滚到对应段落paragraph.BringIntoView()整个编辑器的体感就从「能打字的框」变成了「能写文章的软件」。验证这块我给个实用建议编辑器这类控件不要只靠手点。可以在测试项目里起一个 STA 线程创建RichTextBox加载一段构造好的 RTF跑一遍格式应用再断言GetPropertyValue的返回值。WPF 控件必须在 STA 线程上创建测试框架默认是 MTA忘了加[STAThread]或者线程 ApartmentState 设置测试会直接抛InvalidOperationException报错信息还不明显。// 测试里创建 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; }最后说个心态上的事。这个 demo 最容易让人上头的地方是它让你觉得「再补几个功能就能上线」——表格、分页、页眉页脚、PDF 导出每一项看起来都不难。我从那以后每次接编辑器需求都先把「文档模型」和「视图」的边界画一遍再动手哪些数据必须进FlowDocument哪些只存在于宿主序列化时怎么保证两边对得上。边界画不清楚功能补得越多后面重构越疼。希望帮到你。本文还有配套的精品资源点击获取

WPF原生控件仿Word富文本编辑器：FlowDocument与命令绑定

相关推荐

C++引用详解：从底层原理到与指针的硬核对比

Java网页表格抓取实战：HttpClient+Jsoup导出CSV

离散数学第二章关系全解析：从集合到等价与偏序

更多资讯

协同克里金法原理与ArcGIS实战：破解多变量空间插值失效之谜

MQL4编程入门：从变量、数组到自定义指标的核心避坑指南

MATLAB信号处理实验全流程：从序列生成到FFT频谱分析与采样定理验证

麦语言函数实战避坑指南：REF、#IMPORT与L2盘口的正确用法

WPF+Socket六轴机器人通讯调试器：粘包拆包与心跳保活

GROMACS蛋白-小分子模拟NPT崩溃排查与全流程闭环方案

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？