WPF TextBox 输入限制实战：从基础到高级控制-Seo优化-合肥市网站建设公司

1. 从零开始：为什么我们需要控制TextBox的输入？

刚开始接触WPF开发的时候，我总觉得TextBox就是个简单的输入框，用户想输什么就输什么呗。直到我接手了一个财务系统项目，里面有个金额输入框，用户不仅能输入数字，还能输入中文、字母，甚至表情符号。结果可想而知，后端接口直接报错，数据校验失败，整个流程卡住。更头疼的是，有些用户习惯从Excel里复制一长串带格式的文本直接粘贴进来，里面混杂着货币符号、千位分隔符，清理起来特别麻烦。那次经历让我彻底明白，一个健壮的输入框，绝不是把控件拖到界面上就完事了，输入限制是保证数据质量和用户体验的第一道防线。

你可能觉得，输入限制不就是判断一下用户输入的内容吗？实际上，这里面的水挺深的。想象一下，你正在开发一个医疗设备的管理软件，设备编号必须是特定格式（比如“DEV-2024-001”），或者一个工业控制界面，某个参数只能输入0到100之间的整数。如果用户输错了，轻则系统报个错，重则可能引发逻辑错误，甚至安全问题。所以，对输入框进行精确控制，是每个WPF开发者必须掌握的技能。

在WPF里，TextBox本身是一个非常灵活的控件，但它默认是“来者不拒”的。要实现输入限制，我们得主动介入它的输入过程。常见的思路无非几种：在用户敲下键盘的瞬间就拦截非法字符；或者等用户输入完了一整段内容，再检查格式对不对，不对就标红提示。第一种方式更主动，体验也更即时，我们今天要深入探讨的，主要就是这种“事前拦截”的实战技巧。从最基础的只允许输入数字，到用正则表达式实现复杂的格式校验，再到处理粘贴、输入法这些容易被忽略的“边角料”，我会把我这些年踩过的坑和总结的最佳实践，毫无保留地分享给你。

2. 基础实战：用事件牢牢锁死数字输入

我们先从最简单的需求开始：做一个只能输入数字的文本框。这个需求太常见了，用户登录时的验证码、填写年龄、输入数量等等都会用到。你别看它简单，要想做得完美，把各种“旁门左道”都堵上，还真得花点心思。

2.1 第一道防线：PreviewTextInput事件

WPF提供了一个非常有用的事件：PreviewTextInput。这个事件在文本“即将”输入到控件时触发，注意是“即将”，这意味着我们有机会在字符真正显示出来之前，就把它否决掉。这就像给TextBox加了一个安检门，每个字符进来都得先过检。

private void TextBox_PreviewTextInput(object sender, TextCompositionEventArgs e) { // 核心逻辑：如果输入的文本不是数字，就标记为已处理（即拦截） e.Handled = new Regex("[^0-9]+").IsMatch(e.Text); }

这段代码里的e.Text就是用户当前正在输入的那个字符（或者一串字符，比如中文输入法的组合）。Regex("[^0-9]+")这个正则表达式的意思是“匹配任何非数字字符”。IsMatch方法如果返回true，说明输入了非法字符。这时我们把e.Handled设为true，WPF就知道：“这个输入我已经处理了，你不用管了”，于是非法字符就被成功拦截，根本进不了文本框。

把这个事件处理函数挂到TextBox上，你就能得到一个基础的数字输入框了。但是，先别高兴太早，我实测下来马上就发现了第一个坑：输入法。当你把输入法切换到中文模式，准备输入“一二三”的时候，你会发现拼音字母“y”、“i”、“e”竟然能输进去！这是因为在中文输入法下，输入的英文字母被认为是“输入法组合字符”，PreviewTextInput事件在某些情况下对其拦截不彻底。

解决的办法简单粗暴但有效：直接禁用输入法。在XAML里给TextBox设置一个属性就行。

<TextBox PreviewTextInput="TextBox_PreviewTextInput" InputMethod.IsInputMethodEnabled="False" Height="30" Width="200"/>

设置InputMethod.IsInputMethodEnabled="False"后，当焦点进入这个文本框时，系统会自动切换到英文输入模式，并且不允许切换，从根本上杜绝了中文输入法带来的干扰。不过，这招要慎用，如果你的应用有需要输入中文的场景，就不能一棍子打死了。

2.2 堵住漏洞：处理粘贴操作

你以为禁了键盘输入就万事大吉了？用户还有“粘贴”这个大招。用户可以从别的地方复制一段“abc123”的文字，然后一个Ctrl+V，字母就直接进到你的数字框里了。PreviewTextInput事件可管不了粘贴操作。

要拦截粘贴，我们需要用到DataObject.AddPastingHandler这个方法。它允许我们为控件添加一个处理粘贴事件的回调。

首先，在窗口的构造函数里，为我们的TextBox添加粘贴处理器：

public MainWindow() { InitializeComponent(); // 为名为“tb”的TextBox添加粘贴事件处理 DataObject.AddPastingHandler(this.tb, TextBoxPastingEvent); }

然后，实现处理函数。这里有两种思路：

思路一：一刀切，禁止任何粘贴。这适用于要求极其严格的场景，比如验证码输入。

private void TextBoxPastingEvent(object sender, DataObjectPastingEventArgs e) { // 简单粗暴，取消粘贴命令 e.CancelCommand(); }

思路二：选择性粘贴，只粘贴数字部分。这更友好，用户体验更好。我们检查剪贴板里的内容，只允许纯数字通过。

private void TextBoxPastingEvent(object sender, DataObjectPastingEventArgs e) { // 获取剪贴板中的文本 string clipboardText = e.DataObject.GetData(typeof(string)) as string; if (clipboardText != null) { // 检查剪贴板文本是否包含非数字字符 if (new Regex("[^0-9]+").IsMatch(clipboardText)) { // 如果包含非数字，取消粘贴 e.CancelCommand(); } // 如果全是数字，则允许粘贴，事件会继续执行 } }

我比较推荐第二种方式，因为它更智能。想象一下用户从一份复杂的报表里复制了一个数字，可能前后不小心带了空格或换行，我们可以在处理函数里先做一遍清理（比如Trim()），再检查，这样就更人性化了。

2.3 完整的基础数字输入框

把上面这些组合起来，我们就能得到一个比较健壮的、只允许输入数字的TextBox了。这里给出一个完整的代码示例，包括了事件处理、输入法禁用和粘贴控制。

XAML部分：

<Window x:Class="YourNamespace.MainWindow" ...> <Grid> <TextBox x:Name="NumberOnlyTextBox" Height="30" Width="200" VerticalContentAlignment="Center" InputMethod.IsInputMethodEnabled="False" PreviewTextInput="NumberOnlyTextBox_PreviewTextInput"/> </Grid> </Window>

C# 代码隐藏部分：

public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); // 注册粘贴事件处理 DataObject.AddPastingHandler(NumberOnlyTextBox, OnNumberOnlyTextBoxPasting); } private void NumberOnlyTextBox_PreviewTextInput(object sender, TextCompositionEventArgs e) { // 核心：拦截非数字字符输入 e.Handled = new Regex("[^0-9]+").IsMatch(e.Text); } private void OnNumberOnlyTextBoxPasting(object sender, DataObjectPastingEventArgs e) { string clipboardText = e.DataObject.GetData(typeof(string)) as string; if (clipboardText != null && new Regex("[^0-9]+").IsMatch(clipboardText)) { e.CancelCommand(); // 取消非纯数字内容的粘贴 // 可以在这里给用户一个提示，比如“只能粘贴数字” MessageBox.Show("只能粘贴数字内容！", "提示", MessageBoxButton.OK, MessageBoxImage.Warning); } } }

做到这一步，一个基础但坚固的数字输入框就完成了。它能防住键盘直接输入、防住中文输入法、防住粘贴，已经能满足大部分简单场景了。

3. 进阶控制：深入键盘事件与组合键处理

用PreviewTextInput配合正则表达式是主流做法，但有时候我们需要更底层的控制，比如区分用户按的是数字键盘区的数字键还是主键盘区的，或者要处理一些特殊的控制键（如删除、退格、方向键）。这时候，PreviewKeyDown或KeyDown事件就派上用场了。

3.1 使用PreviewKeyDown进行精细按键控制

PreviewKeyDown事件在按键被按下时触发，它提供了一个KeyEventArgs参数，里面包含了详细的按键信息。我们可以通过判断e.Key这个枚举值来决定是否放行。

比如，我们要实现一个只能输入数字、小数点，并允许使用删除、退格、方向键的输入框（常用于输入金额或小数）。

private void NumericTextBox_PreviewKeyDown(object sender, KeyEventArgs e) { // 首先，允许所有的系统功能键和导航键 if (e.Key == Key.Tab || e.Key == Key.Enter || e.Key == Key.Escape || e.Key == Key.Back || e.Key == Key.Delete || e.Key == Key.Left || e.Key == Key.Right || e.Key == Key.Home || e.Key == Key.End) { return; // 不处理，允许按键 } // 允许数字键（主键盘区和数字小键盘区） if ((e.Key >= Key.D0 && e.Key <= Key.D9) || (e.Key >= Key.NumPad0 && e.Key <= Key.NumPad9)) { return; // 允许输入数字 } // 允许小数点（注意：主键盘的小数点和数字小键盘的小数点是不同的Key值） if (e.Key == Key.OemPeriod || e.Key == Key.Decimal) { // 额外检查：文本中是否已经存在小数点，避免输入多个小数点 TextBox textBox = sender as TextBox; if (textBox != null && textBox.Text.Contains('.')) { e.Handled = true; // 如果已有小数点，则阻止再次输入 } return; } // 如果按下的是Ctrl组合键（如Ctrl+A全选，Ctrl+C复制），也允许 if (Keyboard.Modifiers == ModifierKeys.Control) { return; } // 除此之外，其他所有按键一律拦截 e.Handled = true; }

这段代码的逻辑比单纯用正则表达式更细致。它逐一检查按下的键，只放行我们“白名单”里的键。这样做的好处是控制粒度极细，但缺点也很明显：代码逻辑相对复杂，而且要考虑到所有可能的按键情况，比如不同键盘布局下小数点键的Key值可能不同（OemPeriodvsDecimal）。

3.2 处理Ctrl+V粘贴的漏洞

在PreviewKeyDown事件里，我们同样需要处理粘贴漏洞。用户虽然不能用鼠标右键菜单粘贴了（我们后面会处理），但还可以用Ctrl+V快捷键。在上面的代码中，我们放行了所有的Ctrl组合键，这显然是个漏洞。

我们需要修改判断组合键的逻辑，明确禁止Ctrl+V：

private void NumericTextBox_PreviewKeyDown(object sender, KeyEventArgs e) { // ... 前面的数字、小数点、导航键判断逻辑不变 ... // 修改组合键判断：允许Ctrl组合键，但明确禁止Ctrl+V if (Keyboard.Modifiers == ModifierKeys.Control) { if (e.Key == Key.V) // 明确拦截Ctrl+V { e.Handled = true; return; } // 其他的Ctrl+A, Ctrl+C等仍然允许 return; } // ... 其他拦截逻辑 ... }

3.3 消灭最后的入口：右键菜单

即使我们处理了键盘粘贴，Windows系统还有一个经典的粘贴入口：鼠标右键菜单。用户可以在文本框里点右键，然后选择“粘贴”。要堵住这个口子，最简单的方法就是禁用TextBox自带的上下文菜单。

在XAML中设置即可：

<TextBox x:Name="NumericTextBox" ContextMenu="{x:Null}" PreviewKeyDown="NumericTextBox_PreviewKeyDown" ... />

将ContextMenu属性设为{x:Null}，这个文本框就不会弹出右键菜单了。这是一个非常有效且轻量的方法。当然，如果你需要自定义右键菜单，可以在代码中创建一个新的ContextMenu并手动控制其菜单项，确保不包含“粘贴”选项。

3.4 事件方案的优缺点总结

通过PreviewTextInput和PreviewKeyDown这两个事件，我们已经能构建起一道坚固的输入防线。让我来总结一下这种事件驱动方案的优缺点。

优点：

即时反馈：用户在输入非法字符的瞬间就被阻止，体验非常直接。
逻辑直观：代码写在事件处理程序里，对于刚入门的开发者来说容易理解和调试。
控制灵活：可以针对不同的按键或输入组合进行非常精细的控制。

缺点：

代码重复：如果界面上有十个文本框都要限制数字输入，你就得写十遍几乎相同的事件处理函数，或者弄个公共方法，但XAML里绑定事件还是比较繁琐。
侵入性强：业务逻辑（输入限制）和UI事件处理代码耦合在一起，如果后期要修改限制规则（比如从“只允许数字”改成“允许数字和字母”），就需要找到所有相关的事件处理函数进行修改。
容易遗漏：就像我们前面一步步发现输入法、粘贴、右键菜单这些漏洞一样，事件方案需要开发者考虑周全，稍有遗漏就会留下安全隐患。

正因为有这些缺点，在实际的中大型项目中，我们往往会追求一种更优雅、可复用性更高的解决方案。这就是接下来要讲的“附加属性”方案。

4. 高级封装：用附加属性打造可复用的输入控制器

如果你做过一些WPF项目，肯定对“附加属性”这个概念不陌生。它可以说是WPF依赖属性系统里一颗璀璨的明珠，能让我们给任何依赖对象“贴上”新的属性。用在输入限制上，简直是天作之合。它的核心思想是：将输入限制的逻辑封装成一个独立的、可附加的属性，像开关一样轻松地应用到任何TextBox上。

4.1 创建只允许数字的附加属性

我们来动手创建一个名为TextBoxRestriction的静态类，并在里面定义一个IsNumberOnly的附加属性。

using System.Text.RegularExpressions; using System.Windows; using System.Windows.Controls; using System.Windows.Input; public static class TextBoxRestriction { // 1. 定义附加属性 public static readonly DependencyProperty IsNumberOnlyProperty = DependencyProperty.RegisterAttached( "IsNumberOnly", typeof(bool), typeof(TextBoxRestriction), new PropertyMetadata(false, OnIsNumberOnlyChanged)); // 默认值为false，属性变化时触发回调 // 2. 标准的Get和Set方法 public static bool GetIsNumberOnly(DependencyObject obj) { return (bool)obj.GetValue(IsNumberOnlyProperty); } public static void SetIsNumberOnly(DependencyObject obj, bool value) { obj.SetValue(IsNumberOnlyProperty, value); } // 3. 属性值变化时的处理逻辑（核心！） private static void OnIsNumberOnlyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { // 确保这个属性是附加在TextBox上的 if (d is TextBox textBox) { bool newValue = (bool)e.NewValue; bool oldValue = (bool)e.OldValue; if (newValue && !oldValue) { // 属性从false变为true：启用限制 EnableNumberOnlyRestriction(textBox); } else if (!newValue && oldValue) { // 属性从true变为false：禁用限制 DisableNumberOnlyRestriction(textBox); } } } // 4. 启用限制：挂载所有事件处理器 private static void EnableNumberOnlyRestriction(TextBox textBox) { // 禁用输入法，一劳永逸 InputMethod.SetIsInputMethodEnabled(textBox, false); // 禁用右键菜单，防止鼠标粘贴 textBox.ContextMenu = null; // 挂载事件 textBox.PreviewTextInput += TextBox_PreviewTextInput_Number; textBox.PreviewKeyDown += TextBox_PreviewKeyDown_Number; // 添加粘贴事件处理器 DataObject.AddPastingHandler(textBox, TextBox_Pasting_Number); } // 5. 禁用限制：移除所有事件处理器 private static void DisableNumberOnlyRestriction(TextBox textBox) { textBox.PreviewTextInput -= TextBox_PreviewTextInput_Number; textBox.PreviewKeyDown -= TextBox_PreviewKeyDown_Number; DataObject.RemovePastingHandler(textBox, TextBox_Pasting_Number); // 注意：通常不会去恢复输入法和右键菜单，除非有特殊记录 } // 6. 具体的事件处理实现（与之前事件方案中的逻辑类似） private static void TextBox_PreviewTextInput_Number(object sender, TextCompositionEventArgs e) { e.Handled = new Regex("[^0-9]+").IsMatch(e.Text); } private static void TextBox_PreviewKeyDown_Number(object sender, KeyEventArgs e) { // 允许导航键和删除键 if (e.Key == Key.Back || e.Key == Key.Delete || e.Key == Key.Left || e.Key == Key.Right) return; // 允许Ctrl组合键（除了Ctrl+V） if (Keyboard.Modifiers == ModifierKeys.Control) { if (e.Key == Key.V) e.Handled = true; // 拦截粘贴 return; } // 只允许数字键 if (!((e.Key >= Key.D0 && e.Key <= Key.D9) || (e.Key >= Key.NumPad0 && e.Key <= Key.NumPad9))) { e.Handled = true; } } private static void TextBox_Pasting_Number(object sender, DataObjectPastingEventArgs e) { if (e.DataObject.GetDataPresent(typeof(string))) { string text = (string)e.DataObject.GetData(typeof(string)); if (!string.IsNullOrEmpty(text) && new Regex("[^0-9]+").IsMatch(text)) { e.CancelCommand(); } } } }

这个类的逻辑非常清晰：当某个TextBox的IsNumberOnly属性被设为true时，OnIsNumberOnlyChanged方法会被调用，然后自动为这个TextBox挂载上我们精心编写的三个事件处理器（PreviewTextInput,PreviewKeyDown,Pasting），同时禁用输入法和右键菜单。当属性被设为false时，又会自动移除这些事件处理器，恢复文本框的自由（虽然输入法和右键菜单需要额外处理，但通常解除限制的场景不多）。

4.2 在XAML中轻松使用

使用起来就非常简单优雅了。首先在XAML文件的顶部引入我们自定义类的命名空间（假设类放在YourProject.Controls命名空间下）。

<Window x:Class="YourProject.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="clr-namespace:YourProject.Controls" ...>

然后，在任何一个TextBox上，你只需要像设置普通属性一样，设置这个附加属性为True。

<TextBox Width="200" local:TextBoxRestriction.IsNumberOnly="True" /> <TextBox Width="200" local:TextBoxRestriction.IsNumberOnly="True" Text="默认值123"/> <TextBox Width="200"> <local:TextBoxRestriction.IsNumberOnly> <Binding Path="IsNumericMode" Mode="OneWay"/> </local:TextBoxRestriction.IsNumberOnly> </TextBox>

看到没？第三段代码甚至支持数据绑定！这意味着你可以根据ViewModel里的一个布尔值，动态地开启或关闭某个文本框的数字限制。这种灵活性和解耦程度，是直接在后台写事件处理代码无法比拟的。

4.3 更强大的扩展：通用正则表达式验证器

只限制数字当然不够酷。我们经常需要限制电话号码、邮箱、身份证号等特定格式。这时，我们可以创建一个更通用的附加属性：RegexPattern。让调用者传入一个正则表达式，我们的附加属性就按这个规则来校验。

public static class TextBoxRestriction { // ... 之前的 IsNumberOnlyProperty 定义 ... // 新增一个用于通用正则验证的附加属性 public static readonly DependencyProperty RegexPatternProperty = DependencyProperty.RegisterAttached( "RegexPattern", typeof(string), typeof(TextBoxRestriction), new PropertyMetadata(string.Empty, OnRegexPatternChanged)); public static string GetRegexPattern(DependencyObject obj) => (string)obj.GetValue(RegexPatternProperty); public static void SetRegexPattern(DependencyObject obj, string value) => obj.SetValue(RegexPatternProperty, value); private static void OnRegexPatternChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { if (d is TextBox textBox) { string newPattern = (string)e.NewValue; string oldPattern = (string)e.OldValue; // 移除旧的事件处理（如果之前有设置过模式） if (!string.IsNullOrEmpty(oldPattern)) { DetachRegexHandlers(textBox); } // 附加新的事件处理（如果新模式不为空） if (!string.IsNullOrEmpty(newPattern)) { AttachRegexHandlers(textBox, newPattern); } } } private static void AttachRegexHandlers(TextBox textBox, string pattern) { // 存储正则模式到TextBox的Tag中，方便事件处理器使用 textBox.Tag = pattern; InputMethod.SetIsInputMethodEnabled(textBox, false); textBox.ContextMenu = null; textBox.PreviewTextInput += TextBox_PreviewTextInput_Regex; textBox.PreviewKeyDown += TextBox_PreviewKeyDown_Regex; DataObject.AddPastingHandler(textBox, TextBox_Pasting_Regex); } private static void DetachRegexHandlers(TextBox textBox) { textBox.PreviewTextInput -= TextBox_PreviewTextInput_Regex; textBox.PreviewKeyDown -= TextBox_PreviewKeyDown_Regex; DataObject.RemovePastingHandler(textBox, TextBox_Pasting_Regex); textBox.Tag = null; } private static void TextBox_PreviewTextInput_Regex(object sender, TextCompositionEventArgs e) { var textBox = sender as TextBox; string pattern = textBox?.Tag as string; if (string.IsNullOrEmpty(pattern)) return; // 关键：这里校验的是“输入后的完整文本”，而不是单个字符 // 模拟输入后的文本 string proposedText = textBox.Text.Insert(textBox.SelectionStart, e.Text); Regex regex = new Regex(pattern); // 如果模拟的文本不符合正则，则阻止本次输入 e.Handled = !regex.IsMatch(proposedText); } // ... PreviewKeyDown和Pasting事件处理逻辑类似，需要根据正则进行判断，这里篇幅所限省略详细实现 ... }

使用这个通用属性时，你可以传入任何合法的正则表达式：

<!-- 只允许输入数字 --> <TextBox local:TextBoxRestriction.RegexPattern="^\d*$" /> <!-- 允许输入小数（最多两位） --> <TextBox local:TextBoxRestriction.RegexPattern="^\d*(\.\d{0,2})?$" /> <!-- 简单的邮箱格式验证 --> <TextBox local:TextBoxRestriction.RegexPattern="^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$" />

这里有一个非常重要的细节，我在代码注释里也强调了：在PreviewTextInput事件里做正则校验时，我们校验的不是e.Text这个即将输入的字符，而是textBox.Text.Insert(textBox.SelectionStart, e.Text)这个“假设输入完成后的完整字符串”。为什么要这么做？

考虑一个场景：正则要求是“最多两位小数”^\d*(\.\d{0,2})?$。文本框当前内容是"3.1"，光标在最后。用户输入一个数字"5"。如果只校验e.Text（即"5"），它是数字，会被允许。但输入后文本变成"3.15"，这符合两位小数的规则。如果用户输入的是第三个数字，比如在"3.14"后输入"5"，只校验"5"也会被允许，但最终文本"3.145"就违反了规则。所以，必须模拟输入后的完整文本来进行校验，这才是最严谨的。

5. 实战中的组合拳与疑难杂症

在实际项目中，需求往往不是单一的。我们可能需要一个输入框，它既要满足字符层面的限制（比如只能输入数字和一个小数点），又要满足业务层面的格式校验（比如整体必须是一个有效的、在某个范围内的数字）。这就需要我们打好“组合拳”，并且处理好一些边界情况。

5.1 字符校验 vs 格式校验

这是一个非常重要的概念区分。我以“输入一个最多两位小数的正数”为例来说明。

字符校验（Character Validation）：发生在输入过程中，检查每个输入的字符是否合法。比如，我们只允许输入数字0-9和一个小数点.。这个校验通常在PreviewTextInput或PreviewKeyDown里做，目的是防止非法字符进入文本框。
格式校验（Format Validation）：发生在输入后（或提交前），检查整个文本字符串是否符合最终的业务规则。比如，文本必须能解析成一个数字，小数点后不能超过两位，数字大小要在0到1000之间。这个校验通常在TextChanged、LostFocus事件里做，或者结合WPF的IDataErrorInfo和验证规则（ValidationRule）来做。

一个健壮的实现，应该两者结合。字符校验提供即时反馈和良好的输入体验，格式校验保证最终数据的绝对正确性。

// 在附加属性的事件处理器中，可以这样组合： private static void TextBox_PreviewTextInput_Decimal(object sender, TextCompositionEventArgs e) { var textBox = sender as TextBox; // 字符校验：只允许数字和小数点 Regex charRegex = new Regex("^[0-9.]*$"); if (!charRegex.IsMatch(e.Text)) { e.Handled = true; return; } // 额外的即时格式预判：防止输入多个小数点 if (e.Text == ".") { if (textBox.Text.Contains('.')) { e.Handled = true; // 已有一个小数点，禁止再输入 return; } } } private static void TextBox_TextChanged_Decimal(object sender, TextChangedEventArgs e) { var textBox = sender as TextBox; // 格式校验：最终文本必须是有效的、最多两位小数的数字 Regex formatRegex = new Regex(@"^\d+(\.\d{1,2})?$"); bool isValid = formatRegex.IsMatch(textBox.Text); if (!isValid) { // 格式不对，可以在这里提供UI反馈，比如把文本框边框标红 // 或者，进行自动矫正（谨慎使用，可能影响用户体验） // 例如：如果以小数点结尾，自动补零 "123." -> "123.0" // 或者直接清空 textBox.Text = string.Empty; } else { // 格式正确，清除错误提示 } }

5.2 处理TextChanged事件与业务赋值

前面我们主要关注用户交互式的输入。但别忘了，文本框的内容也可以通过代码直接设置，比如textBox1.Text = "abc";。PreviewTextInput和PreviewKeyDown事件对这种方式是无效的。这时，TextChanged事件就成了我们最后的守护者。

无论文本是通过用户输入、代码赋值、还是数据绑定改变的，TextChanged事件都会触发。因此，把最终、最严格的格式校验逻辑放在这里是非常合适的。它可以作为数据进入业务逻辑前的最后一道清洗和验证关口。

5.3 性能考量与用户体验

输入限制的逻辑，尤其是正则表达式匹配，会在用户每次按键时执行。虽然单次匹配开销很小，但如果正则非常复杂，或者文本框在一个频繁更新的数据网格中，也可能对性能产生轻微影响。有几点优化建议：

编译正则表达式：如果某个正则表达式会被频繁使用（比如在TextChanged事件中），可以使用Regex的Compiled选项进行编译，能提升匹配速度。
```
private static readonly Regex _decimalRegex = new Regex(@"^\d+(\.\d{1,2})?$", RegexOptions.Compiled);
```
避免在PreviewTextInput中做复杂校验：PreviewTextInput触发非常频繁，这里的逻辑应尽可能轻量。复杂的格式校验可以放到LostFocus或TextChanged中（注意TextChanged也可能频繁触发，需权衡）。
提供清晰的反馈：当用户输入被阻止时，最好能给出提示。例如，在拦截非法粘贴时弹出一个简单的ToolTip，或者让文本框轻微震动一下（动画），让用户明白发生了什么，而不是感觉程序“卡了”或“坏了”。
允许合理的编辑操作：一定要确保删除（Backspace, Delete）、光标移动（Left, Right, Home, End）、全选（Ctrl+A）、复制（Ctrl+C）等操作是畅通无阻的。我见过一些实现因为逻辑不严谨，把退格键也给禁了，导致用户输错后无法修改，非常糟糕。

5.4 一个综合性的实战案例

最后，我想分享一个我最近在物联网设备配置工具中用到的一个真实案例。需要一个文本框来输入设备的IP地址第四段（范围1-254）。要求是：

只能输入数字。
输入过程中，实时检查数值是否在1-254之间。
如果用户输入0、255或更大的数，需要立即提示并阻止（或清空）。
支持粘贴，但粘贴的内容必须经过同样的清洗和验证。

这个需求用单纯的字符校验搞不定，因为“25”是合法的（可能用户想输入254），但“255”就是非法的。必须结合PreviewTextInput、TextChanged和粘贴处理。

我最终的实现思路是：

PreviewTextInput+PreviewKeyDown：只允许输入数字和必要的控制键。
TextChanged：在这里进行实时范围校验。一旦文本变化，就尝试解析为整数。如果解析失败，或数值不在1-254之间，则将文本框背景色设为浅红色提示，但不立即清空文本（避免在用户输入“25”准备输入“4”时，因为“25”合法而无法给出连续反馈）。同时，将一个IsValid的附加属性设为False。
LostFocus：当焦点离开文本框时，进行最终裁决。如果此时IsValid为False，则清空文本框内容，并给出明确的提示（如弹出ToolTip：“请输入1-254之间的数字”）。
粘贴处理：在粘贴事件中，获取剪贴板文本，尝试解析并验证范围。如果完全合法，则允许粘贴整个数字；如果部分合法（比如粘贴“abc123def”），则只提取其中的数字“123”并填入；如果数字超出范围，则取消粘贴并提示。

这个方案既保证了输入的流畅性（输入过程中不打断），又保证了数据的最终正确性（焦点离开时强制校验），还对粘贴操作做了智能处理，用户体验非常好。实现代码虽然比之前的例子要长，但结构清晰，每个事件各司其职，维护起来也很方便。这其实就是把前面讲的所有知识点，根据一个具体的、稍复杂的业务场景，做了一次深度的融合与应用。