如果你在公司项目里跟我一样被“把RichTextBox绑到ViewModel”这件事折磨过，那你一定知道，WPF里这个最常用的富文本控件，从2006年出生到现在，官方就没给过MVVM一点好脸色。网上搜索“WPF RichTextBox MVVM绑定”，翻来覆去就是“不能直接绑定Document”“用附加属性”“用行为”这几种说法，真正能落地的完整方案却很少。这篇东西我整理了近两年在工控上位机和文档编辑项目里的实际落地经验，从最小可用的Document双向绑定，到Selection联动、图片插入、序列化存取、泛型附加属性封装，再到性能和内存的坑，一次性讲透。
这套东西适合谁？一是刚学WPF MVVM、正在写编辑器或聊天界面的新手，能直接抄代码；二是被RichTextBox绑定坑过、想知道原理和更优方案的开发者，能避开我踩过的坑。我会先把为什么“不能绑定”讲清楚，再一步步给出能跑的完整实现。
1. 先看清楚：RichTextBox和MVVM的矛盾在哪里
1.1 一个老生常谈的坑
RichTextBox没有Text属性，它只有Document属性，类型是FlowDocument。你在XAML里写Text="{Binding Body}"，编译器直接报错；你想学WinForms那样弄个Text，连门都没有。
FlowDocument本身是一个DependencyObject，但它不是普通的字符串、布尔值这类标量属性。它内部维护的是一个完整的文档树：段落、行、Inline元素、超链接、图片、表格……随便一次输入，都可能触发复杂的内容结构调整。把它直接绑定到ViewModel上，MVVM的“View和ViewModel解耦”原则很难落实，因为ViewModel要操作一个UI层的文档对象，等于把View层的东西塞进了业务层。
更麻烦的是，你就算用Document="{Binding Doc}"强行绑上，用户输入时FlowDocument会变，但你绑定的源属性却收不到任何通知。TextChanged事件在RichTextBox内部是有的，可它没有暴露成绑定用的依赖属性，默认的绑定管道根本不知道文档变化这件事。
所以网上一搜全是“不能绑定”，本质原因有三个：没有字符串类型的Text属性可以绑、Document是复杂对象而不是值类型、内部变化事件没有和依赖属性系统打通。
1.2 为什么“想办法把它变成可绑定”这件事值得做
有人会说，那不用MVVM不就行了？代码后置里直接doc.TextChanged += ...，想怎么拿文本怎么拿文本。但你一旦这么干，项目复杂度上来就收不住了。大型WPF应用里，业务逻辑要跑在ViewModel，命令要统一走Command，界面状态要跟着数据状态走。编辑器内容的保存、校验、版本对比、权限控制，全都得在ViewModel里能拿到值。
举我做过的一个工控上位机项目为例，设备参数编辑器允许操作员编辑工艺备注，保存时要校验内容是否包含禁用字符，还要根据用户角色决定能否编辑。如果RichTextBox的内容直接写在界面层，校验逻辑就得破MVVM的规矩跑到View里，或者绕一大圈用事件把它带回ViewModel，代码会变得非常难维护。
所以很多时候问题的核心不是“能不能绑定”，而是“怎么用最小的代价，做一个足够通用、足够稳的可绑定RichTextBox”。这个基础设施做好之后，所有用到富文本编辑器的界面都能复用，节省下来的时间远比刚开始折腾绑定所花费的时间多。
2. 最小可用的双向绑定实现
2.1 依赖属性是绕不开的基石
既然RichTextBox自身没有可绑定的文本属性，我们要做的就是自己给它“造”一个。最通用的做法是写一个静态类，里面定义依赖属性，然后通过附加属性的方式挂到RichTextBox上。
依赖属性在这里有两个作用：一是提供绑定管道，让XAML里能写{Binding}；二是值变化时能有回调通知，让我们有机会把新值同步给UI。为什么不直接继承RichTextBox写子类？因为WPF里控件继承链很长，为了一个绑定功能去继承一个复杂控件，成本高不说，还得多维护一个新控件类；用附加属性，则所有RichTextBox开箱即用，不管是模板化出来的还是代码里new出来的，直接挂属性就能生效。
先看最小版本，创建一个RichTextBoxHelper静态类，定义Document附加属性：
public static class RichTextBoxHelper { public static readonly DependencyProperty DocumentProperty = DependencyProperty.RegisterAttached( "Document", typeof(FlowDocument), typeof(RichTextBoxHelper), new FrameworkPropertyMetadata(null, OnDocumentChanged)); public static FlowDocument GetDocument(DependencyObject obj) { return (FlowDocument)obj.GetValue(DocumentProperty); } public static void SetDocument(DependencyObject obj, FlowDocument value) { obj.SetValue(DocumentProperty, value); } private static void OnDocumentChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { if (d is RichTextBox box) { box.Document = e.NewValue as FlowDocument ?? new FlowDocument(); } } }这里有个细节：依赖属性注册时的默认值设为null，不要试图在注册时给new FlowDocument()作为默认值。
因为依赖属性系统对引用类型默认值的处理是共享的，所有没有显式赋值的控件都会拿到同一个FlowDocument实例。你想象一下，页面上两个RichTextBox没绑任何东西，结果它们共享同一个文档，在其中一个里打字，另一个也跟着变，那场景太酸爽了。所以必须在回调里处理null，给每个控件一个独立的新文档。
2.2 双向同步与重入保护
上面只是单向的“赋值给UI”，用户输入时ViewModel是不知道的。要做真正的双向绑定，必须监听RichTextBox的TextChanged事件，并把最新的FlowDocument回写依赖属性。
最直接的办法是在OnDocumentChanged里给box挂TextChanged处理器：
private static void OnDocumentChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { if (d is RichTextBox box) { box.TextChanged -= OnTextChanged; box.Document = e.NewValue as FlowDocument ?? new FlowDocument(); box.TextChanged += OnTextChanged; } }挂事件之前先把旧的处理器摘掉，防止多次赋值导致重复订阅。
再定义一个_isSyncing标志位，防止“UI变化→回写依赖属性→触发OnDocumentChanged→重新赋值文档→再次触发TextChanged”这样的死循环：
private static bool _isSyncing; private static void OnTextChanged(object sender, TextChangedEventArgs e) { if (sender is RichTextBox box && !_isSyncing) { _isSyncing = true; SetDocument(box, box.Document); _isSyncing = false; } }但这里有个隐患：_isSyncing是静态的，如果界面上同时存在多个RichTextBox，它们会共享同一个标志位。A控件输入时标志位被置为true，期间B控件恰好也触发了TextChanged，就会被错误跳过，导致B的文档没有同步。多编辑器场景下这个Bug非常隐蔽，我建议用一个实例级的包装，或者至少给每个控件记录自己的标志位。
一个比较稳的处理方式，是每次在TextChanged里临时把该控件的Document赋值给自己，强制依赖属性系统感知变化。但不需要绕这么远，更好的思路是把同步逻辑放到一个专用的BindableRichTextBox控件里，每个实例持有自己的_isSyncing。附加属性版本为了简单，可以接受单个编辑器的场景，如果是多实例场景最好封装控件。
提示：TextChanged触发非常频繁，每敲一个字符都会触发。回写依赖属性时，
SetDocument(box, box.Document)虽然是同一个对象，但依赖属性系统还是会产生一次属性变化通知。高频输入下，这会有一定性能开销。后面第6节我会讲更优的同步策略。
2.3 绑定到ViewModel
依赖属性定义好之后，XAML里就可以这样绑定：
<RichTextBox helper:RichTextBoxHelper.Document="{Binding Doc, UpdateSourceTrigger=PropertyChanged}" />ViewModel里用一个普通的可通知属性就行了：
public class MainViewModel : BindableBase { private FlowDocument _doc; public FlowDocument Doc { get => _doc; set { SetProperty(ref _doc, value); // 可以在这里做保存、校验等业务逻辑 } } }注意UpdateSourceTrigger=PropertyChanged，默认的LostFocus触发在编辑器场景下很不友好。用户正打着字切出去，可能还没离开焦点内容就已经需要保存了，等焦点丢失再更新就晚了。富文本编辑器是连续输入型控件，用PropertyChanged更符合直觉。
到这里，一个最小可用的双向绑定就完成了。这段代码不长，但解决了RichTextBox绑定的核心问题。真正做编辑器时，还需要Selection、图片、只读控制、序列化这些进阶能力，下面逐个展开。
3. 富文本编辑器真正要用的进阶能力
3.1 Selection绑定
文档编辑器里，工具栏的加粗、斜体、字号按钮，必须知道你当前选中了哪段文字。RichTextBox的Selection属性类型是TextSelection，不能直接用字符串绑定。它也是个依赖属性，但类型太复杂，不适合放到ViewModel做业务判断。
我这里提供一种折中方案：把Selection的起止偏移量或选中文本内容绑定出来。如果要精确知道选中了什么，可以在ViewModel里定义一个SelectedText属性，同步时只取选中区间的纯文本：
public static readonly DependencyProperty SelectedTextProperty = DependencyProperty.RegisterAttached( "SelectedText", typeof(string), typeof(RichTextBoxHelper), new FrameworkPropertyMetadata(string.Empty, OnSelectedTextChanged)); private static void OnSelectedTextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { if (d is RichTextBox box) { var selection = box.Selection; box.Selection.Text = e.NewValue as string ?? string.Empty; } }在TextChanged或者SelectionChanged时更新SelectedText：
private static void OnSelectionChanged(object sender, RoutedEventArgs e) { if (sender is RichTextBox box) { SetSelectedText(box, box.Selection.Text); } }但要注意：box.Selection.Text会把选中范围内的所有文本拼成一个纯字符串，图片、表格等非文本内容会被忽略或变成特殊占位符。这个方案适合简单的文本选中状态同步，如果要做样式按钮的高亮状态，需要更细粒度的方案，一般是通过CommandParameter加box.Selection.GetPropertyValue(TextElement.FontWeightProperty)这类方法，在命令里直接读取。
对于工具栏按钮来说，比较好的写法是把RichTextBox实例或Selection对象传给命令，让命令内部直接操作UI。这个在纯MVVM理论里有点“脏”，但在富文本编辑器这种强耦合UI的领域里，反而是最务实、代码量最少的做法。理论是为人服务的，不是反过来折腾人的。
3.2 插入图片
富文本编辑器没有图片是不可想象的。WPF里往FlowDocument里插入图片，常见做法是通过剪贴板粘贴，或者从文件拖拽。
剪贴板粘贴其实不用写代码，RichTextBox默认支持Ctrl+V粘贴位图。但如果你想在界面上做一个“插入图片”按钮，可以这么写：
private void InsertImageFromClipboard(RichTextBox box) { var image = Clipboard.GetImage(); if (image == null) return; var position = box.CaretPosition; var imageElement = new InlineUIContainer( new Image { Source = image, MaxWidth = 400, MaxHeight = 400 }) { BaselineAlignment = BaselineAlignment.Center }; position.InsertInlineUIContainer(imageElement); box.Focus(); }代码意思很简单：拿到剪贴板图像，创建一个InlineUIContainer包住Image控件，插入到光标位置。InlineUIContainer是FlowDocument里嵌UI元素的容器，任何WPF控件都能塞进去，这是FlowDocument设计上比较灵活的地方。
拖拽插入图片稍微麻烦一点，需要处理DragEnter和Drop：
box.AllowDrop = true; box.DragOver += (s, e) => { e.Effects = e.Data.GetDataPresent(DataFormats.FileDrop) ? DragDropEffects.Copy : DragDropEffects.None; e.Handled = true; }; box.Drop += (s, e) => { if (e.Data.GetData(DataFormats.FileDrop) is string[] files && files.Length > 0) { foreach (var file in files) { if (Path.GetExtension(file).ToLower() is ".png" or ".jpg" or ".jpeg" or ".bmp") { var image = new BitmapImage(new Uri(file)); var container = new InlineUIContainer( new Image { Source = image, MaxWidth = 400 }) { BaselineAlignment = BaselineAlignment.Center }; box.CaretPosition.InsertInlineUIContainer(container); } } e.Handled = true; } };拖拽时要把e.Handled = true设置上，否则RichTextBox自带的处理逻辑会和你的逻辑打架，导致图片插入位置不对或者根本没插进去。
3.3 只读、权限与工具栏联动
我在编辑器项目里遇到的第二个真实需求是权限控制。工艺员只能读，工程师能编辑，管理员能改任何内容，甚至不同字段的编辑权限都不一样。这个用绑定做起来其实很顺手，RichTextBox原生支持IsReadOnly和IsReadOnlyCaretVisible两个属性：
<RichTextBox helper:RichTextBoxHelper.Document="{Binding Doc}" IsReadOnly="{Binding IsReadOnly}" IsReadOnlyCaretVisible="True" />但直接绑定IsReadOnly在MVVM里有个坑：你希望在ViewModel里通过一个枚举角色来控制只读状态，而不是每个字段单独暴露一个bool。所以我更推荐在ViewModel里计算权限，把它转换成CanEdit属性：
public bool IsReadOnly => CurrentUserRole < UserRole.Engineer;权限变化时，调用OnPropertyChanged(nameof(IsReadOnly))通知界面刷新。
工具栏按钮的可用性也一样。加粗、斜体、插入图片这些按钮，应该根据当前选中内容和权限动态启用。实际做的时候，我用命令的CanExecute来控制。但有一个细节，WPF的命令CanExecute默认只在特定时机刷新（比如焦点切换、按钮点击），选中文字变化不会自动触发。如果发现按钮状态不跟随选区更新，要手动调用CommandManager.InvalidateRequerySuggested()。
这个我踩过好几次。一开始写了加粗按钮的Command绑定，运行后发现选不选中文字，按钮永远是灰色。加上手动刷新之后就正常了。工具栏和正文区联动，代码里要处理的其实就是这个细节。
3.4 拼写检查
如果编辑器需要输入英文，比如工艺备注里经常有英文缩写和参数名，WPF的拼写检查功能可以直接开：
<RichTextBox SpellCheck.IsEnabled="True" Language="en-US" />这个功能是系统自带的，不需要额外引入词典，也不需要联网。开启之后，拼错的单词下面会出现红色波浪线，右键还能看到建议词。需要注意的是，Language属性要设置成正确的语言，否则中文环境下可能不会生效。
SpellCheck.IsEnabled本质上是附加属性，它内部也只对TextBoxBase的子类生效。RichTextBox继承自TextBoxBase，所以没问题。实测下来，它对长文档的性能影响可以忽略，除非文档特别大且每个词都拼错（那波浪线渲染确实会变慢一些）。
4. 文本提取与序列化
4.1 为什么不用RTF
绑定解决了“界面数据”的问题，但富文本编辑器终究要把内容存到数据库或文件里。FlowDocument没法直接丢给数据库，需要序列化成字符串。WPF里TextRange支持三种序列化格式：Xaml、Rtf、Text。
网上很多老教程让你用RTF，因为Word和很多编辑器都支持RTF。但在实际项目里我强烈建议优先考虑Xaml格式，除非有和其他软件交换文档的硬性要求。原因很简单：FlowDocument里很多特性（比如InlineUIContainer嵌入的自定义控件、绑定表达式、样式资源）在序列化为RTF时会丢失，而Xaml能最大程度保留原始结构。你的编辑器是自产自销，不存在跨软件编辑的需求，用Xaml最稳。
提示：RTF格式在不同版本的.NET Framework下序列化结果有差异，跨机器会出现字体、颜色对不上的问题。用Xaml格式，只要两边是同一个WPF运行时，解析结果基本一致。
4.2 Xaml序列化实现
序列化和反序列化的代码很简单，但有一个很容易踩的坑。看代码：
public static string ToXamlText(FlowDocument document) { if (document == null) return string.Empty; var range = new TextRange(document.ContentStart, document.ContentEnd); using var ms = new MemoryStream(); range.Save(ms, DataFormats.Xaml); return Encoding.UTF8.GetString(ms.ToArray()); }这个DataFormats.Xaml是WPF自定义格式，保存出来的其实是一段XAML包XML。注意几个细节：
- 必须使用
Encoding.UTF8。有些老代码用Encoding.Default，在中文Windows上可能是GBK，存出来再读会乱码。 TextRange.Save之后，MemoryStream的位置已经在末尾了，不能直接ToString读，要先ToArray或者重置Position。range.Save前如果文档末尾有空的段落，序列化结果里会多一些空<Paragraph/>，这属于正常现象。
但上面的方法有个问题：TextRange在Save的时候会把FlowDocument中我们手动插入的InlineUIContainer等嵌入控件序列化成一堆XAML代码，这没问题；但如果你在代码里给FlowDocument设置了PagePadding、FontFamily这些资源，序列化结果会非常庞大，甚至有动态资源表达式无法解析的风险。
我踩过的更隐蔽的坑是：有些嵌入内容（比如按钮、输入框）反序列化后不一定能正常还原。所以如果编辑器只允许插入图片，序列化前要确认所有内嵌元素都是可还原类型；如果允许任何控件，建议把控件数据单独存储，不要在FlowDocument里裸嵌。
4.3 从存储恢复文档
反序列化的代码如下：
public static FlowDocument FromXamlText(string xaml) { if (string.IsNullOrWhiteSpace(xaml)) return new FlowDocument(); var doc = new FlowDocument(); var range = new TextRange(doc.ContentStart, doc.ContentEnd); using var ms = new MemoryStream(Encoding.UTF8.GetBytes(xaml)); range.Load(ms, DataFormats.Xaml); return doc; }这个range.Load调用有讲究。TextRange的构造函数第一个参数是起始TextPointer，第二个是结束TextPointer，这里用的是doc.ContentStart和doc.ContentEnd，也就是先创建空文档，再把XAML加载进去。不能直接new TextRange(null, null)，那样会抛出异常。
另外一点，如果XAML字符串是从数据库读出来的，很可能因为手工拼接、字符串转义问题变成坏数据。range.Load遇到不合法XAML会直接抛异常。轻则编辑器打不开，重则整个窗口崩掉。稳妥做法是做一层try/catch，失败时返回空文档，同时记录日志：
public static FlowDocument FromXamlSafe(string xaml) { try { return FromXamlText(xaml); } catch (Exception ex) { Debug.WriteLine($"解析富文本失败: {ex.Message}"); return new FlowDocument(); } }我在实际项目里就遇到过：数据从老系统迁移过来时，字符串里带了一个未转义的小于号<，结果Load直接崩溃。从那以后所有加载入口都包了try/catch，宁可内容丢了也不能让程序崩。
5. 做一个更通用的基础设施
5.1 泛型附加属性
上面的实现针对RichTextBox写死了，但项目里可能还有其他需要类似绑定的文本控件。WPF中可以做泛型附加属性封装，让同一个基础设施支持多种控件。虽然附加属性本身不能写成泛型类，但我们可以把公共逻辑抽成基类，再用不同的静态类暴露不同控件类型的附加属性。
举个例子，我做过一个BindableDocumentService，内部用一个条件字典来区分不同控件类型：
public static class BindableDocumentService { private static readonly Dictionary<Type, Action<DependencyObject, FlowDocument>> _documentApplier = new(); public static void RegisterDocumentApplier<T>( Action<T, FlowDocument> applier) where T : FrameworkElement { _documentApplier[typeof(T)] = (obj, doc) => applier((T)obj, doc); } public static readonly DependencyProperty DocumentProperty = DependencyProperty.RegisterAttached( "Document", typeof(FlowDocument), typeof(BindableDocumentService), new FrameworkPropertyMetadata(null, OnDocumentChanged)); private static void OnDocumentChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { if (!_documentApplier.TryGetValue(d.GetType(), out var applier)) return; applier(d, e.NewValue as FlowDocument); } public static FlowDocument GetDocument(DependencyObject obj) => (FlowDocument)obj.GetValue(DocumentProperty); public static void SetDocument(DependencyObject obj, FlowDocument value) => obj.SetValue(DocumentProperty, value); }初始化时注册RichTextBox和FlowDocumentScrollViewer的处理逻辑：
BindableDocumentService.RegisterDocumentApplier<RichTextBox>( (box, doc) => box.Document = doc ?? new FlowDocument()); BindableDocumentService.RegisterDocumentApplier<FlowDocumentScrollViewer>( (viewer, doc) => viewer.Document = doc ?? new FlowDocument());这样，同一个Document附加属性就能用在多个控件上，ViewModel里那个FlowDocument属性，既能绑到编辑器上，也能绑到只读的查看器上。
这个封装方式有一点要特别注意：_documentApplier是静态字典，多线程环境下要保证初始化顺序。一般应用启动时在App.xaml.cs里注册就够了，不会有并发问题。
5.2 DataTemplate里的坑
非要提一个我花了两天时间才找到的坑：把带Document绑定的RichTextBox放进DataTemplate，比如ListBox的ItemTemplate，然后发现绑定在界面首次显示后莫名其妙失效，或者每个项的内容互相串。
原因很简单：DataTemplate里每个项都会创建独立的RichTextBox实例，但RichTextBox内部会为每个实例创建自己的FlowDocument。当你设置附加属性后再把它丢进ItemsControl，控件模板重新生成时，box.Document可能会被框架重置为默认的空文档，导致之前的绑定值被覆盖。
解决办法有几种：
- 放弃在DataTemplate里直接放RichTextBox，改成用
ContentControl承载，并把Document绑定放到ContentControl的模板里。 - 在
Loaded事件里重新应用一次绑定值，确保模板应用完成后Document是对的。 - 如果列表只是只读展示，改用
FlowDocumentScrollViewer或者FlowDocumentReader，它们对绑定友好很多，也不需要编辑功能。
只读展示和编辑交互的边界，在代码层面就是两种控件的差别。ViewModel里那个FlowDocument属性可以共用，但View层要用不同控件去呈现它：编辑用RichTextBox，只读用FlowDocumentScrollViewer。这样权限控制也省了一大半——先判断角色，再决定用哪个View展示同一份数据。
6. 性能、内存和替代方案
6.1 大数据量下的卡顿
RichTextBox的FlowDocument本身就是为文档排版设计的，它能承载很长的文本，但TextField的编辑性能和普通TextBox完全不是一个量级。几万字的文档，每次输入都全量序列化成Xaml存在ViewModel里，UI线程会明显感到卡顿。
我之前做一个设备日志备注编辑器，用户能粘贴几千行日志进去。结果每按一个键，ViewModel里的字符串就重新序列化一次，界面开始掉帧。后来我做了两个优化：
第一，设置了同步策略。不是每个TextChanged都立刻回写ViewModel，而是用一个防抖计时器，停止输入300毫秒后再序列化同步。代码如下：
private static readonly Dictionary<RichTextBox, DispatcherTimer> _debounceTimers = new(); private static void OnTextChanged(object sender, TextChangedEventArgs e) { if (sender is not RichTextBox box) return; if (!_debounceTimers.TryGetValue(box, out var timer)) { timer = new DispatcherTimer { Interval = TimeSpan.FromMilliseconds(300) }; timer.Tick += (s, _) => { timer.Stop(); SetDocument(box, box.Document); }; _debounceTimers[box] = timer; } timer.Stop(); timer.Start(); }防抖之后，用户连续输入时ViewModel不会频繁更新，只在停顿后进行一次性同步。保存时的数据完整性不受影响，界面流畅度大幅提升。
第二，如果是只读展示超长文档，不要用RichTextBox，改用FlowDocumentReader或FlowDocumentPageViewer，这两种控件不会为每个字符维护编辑状态，渲染性能高一个数量级。
6.2 内存泄漏隐患
在附加属性版本里，最容易引发内存泄漏的地方就是事件订阅。如果每创建一个RichTextBox实例，都在OnDocumentChanged里挂一个实例级的TextChanged处理器，而这些实例又被长期保存在可视化树里来回切换，事件处理器会一直引用着控件，GC永远回收不了它们。
推荐用EventManager.RegisterClassHandler做类级别的事件处理，而不是给每个实例挂事件。类级别处理器的生命周期和类型一样长，不会因为单个实例销毁而产生泄漏：
static RichTextBoxHelper() { EventManager.RegisterClassHandler( typeof(RichTextBox), TextChangedEvent, new TextChangedEventHandler(OnTextChangedClassHandler)); }类级别处理器里，通过(sender as RichTextBox)拿到实际触发事件的控件，逻辑和实例级类似，但不需要在OnDocumentChanged里反复-=和+=，也不会有重复订阅问题。这个做法我强烈推荐，尤其是在控件会被频繁创建销毁的场景。
另外，FlowDocument里如果插入了大量图片，BitmapImage记得设置CacheOption = BitmapCacheOption.OnLoad，让图片加载后就能释放文件句柄，否则整个文件会被一直锁定，而且内存占用会随着撤销栈累积。
6.3 实在不行就别绑了
有几种场景，我建议你放弃“强绑定”的执念，回到务实方案：
- 编辑器在ScrollViewer或TabControl里被频繁卸载和重新加载。
- 需要绑定的是超大文档（比如几十万字的小说）。
- 编辑器之间需要复杂的复制粘贴格式联动。
这种情况下，与其折腾绑定，不如在代码后置里维护一个EditorMediator单例，或者在ViewModel里直接用命令调box.Document。MVVM是指导原则，不是铁律。我在做大型流程编辑器时，也遇到过“ViewModel里拿不到FlowDocument上下文”的尴尬场景，最后把部分编辑操作封装成EditorService，直接操作RichTextBox的Document，代码反而更简单清晰。
提示：如果你的ViewModel确实需要和FlowDocument深度交互，比如执行
TextRange.Find、批量替换文字、动态插入表格，直接传RichTextBox给命令是成本最低的方案。不要为了MVVM牺牲可维护性。
7. 常见问题速查表
我在使用绑定的RichTextBox过程中，把遇到的高频问题整理成了表格，你对照着排查基本能一键定位。
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 绑定后文本不显示 | ViewModel属性没有通知，或文档为空 | 确认属性是FlowDocument且实现了INotifyPropertyChanged |
| 输入后ViewModel值不更新 | 绑定没设置UpdateSourceTrigger，或事件没挂上 | 改成PropertyChanged；检查事件处理器是否被误签 |
| 界面卡顿 | 每次输入都全量序列化 | 加防抖，索引或文本变化后再同步 |
| 模板里绑定失效 | DataTemplate里RichTextBox被重新创建 | 用FlowDocumentScrollViewer只读展示，或在Loaded里重新赋值 |
| 图片插入失败 | 剪贴板没有图片数据 | 用Clipboard.ContainsImage()判断后再插入 |
| 恢复文档时抛异常 | Xaml字符串不合法 | Load外面包try/catch，返回空文档 |
| 序列化出来内容巨大 | FlowDocument带大量样式资源 | 精简资源；不要嵌动态资源引用 |
| 多个编辑器互相影响 | 依赖属性默认值共享同一固定实例 | 注册时默认null，在回调里new新实例 |
| 撤销/重做异常 | 频繁替换Document导致撤销栈混乱 | 手动管理撤销，或减少对Document的赋值次数 |
还有一个很容易被忽略的问题：如果你直接把box.Document设置成一个已经挂到其他控件的FlowDocument，WPF会抛出“指定元素已是另一个元素的逻辑子元素”异常。赋值前要判断文档是否已有parent，必要时先做doc.RemoveFromParent()处理。
写在最后的实操心得
这套绑定方案在我自己的项目里迭代了快两年，从最早依赖属性加事件、到后来封装附加属性、再到现在的泛型服务和防抖同步，每一步都是被具体问题逼出来的。我最想分享的一点是：不要一上来就追求“最完美、最符合MVVM”的架构。你先解决绑定，跑通流程，等真正遇到性能问题、模板问题、多编辑器共存问题，再针对性地优化第5、6节那些方案，反而比我这样一上来就想着做通用框架稳妥得多。
最后再分享一个真正提升体验的小技巧：如果你做的编辑器允许用户输入大量内容，建议给RichTextBox的VerticalScrollBarVisibility设成Auto，并且在内容超长时自动滚动到光标处。上面第3节那些命令，里面顺手执行一句box.ScrollToEnd()或box.CaretPosition.GetInsertionPosition(LogicalDirection.Forward)相关逻辑，就能省下用户不停拉滚动条的烦恼，这个小细节实测对这类工具型界面特别加分。
