WPF DataGrid点击单元格立即进入编辑模式的完整实现

上个月在给公司内部的数据录入工具做交互改造，WPF的DataGrid用了这么久，收到最多的抱怨就是录数效率低：鼠标点到一个格子，以为能直接打字了，结果系统只是把单元格选中而已，还得再点一下、按F2、或者双击，才能进入编辑模式。每录一个数都多出几步操作，几百行下去手都快麻了。这个需求看着小，背后其实藏着一个很有意思的问题：WPF DataGrid默认把“选中”和“编辑”当成两个独立阶段来处理。这篇文章就从DataGrid的事件机制说起，把“点击单元格立即进入编辑模式”这个功能彻底讲透，给出可以直接抄的代码，也把我实现过程中踩过的坑一并写出来。

先说结论：要实现这个效果，最核心的动作是在鼠标左键按下的预览阶段（PreviewMouseLeftButtonDown）接管点击，把当前单元格定位好，然后主动调用DataGrid.BeginEdit。但这只是第一步，后面还有焦点、光标、提交时机、模板列冲突等一系列细节，任何一个没处理好，功能都会变得“能用但难用”。下面逐步拆开聊。

1. DataGrid点击一下为什么没反应：三步状态机的隐藏规则

1.1 WPF DataGrid把单元格交互拆成了三个独立状态

刚开始我也以为DataGrid会像Excel一样，点中就是编辑，后来翻了源码和调试事件才知道，WPF DataGrid对单元格的处理是严格分阶段的：

• 选中状态：单击一个新单元格，系统只负责把选择器移到它上面，更新Selection和CurrentCell，但是不会触发编辑。
• 激活状态：当某个单元格已经处于选中状态，再次单击这个单元格时，DataGrid才认为用户“激活”了它，此时才具备进入编辑的条件。
• 编辑状态：激活之后，还要经过内部判断（列是否只读、DataGrid整体是否只读、当前编辑是否允许），最后调用BeginEdit进入编辑。

换句话说，点击一个从未选中过的单元格，默认只走到第一步，这也是为什么“点一下没反应、再点一下才能改”会成为DataGrid的默认体验。

1.2 默认能触发编辑的几种路径都有各自代价

我整理了实际项目里最常用的几种进入编辑的方式：

操作	行为	说明
单击未选中的单元格	仅选中	不进入编辑，录数时需要额外操作
再次单击已选中的单元格	进入编辑	对DataGridTextColumn有效
双击单元格	进入编辑并选中文本	鼠标操作要走两次按键
按F2	进入编辑	键盘用户常用，但录数要抬手找键
Tab导航到单元格后输入字符	不一定进入编辑	DataGrid默认不像Excel那样输入即编辑

这些方式单独看都不算离谱，但放在高频数据录入场景里就非常拖节奏。双击要等两次Click的时间间隔，F2要腾出手去按键盘，重新单击已经选中的单元格也不符合大多数人的直觉。用户脑子里想的其实是：鼠标点到哪个格，我就要改哪个格，没有第二次操作。

1.3 寻找插入点：为什么只能选Preview阶段

既然默认逻辑只会走到“选中即止”，那我们要做的就是在它“止住”之前，把流程继续推下去。WPF的路由事件分隧道和冒泡两个方向，PreviewMouseLeftButtonDown是隧道事件，从窗口一路向下，先于单元格内部的业务逻辑执行。在这个阶段动手，有三个好处：

1. 默认的选择逻辑还没跑完，我们有机会改变CurrentCell的归属。
2. 可以获取第一手鼠标状态，做命中判断。
3. 事件还没被内部的TextBlock等控件处理，不会出现“已经选中单元格并且光标已经定位到文本上，我们再去BeginEdit”的冲突。

反过来，如果选择冒泡阶段的MouseLeftButtonDown，那时候DataGrid内部已经把选择逻辑处理完了，我们再介入就会造成“先选择、后编辑”的时序错乱，某些情况下还会导致编辑状态被DataGrid内部的后续操作覆盖。所以这篇文章的方案全部围绕Preview事件展开。

2. 在Preview鼠标事件中抢先接管：真正让点击变成编辑的实现

2.1 两种挂事件的方式，我推荐你从第二种开始用

先看最简单的实现，直接在Code-Behind里给DataGrid.CellStyle挂EventSetter：

<DataGrid x:Name="UserGrid" ItemsSource="{Binding Users}" AutoGenerateColumns="False"> <DataGrid.CellStyle> <Style TargetType="DataGridCell"> <EventSetter Event="PreviewMouseLeftButtonDown" Handler="DataGridCell_PreviewMouseLeftButtonDown"/> </Style> </DataGrid.CellStyle> </DataGrid>

对应的处理逻辑：

private void DataGridCell_PreviewMouseLeftButtonDown(object sender, MouseButtonEventArgs e) { if (sender is not DataGridCell cell) return; if (cell.IsEditing || cell.IsReadOnly) return; if (cell.Column is not DataGridColumn column || column.IsReadOnly) return; DataGrid dataGrid = FindVisualParent<DataGrid>(cell); if (dataGrid == null || dataGrid.IsReadOnly) return; if (!cell.IsFocused) cell.Focus(); if (dataGrid.CurrentCell.Column != column || !ReferenceEquals(dataGrid.CurrentCell.Item, cell.DataContext)) { dataGrid.CurrentCell = new DataGridCellInfo(cell); } bool editingStarted = dataGrid.BeginEdit(e.RoutedEvent); if (editingStarted) { PrepareEditor(cell); e.Handled = false; // 继续传递，DataGrid内部选择逻辑照常工作 } }

FindVisualParent是一个用VisualTreeHelper向上找父级的方法，项目里一般都有现成的，没有的话自己写十几行也很简单。

这套方案的好处是非常直白，代码量少，适合小项目快速验证效果。坏处是它依赖Code-Behind事件，MVVM项目里不想在View里堆逻辑的话，用起来会有点别扭。

2.2 拆解每一步：Focus、CurrentCell、BeginEdit一个都不能少

这段代码看着简单，里面有几个关键顺序不能乱，否则就是各种看似莫名其妙的问题。

先讲Focus。为什么要在BeginEdit之前调用cell.Focus？因为DataGrid的编辑逻辑和键盘焦点强相关，DataGrid当前焦点不在这个Cell上时，BeginEdit内部的很多操作（比如寻找编辑器、设置焦点范围）会拿不到正确的容器上下文。我们先把焦点落到目标单元格，编辑器生成后才能顺理成章地拿到焦点。

再讲CurrentCell。BeginEdit执行之前，DataGrid内部会拿CurrentCell和鼠标点击位置做比较，如果发现点击的单元格根本不是当前单元格，它会先切换CurrentCell，这时候再调用BeginEdit，时序上已经晚了半拍。所以在Preview阶段手动把CurrentCell设置成目标单元格，相当于提前把DataGrid的状态调整到“用户正在激活这个单元格”，紧接着再BeginEdit就非常自然。

最后是BeginEdit(RoutedEvent)这个重载。BeginEdit()也不是不能用，但传e.RoutedEvent进去可以让DataGrid明确知道“本次编辑是由鼠标左键按下的Preview事件发起的”，内部在判定允许编辑的来源时更准确。实际测试中，传入事件参数的版本在连续快速点击时，比无参版本稳定。

2.3 为什么我说这套逻辑已经处理了大部分默认行为

很多从网上Copy过代码的朋友应该见过更简短的版本，比如直接在DataGridCell的PreviewMouseLeftButtonDown里判断IsEditing后无脑BeginEdit。那些版本在简单列表上确实能跑，但遇到DataGridTextColumn以外的情况就会有问题。上面这个版本把几个核心过滤都补全了：

• cell.IsEditing：防止对已经处于编辑状态的单元格重复触发。
• cell.IsReadOnly：当前单元格只读时直接跳过。
• column.IsReadOnly：列级只读的判断。
• dataGrid.IsReadOnly：整个DataGrid只读时直接不处理。
• 连续点击不同单元格时，先调整CurrentCell再BeginEdit，避免内部提交时序错乱。

这里还有个细节：new DataGridCellInfo(cell)这个构造函数可不是随便用的，它会把DataGridCell里的DataContext提取出来作为Item，连同Column一起组装成一个DataGridCellInfo。如果直接new DataGridCellInfo(cell.DataContext, cell.Column)效果一样，但代码可读性不如传cell。

3. 获取焦点与光标落点：编辑体验的分水岭

3.1 BeginEdit成功不等于编辑器已经就绪

我第一次实现完，兴冲冲地跑起来，发现一个问题：点击单元格后，编辑模式确实激活了，但光标没有出现在我想输入的位置。大多数情况下光标停在文本框开头，有时候甚至在末尾。原因前面提过一嘴，这里再展开一下：我们是在PreviewMouseLeftButtonDown阶段触发的BeginEdit，这个阶段事件还在路由的隧道部分，单元格内的TextBlock还没被替换成TextBox编辑器。我们调用完BeginEdit之后，事件继续向下传递，但新生成的TextBox并不在原始命中测试的路径上，所以这次鼠标点击事件它根本接收不到。系统不会在拨号时帮你把拨号键自动按下，结果就是：编辑框激活了，鼠标点击位置对应的光标定位动作却没发生。

3.2 手动把光标送到鼠标点击的位置

要解决光标位置不准的问题，我采用的做法是在BeginEdit成功后，用Dispatcher.BeginInvoke把一个回调排到输入优先级，等编辑器真正布局完成后，再根据当前鼠标位置计算TextBox里的字符索引并设置CaretIndex。

private void PrepareEditor(DataGridCell cell) { Dispatcher.BeginInvoke(new Action(() => { object content = cell.Content; TextBox textBox = content as TextBox; if (textBox == null && content is DependencyObject dep) { textBox = FindDescendant<TextBox>(dep); } if (textBox != null) { textBox.Focus(); Point point = Mouse.GetPosition(textBox); int index = textBox.GetCharacterIndexFromPoint(point, true); textBox.CaretIndex = index >= 0 ? index : textBox.Text.Length; return; } ComboBox comboBox = content as ComboBox; if (comboBox == null && content is DependencyObject dep2) { comboBox = FindDescendant<ComboBox>(dep2); } if (comboBox != null) { comboBox.Focus(); comboBox.IsDropDownOpen = true; return; } }), DispatcherPriority.Input); }

这里有两个容易踩的隐藏点：

• 为什么不直接e.GetPosition(textBox)而要用Mouse.GetPosition(textBox)？因为Dispatcher回调执行的时候，原来的MouseButtonEventArgs很可能已经失效了，直接调用GetPosition会抛异常或者返回错误坐标。Mouse.GetPosition是实时从当前鼠标设备读取的，在“点击瞬间”这个时间窗口内，用户手基本没动，坐标精度完全够用。

• GetCharacterIndexFromPoint返回-1的情况很常见，比如点击位置落在文本框右边空白区域。这时候不能直接赋值-1，要兜底到Text.Length。

3.3 不同列类型要给予不同的“唤醒”动作

DataGridTextColumn的编辑器是TextBox，光标处理好就完事了。但DataGridTemplateColumn如果用的是ComboBox或DatePicker，光调用Focus还不够。ComboBox获得焦点后并不会自动展开下拉框，发布日期控件获得焦点后也不会自动弹出日历，用户还得再点一次才能选。

所以我在PrepareEditor里做了区分：遇到ComboBox就Focus并展开下拉，遇到DatePicker就Focus并打开日历。这样才能保证“点击即编辑”的体验在所有列类型上统一。如果你的模板列用的是自定义编辑器，同理，判断到对应控件类型后做一次“最适合编辑的初始状态设置”即可。

4. 写成一个附加行为：MVVM里一行XAML就能启用

4.1 为什么要封装成附加行为

前面那个Code-Behind方案虽然能用，但每个DataGrid都要写一个事件方法，模板列一多，代码隐藏页全是重复逻辑，既不美观也不好维护。放到MVVM架构里更难受，View里堆事件代码，ViewModel的同事看到就头疼。

所以我把它封装成了一个附加行为类。这样XAML里只需要挂一个附加属性，文件里看不出任何Code-Behind逻辑：

<DataGrid ItemsSource="{Binding Items}" local:DataGridEditOnClick.Enabled="True" local:DataGridEditOnClick.SkipInteractiveControls="True" local:DataGridEditOnClick.CaretMode="MousePosition"/>

4.2 行为类的完整实现

public static class DataGridEditOnClick { public enum CaretMode { MousePosition, SelectAll, Start, End } public static readonly DependencyProperty EnabledProperty = DependencyProperty.RegisterAttached( "Enabled", typeof(bool), typeof(DataGridEditOnClick), new PropertyMetadata(false, OnEnabledChanged)); public static readonly DependencyProperty SkipInteractiveControlsProperty = DependencyProperty.RegisterAttached( "SkipInteractiveControls", typeof(bool), typeof(DataGridEditOnClick), new PropertyMetadata(true)); public static readonly DependencyProperty CaretModeProperty = DependencyProperty.RegisterAttached( "CaretMode", typeof(CaretMode), typeof(DataGridEditOnClick), new PropertyMetadata(CaretMode.MousePosition)); public static void SetEnabled(DependencyObject element, bool value) => element.SetValue(EnabledProperty, value); public static bool GetEnabled(DependencyObject element) => (bool)element.GetValue(EnabledProperty); public static void SetSkipInteractiveControls(DependencyObject element, bool value) => element.SetValue(SkipInteractiveControlsProperty, value); public static bool GetSkipInteractiveControls(DependencyObject element) => (bool)element.GetValue(SkipInteractiveControlsProperty); public static void SetCaretMode(DependencyObject element, CaretMode value) => element.SetValue(CaretModeProperty, value); public static CaretMode GetCaretMode(DependencyObject element) => (CaretMode)element.GetValue(CaretModeProperty); private static void OnEnabledChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { if (d is not DataGrid grid) return; var handler = new MouseButtonEventHandler(OnCellPreviewMouseLeftButtonDown); if ((bool)e.NewValue) { grid.AddHandler(DataGridCell.PreviewMouseLeftButtonDownEvent, handler, true); } else { grid.RemoveHandler(DataGridCell.PreviewMouseLeftButtonDownEvent, handler); } } private static void OnCellPreviewMouseLeftButtonDown(object sender, MouseButtonEventArgs e) { if (sender is not DataGrid grid || grid.IsReadOnly) return; if (e.OriginalSource is not DependencyObject original) return; DataGridCell? cell = FindAncestor<DataGridCell>(original); if (cell == null || cell.IsEditing || cell.IsReadOnly) return; if (cell.Column is not DataGridColumn column || column.IsReadOnly) return; if (GetSkipInteractiveControls(grid) && IsHittingInteractiveControl(original, cell)) return; if (!cell.IsFocused) cell.Focus(); if (!IsSameCell(grid.CurrentCell, cell)) grid.CurrentCell = new DataGridCellInfo(cell); if (grid.BeginEdit(e.RoutedEvent)) { Dispatcher.BeginInvoke(new Action(() => { PrepareEditor(cell, GetCaretMode(grid)); }), DispatcherPriority.Input); } } private static bool IsHittingInteractiveControl(DependencyObject original, DataGridCell cell) { DependencyObject? current = original; while (current != null && current != cell) { if (current is Button or CheckBox or RadioButton or ComboBox or ToggleButton or Hyperlink) return true; current = VisualTreeHelper.GetParent(current); } return false; } private static bool IsSameCell(DataGridCellInfo info, DataGridCell cell) { return info.Column == cell.Column && ReferenceEquals(info.Item, cell.DataContext); } private static T? FindAncestor<T>(DependencyObject? current) where T : DependencyObject { while (current != null) { if (current is T target) return target; current = VisualTreeHelper.GetParent(current); } return null; } private static T? FindDescendant<T>(DependencyObject? root) where T : DependencyObject { if (root == null) return null; int count = VisualTreeHelper.GetChildrenCount(root); for (int i = 0; i < count; i++) { var child = VisualTreeHelper.GetChild(root, i); if (child is T target) return target; var result = FindDescendant<T>(child); if (result != null) return result; } return null; } private static void PrepareEditor(DataGridCell cell, CaretMode mode) { object content = cell.Content; DependencyObject? contentRoot = content as DependencyObject; TextBox? textBox = content as TextBox; if (textBox == null) textBox = FindDescendant<TextBox>(contentRoot); if (textBox != null) { textBox.Focus(); switch (mode) { case CaretMode.MousePosition: Point point = Mouse.GetPosition(textBox); int index = textBox.GetCharacterIndexFromPoint(point, true); textBox.CaretIndex = index >= 0 ? index : textBox.Text.Length; break; case CaretMode.SelectAll: textBox.SelectAll(); break; case CaretMode.Start: textBox.CaretIndex = 0; break; case CaretMode.End: textBox.CaretIndex = textBox.Text.Length; break; } return; } ComboBox? combo = content as ComboBox; if (combo == null) combo = FindDescendant<ComboBox>(contentRoot); if (combo != null) { combo.Focus(); combo.IsDropDownOpen = true; return; } } }

有几个地方值得解释。

一是挂事件的方式，我用的是DataGrid.AddHandler(DataGridCell.PreviewMouseLeftButtonDownEvent, ...)，而不是直接给每个DataGridCell挂EventSetter。这样事件在隧道阶段到达DataGrid时就会被我们截获，然后通过FindAncestor<DataGridCell>(e.OriginalSource)定位真正被点击的单元格。AddHandler的handledEventsToo参数传true，是为了防止单元格内部某些元素提前把PreviewMouseLeftButtonDown标记为Handled导致我们收不到，模板列场景下这个参数尤为重要。

二是SkipInteractiveControls。如果某个单元格的CellTemplate里放了一个Button或者CheckBox，用户点击这个控件时，我们其实不希望立即进入编辑状态，因为编辑模板会替换掉整个单元格内容，Button的Click事件可能还没触发就被移出了可视树。这个开关一开，命中路径上只要检测到交互控件，就放弃本次拦截，让控件按默认方式工作。

三是CaretMode。这个枚举是我在实际项目里反复测试后加上的配置项，四种模式对应不同的录入习惯：有人希望光标跟手（MousePosition），有人希望点进来就全选方便直接覆盖（SelectAll），还有人只想在开头或结尾输入（Start/End）。做成附加属性就是不想把这种交互偏好写死在代码里。

4.3 和MVVM的联动建议

行为类本身不依赖任何ViewModel，挂上就生效。真正要注意的是DataGrid的绑定状态：编辑提交后，Binding会自动把值写回绑定的属性，前提是列的Binding要正确设置UpdateSourceTrigger。通常DataGridTextColumn的Binding默认是LostFocus时才提交，这和高频录入场景不一定匹配。最好显式加上UpdateSourceTrigger=PropertyChanged或CellEditEnding里手动CommitEdit，可以避免“刚编辑完还没来得及提交就被切走”的丢失问题。

5. 实测踩坑：从双击冲突到虚拟化错位的五个问题

5.1 模板列里的CheckBox会被误编辑

这个坑我在封装行为之前就遇到了。一个状态列用了DataGridTemplateColumn，CellTemplate里放CheckBox。行为加进去之后，点击CheckBox居然没有勾选，反而弹出了编辑框。原因就是行为在Preview阶段无脑调用了BeginEdit，编辑模板一替换，CheckBox还没来得及处理Click就被移出可视树了。

之前已经给了解决方案，也就是SkipInteractiveControls。但要提醒的是，这个开关要靠命中路径检测，如果CheckBox外面包了自定义边框或者带模板的ContentControl，向上查找的时候可能检测不到CheckBox类型，需要额外考虑。最稳妥的兜底方案是：在行为里判断命中的元素如果是DataGridCell本身以外的、包含交互语义的控件，就统一不劫持。

5.2 DataGridTemplateColumn没有编辑模板等于没编辑

有时候明明列不是只读，行为也挂上了，但点击就是进不了编辑。排查了半天发现，DataGridTemplateColumn只定义了CellTemplate，没有CellEditingTemplate。这种情况下DataGrid无法生成编辑器，BeginEdit自然会失败。

定义编辑模板很容易被忽略，尤其是习惯用AutoGenerateColumns的项目。如果你用DataGridTemplateColumn承载下拉框、日期选择器这些自定义编辑器，记得两种模板都要写：

<DataGridTemplateColumn Header="状态"> <DataGridTemplateColumn.CellTemplate> <DataTemplate> <TextBlock Text="{Binding Status}"/> </DataTemplate> </DataGridTemplateColumn.CellTemplate> <DataGridTemplateColumn.CellEditingTemplate> <DataTemplate> <ComboBox ItemsSource="{Binding DataContext.StatusOptions, RelativeSource={RelativeSource AncestorType=DataGrid}}" SelectedValue="{Binding Status, UpdateSourceTrigger=PropertyChanged}"/> </DataTemplate> </DataGridTemplateColumn.CellEditingTemplate> </DataGridTemplateColumn>

5.3 SelectionUnit=FullRow时的表现差异

如果DataGrid把SelectionUnit设成了FullRow，点击单元格会先选中整行，然后再进入编辑，视觉上会闪烁一下：选中行高亮、编辑器出现，看起来没有默认的Cell模式那么干净。行为代码本身在FullRow模式下也能工作，因为DataGridCellIsEditing、CurrentCell这些机制依然存在。但如果你的目标是“零闪烁的Excel式编辑”，建议把SelectionUnit保持在默认的Cell模式，或者接受FullRow模式下的视觉反馈。

顺带一提，FullRow模式下，CellEditEnding和RowEditEnding的触发顺序会和Cell模式不同。如果长时间在FullRow模式下发现某些提交逻辑执行了两次，去排查RowEditEnding是不是在处理你已经手动CommitEdit过的内容。

5.4 虚拟化滚动与事件源查找

DataGrid默认启用了UI虚拟化，滚动时单元格会被不断创建和回收。这也是为什么我不建议在XAML里直接给DataGridCell注册永久事件再长期持有一个特定Cell的引用。用附加行为时，每次点击都从e.OriginalSource重新向上查找DataGridCell，不持有任何固定引用，就不会出现滚动后事件丢失、内存泄漏这类问题。

另外，虚拟化环境下DataGridCell的Row和Column索引很可能不可靠，尤其是经过排序或筛选之后。判断“当前点击的是哪个单元格”时，不要依赖cell.Column.DisplayIndex或DataGrid.Items.IndexOf这种东西，直接用cell.Column和cell.DataContext做对比就行。

5.5 CellEditEnding里Cancel会连锁卡住下一个单元格

这是很隐蔽的一个坑。假设你在CellEditEnding里做了数据校验，发现值非法，于是在里面设置e.Cancel = true。此时DataGrid会保持当前单元格的编辑状态不提交。然后用户再去点下一个单元格，行为代码里会尝试设置新的CurrentCell并调用BeginEdit，但DataGrid发现当前单元格还没成功提交，会拒绝切换或拒绝开启新编辑，表现就是“点了没反应，编辑框也不出现”。

不只是这个行为，这种Cancel逻辑本身就会影响DataGrid默认的交互。处理办法有两个方向：

1. 校验不通过时，不要Cancel，而是接受提交后在ViewModel里做更精细的处理。
2. 必须Cancel的场合，要把错误提示做到位，避免用户反复点无反应。同时在校验过程中给用户一个明确的提示，比如弹气泡、标红边框。

我个人建议是：录入工具尽量轻校验，重校验放到保存环节做，这样既能保持点击即编辑的顺滑，又不会把录入过程卡死。

5.6 最终可上手的推荐组合

这套功能我跑下来的最终配置是：

<DataGrid ItemsSource="{Binding Items}" SelectionUnit="Cell" AutoGenerateColumns="False" local:DataGridEditOnClick.Enabled="True" local:DataGridEditOnClick.SkipInteractiveControls="True" local:DataGridEditOnClick.CaretMode="MousePosition"> <DataGrid.Columns> <!-- 常规文本列加Binding，更新源设为PropertyChanged --> </DataGrid.Columns> </DataGrid>

列Binding加UpdateSourceTrigger=PropertyChanged，点击进入编辑后内容一变就提交，回车切下一格，整个录入流程行云流水。配合附加行为里已经处理好的焦点逻辑，连鼠标带键盘的操作都比默认DataGrid顺一个量级。

如果你想让录入效率再进一步，还可以在CellEditEnding提交成功后手动把CurrentCell定位到下一行同一列，再调用一次BeginEdit，这样录完一个数按Enter就能接着录下一个，完全不需要鼠标在表格里来回跳。我手头那个内部工具就是这么改完交付的，测试同事反馈说“录入速度提升非常明显”。

最后说点实在的：这个功能难不在那个BeginEdit调用，难在编辑介入的时机、焦点与光标的后续处理和模板列的各种边界情况。把这些细节都照顾到之后，DataGrid才能真正做到像Excel一样“点到即改”，也才敢在正式业务里交给用户高频使用。希望这篇文章能帮你少走几个弯路，尤其是那几个我在调试器前面蹲了一晚上才定位的问题。