最近在调 WPF 上位机界面，又遇到那个绕不开的老需求：界面上要动态显示一组工位状态卡片，工位数不固定，今天可能是 6 台，明天加了产线就变成 14 台，卡片还得按网格对齐。最笨的办法是每次在后台代码里往 Grid 的 RowDefinitions 和 ColumnDefinitions 里循环 Add，代码写起来又臭又长，数据一变就得重建一遍。也试过 UniformGrid，它虽然省事，但所有格子强制等大，卡片内容一旦长度不一样，布局马上变得很难看。后来我干脆自己写了一个自定义控件 AutoGrid，专门解决“内容自动排成网格”的场景，用了一段时间效果很稳，这中间踩过的坑也不少，整理出来供大家参考。
AutoGrid 本质上是一个增强版的 Grid，核心能力是“不手动定义行列，也能自动按子元素数量生成行列，并支持固定的行数或列数、支持行优先或列优先的排列方向，还能无缝放进 ItemsControl 的 ItemsPanel 里配合数据绑定使用”。它解决的不只是上位机看板问题，任何需要动态卡片、动态瓷砖、动态网格布局的 WPF 应用都可以直接用。
1. 先聊聊我为什么要写这个控件：Grid 和 UniformGrid 都不够用
1.1 用 Grid 做动态布局，代码又长又不好维护
WPF 原生的 Grid 本身是非常强大的布局容器，支持 Star、Auto、固定像素三种尺寸模式，也支持跨行跨列。但它的强大建立在“行列结构明确”这个前提上。一旦行列数量在运行时才能确定，代码就开始变味了。
假设我要排 8 个工位卡片，4 列 2 行，用原生 Grid 写大概是这个感觉：
var grid = new Grid(); for (int i = 0; i < 4; i++) { grid.ColumnDefinitions.Add(new ColumnDefinition { Width = new GridLength(1, GridUnitType.Star) }); } for (int i = 0; i < 2; i++) { grid.RowDefinitions.Add(new RowDefinition { Height = new GridLength(1, GridUnitType.Star) }); } for (int i = 0; i < list.Count; i++) { var card = CreateCard(list[i]); Grid.SetRow(card, i / 4); Grid.SetColumn(card, i % 4); grid.Children.Add(card); }如果行数列数还不固定，比如要根据集合数量自动算，那还要套一层 Math.Ceiling 去计算。这套逻辑本身不难，但它是一坨“重复的、命令式的布局代码”，散落在各个窗口里。今天这个页面要 4 列，明天那个页面要 2 行，每个地方写一遍，维护起来很痛苦。
所以第一个诉求很明确：把这些“按数量自动生成行列”的逻辑收进控件内部，对外只暴露一个 Rows 或 Columns 属性。使用方只需要声明“我要 4 列”，剩下的由控件自己算。
1.2 UniformGrid 的解与不解
有人会说我用 UniformGrid 不行吗？UniformGrid 确实是 WPF 里一个比较冷门但好用的控件，它的排列逻辑就是“子元素数量决定行列，然后所有格子等大排列”。放几个元素就是几个格子，适合做九宫格、图标矩阵这类场景。
但 UniformGrid 有两个明显的毛病：
第一，尺寸模式单一。UniformGrid 没有 Star、Auto、像素的概念，所有格子永远是等分的。你想让某一列稍微宽一点、某一行根据内容自适应高度，它做不到。Grid 的那套 GridLength 控制能力在它身上完全不存在。
第二，排列方向不可控。UniformGrid 内部默认是从左到右、从上到下排列，没有行优先和列优先的区分。但我做上位机看板的时候经常遇到“先从上往下填满第一列，再填第二列”的需求，类似仪表盘里的纵向分组，UniformGrid 满足不了。
AutoGrid 的目标就是同时吸收两边的优点：保留 Grid 的行列定义能力，同时像 UniformGrid 一样根据子元素数量自动生成行列结构，还允许指定排列方向。
1.3 我给 AutoGrid 定的目标清单
综合上面的痛点，写之前我列了一个功能清单，也算是我对它验收的标准：
- 只设置 Columns，行数根据子元素数量自动计算。
- 只设置 Rows，列数根据子元素数量自动计算。
- 什么都不设置，自动生成接近方阵的网格，行列数由子元素总数开平方决定。
- 支持 Orientation 属性，Horizontal 表示行优先填充，Vertical 表示列优先填充。
- 保留 Grid 的跨行跨列能力，用户手动参与定位时不能被自动分配逻辑覆盖。
- 能在 ItemsControl 的 ItemsPanel 中使用，配合 MVVM 实现纯数据驱动布局。
后面所有代码都是围绕这六条展开的。
2. AutoGrid 的布局核心：在 Measure 阶段自动生成行列
2.1 继承 Grid 还是 Panel？我选了 Grid
写自定义布局控件，最纠结的就是继承关系。继承 Panel 的好处是完全掌控 MeasureOverride 和 ArrangeOverride，想怎么排就怎么排；坏处是 Grid 的附加属性体系（Grid.Row、Grid.Column、Grid.RowSpan、Grid.ColumnSpan）用起来没那么自然，需要自己实现一套。
我最终选择继承 Grid。原因很实际：项目里已经有大量 XAML 和 DataTemplate 用了 Grid.Row 这类附加属性，如果 AutoGrid 继承自普通 Panel，这些写法在视觉树上会让人精神分裂——一会儿是 Grid 的附加属性，一会儿又是 AutoGrid 自己的自动分配规则。继承 Grid 之后，AutoGrid 本质上还是一个 Grid，所有基于 Grid 的布局知识可以直接迁移过来，学习成本最低。
但继承 Grid 有个代价：Grid 自身的 MeasureOverride 逻辑非常复杂，你没法绕过它去自己控制每个子元素的位置，只能在它开始测量之前，先把行列定义准备好，剩下的交给基类。这就是整个控件的核心思路——不是“自己画格子”，而是“替 Grid 把格子画好”。
2.2 行列数量是怎么算出来的
行列计算逻辑是整个控件的大脑，代码其实很短：
protected override Size MeasureOverride(Size availableSize) { // 结构未变化时避免重复重建，这个 flag 的作用后面细说 if (!_isUpdating) { _isUpdating = true; try { BuildStructure(); } finally { _isUpdating = false; } } return base.MeasureOverride(availableSize); } private void BuildStructure() { int count = InternalChildren.Count; if (count == 0) return; int targetRows = Rows; int targetColumns = Columns; // 行列都没指定，生成接近方阵的网格 if (targetRows <= 0 && targetColumns <= 0) { targetColumns = (int)Math.Ceiling(Math.Sqrt(count)); targetRows = (int)Math.Ceiling(count / (double)targetColumns); } // 只指定了列数，行数向上取整 else if (targetRows <= 0) { targetRows = (int)Math.Ceiling(count / (double)targetColumns); } // 只指定了行数，列数向上取整 else if (targetColumns <= 0) { targetColumns = (int)Math.Ceiling(count / (double)targetRows); } EnsureRowDefinitions(targetRows); EnsureColumnDefinitions(targetColumns); AssignChildIndex(targetRows, targetColumns); }这个计算逻辑不复杂，只有几个分支，但它是整个控件所有行为的基础。重点说一下几个边界情况：
- 行列都没指定时，如果用
Math.Sqrt(count)算出来列数，可能会出现列数比行数多的情况，比如 7 个元素就是 3 列 3 行，最后一个格子空着。这是符合预期的，方阵布局本来就会留空。 - 只指定列数时，行数必须用
Math.Ceiling向上取整，否则元素会溢出到可视区域外面。比如 10 个元素排 4 列，3 行能容纳 12 个，行数算出来是 2.5，向上取整为 3。 - 如果显式设置了
RowDefinitions和ColumnDefinitions，理论上 Rows 和 Columns 属性就可以不设置，但为了行为一致，我建议这两者只取其一，混用容易产生认知负担。
2.3 行列定义生成的防抖与缓存
这里要提到刚才代码里的_isUpdating标志。我最初写的第一版没这个标志，直接就在 MeasureOverride 里调用 BuildStructure，结果窗口一加载 CPU 直接拉满，布局线程死循环。
原因是这样：Grid 在 MeasureOverride 时会读取RowDefinitions和ColumnDefinitions。如果我在 MeasureOverride 过程中反复向这两个集合添加或删除元素，Grid 会认为行列结构变了，于是再次触发 Measure，Measure 又触发 BuildStructure，BuildStructure 又修改集合，循环不止。
解决办法很简单：BuildStructure 里先检查当前定义数量，和目标数量一致就直接返回，不一致才更新。_isUpdating标志则是为了防住“数量一致但内容需要刷新”的场景，比如 ChildMargin 变了，或者子元素的排列方向变了，这些情况不涉及行列数量变化，但需要重新分配索引。
行列定义本身也做了缓存，不会每次 Measure 都 new 一堆对象：
private static readonly GridLength StarLength = new GridLength(1, GridUnitType.Star); private void EnsureRowDefinitions(int rows) { while (RowDefinitions.Count < rows) { RowDefinitions.Add(new RowDefinition { Height = StarLength }); } while (RowDefinitions.Count > rows) { RowDefinitions.RemoveAt(RowDefinitions.Count - 1); } } private void EnsureColumnDefinitions(int columns) { while (ColumnDefinitions.Count < columns) { ColumnDefinitions.Add(new ColumnDefinition { Width = StarLength }); } while (ColumnDefinitions.Count > columns) { ColumnDefinitions.RemoveAt(ColumnDefinitions.Count - 1); } }如果使用方在 XAML 里手动定义了RowDefinition或ColumnDefinition，这些代码会保留用户定义的部分，只补充不够的行列，超出部分再截断。自动补充的行列默认是 Star 等分，这也是最常见的网格布局需求。
2.4 Orientation 决定填充方向：行优先还是列优先
这个属性很多人不理解有什么用。我举个实际场景：设备看板上有一个“报警信息区”，要求纵向排列，第一条报警在最上面，一列放不下再换到第二列。这就是典型的行列优先需求，但用原生 Grid 实现非常繁琐，你要先知道报警数量，再手动计算每个报警的 Grid.Row 和 Grid.Column。
AutoGrid 处理起来就一行 XAML 的事：
<controls:AutoGrid Rows="8" Orientation="Vertical"> <!-- 子元素会先填满第一列，再填第二列 --> </controls:AutoGrid>实现上其实就是索引映射公式不同。Horizontal 模式下，子元素按照row = index / columns、col = index % columns来分配位置；Vertical 模式下，按照row = index % rows、col = index / rows来分配位置：
private void AssignChildIndex(int targetRows, int targetColumns) { int count = InternalChildren.Count; for (int i = 0; i < count; i++) { var child = InternalChildren[i]; // 附加属性 AutoIndex 为 false 的子元素，跳过自动分配 if (!GetAutoIndex(child)) continue; int row, col; if (Orientation == Orientation.Horizontal) { row = i / targetColumns; col = i % targetColumns; } else { row = i % targetRows; col = i / targetRows; } // 值没变化就不重复 Set，避免无意义触发布局 if (Grid.GetRow(child) != row) Grid.SetRow(child, row); if (Grid.GetColumn(child) != col) Grid.SetColumn(child, col); } }注意这里有个细节：我在设置附加属性之前先读取当前值，如果一样就跳过去。原因稍后在踩坑章节详细讲，简单说就是 WPF 里强制设置一次 Grid.Row 即使值相同，也可能触发父级重新布局，高频场景下白白浪费性能。
3. 让它能打：跨行跨列与 ItemsControl 数据绑定场景
3.1 附加属性 AutoIndex：手动定位和自动定位的开关
一个网格控件如果只能强制平均分配每个子元素的格子，那它是不完整的。实际场景里经常有某个卡片要特别显眼，占两个格子高，或者某个面板需要跨两列展示。
Grid 原生支持 Grid.RowSpan 和 Grid.ColumnSpan，AutoGrid 既然继承了 Grid，天然就支持这两个属性。问题是自动分配索引时，如果某个子元素希望手动指定位置，两者会冲突。所以我给 AutoGrid 加了一个附加属性AutoIndex，默认是 true，表示由 AutoGrid 自动分配 Row 和 Column；一旦设置为 false，就表示这个子元素自己管理位置，AutoGrid 不碰它。
public static readonly DependencyProperty AutoIndexProperty = DependencyProperty.RegisterAttached( "AutoIndex", typeof(bool), typeof(AutoGrid), new FrameworkPropertyMetadata( true, FrameworkPropertyMetadataOptions.AffectsParentMeasure)); public static bool GetAutoIndex(DependencyObject obj) { return (bool)obj.GetValue(AutoIndexProperty); } public static void SetAutoIndex(DependencyObject obj, bool value) { obj.SetValue(AutoIndexProperty, value); }用法大概是这样的：
<controls:AutoGrid Columns="4"> <Border Grid.Row="0" Grid.Column="0" Grid.RowSpan="2" controls:AutoGrid.AutoIndex="False"> <!-- 这个块手动占据第一格，并向下跨两行 --> </Border> <Border controls:AutoGrid.AutoIndex="True"/> <Border controls:AutoGrid.AutoIndex="True"/> </controls:AutoGrid>这里要说明一个边界场景：AutoIndex 为 true 的子元素仍然按顺序向后填充，并不会因为某个手动定位的块占了位置就智能跳过。所以如果手动定位的元素和自动定位的元素混在一起，布局很可能会重叠。我的建议是：要么全部自动，要么少量手动元素放在自动元素之前，把它当成“钉在网格左上角的固定块”。
3.2 在 ItemsControl 中作为 ItemsPanel
AutoGrid 最有价值的用法，是放进 ItemsControl 的 ItemsPanel 里，实现真正的数据驱动布局。这样一来，后台只需要维护一个 ObservableCollection，集合增删元素，界面上的网格自动重排，完全不用写一行布局代码。
先看 ViewModel 这一层：
public class DeviceCardViewModel { public string DeviceName { get; set; } public string DeviceStatus { get; set; } public Brush StatusBrush { get; set; } } public class MainViewModel { public ObservableCollection<DeviceCardViewModel> Devices { get; set; } public MainViewModel() { Devices = new ObservableCollection<DeviceCardViewModel>(); // 模拟从 PLC 或 MES 拉到的实时数据 Devices.Add(new DeviceCardViewModel { DeviceName = "工位 01", DeviceStatus = "运行中", StatusBrush = Brushes.Green }); // ... 更多设备 } }XAML 这一层就清爽了：
<ItemsControl ItemsSource="{Binding Devices}"> <ItemsControl.ItemsPanel> <ItemsPanelTemplate> <controls:AutoGrid Columns="4" ChildMargin="4"/> </ItemsPanelTemplate> </ItemsControl.ItemsPanel> <ItemsControl.ItemTemplate> <DataTemplate> <Border BorderBrush="{Binding StatusBrush}" BorderThickness="2" CornerRadius="4" Padding="8"> <StackPanel> <TextBlock Text="{Binding DeviceName}" FontWeight="Bold" FontSize="14"/> <TextBlock Text="{Binding DeviceStatus}" Foreground="{Binding StatusBrush}" Margin="0,4,0,0"/> </StackPanel> </Border> </DataTemplate> </ItemsControl.ItemTemplate> </ItemsControl>这段代码里有几个细节值得展开：
第一，在 ItemsPanel 中使用的控件必须是 Panel 的子类，Grid 天然满足，所以 AutoGrid 可以直接塞进去。ItemsControl 每生成一个容器项，都会向 AutoGrid 的 Children 里添加一个元素，AutoGrid 的 MeasureOverride 会在合适的时机被触发，然后重建行列结构。
第二，AutoGrid 不需要设置 Rows，因为 ItemsControl 里到底有多少项，是在运行时由数据集合决定的。我们只需要声明“我要 4 列”，行数交给 AutoGrid 去算。
第三，ChildMargin 是我在 AutoGrid 上额外加的一个依赖属性，类型是 Thickness，作用是在 Measure 之前统一给所有子元素设置 Margin。如果不做这个，每个卡片都要包一层带 Margin 的 Border，或者手工给每个子元素设置 Margin，XAML 会膨胀得很厉害。
3.3 常见误区：AutoGrid 不是 ItemsControl
写博客的过程里我回答过几次问题，发现很多人把 AutoGrid 和 ItemsControl 混在一起。这里必须说清楚：AutoGrid 是一个 Panel，它只负责布局由它托管的一组子元素，本身不提供 ItemsSource 属性，也听不懂数据集合增删的通知。
如果你只是要在窗口里固定放几个 Grid 的子元素，那直接在 XAML 里写：
<controls:AutoGrid Columns="3"> <Border/> <Border/> <Border/> </controls:AutoGrid>如果你要根据数据集合动态生成卡片，那必须用一个宿主控件，最常用的就是 ItemsControl，把 AutoGrid 塞进它的 ItemsPanel 里，数据驱动由 ItemsControl 负责，网格排列由 AutoGrid 负责，各司其职。
另外一个相关的“坑”是：不要试图在 AutoGrid 里直接监听任何数据集合变化，也最好不要自己往InternalChildren里直接 Add。Panel 的 Children 集合在 ItemsControl 场景下由 WPF 的 ItemContainerGenerator 管理，手动干预会导致界面和数据错乱。
4. 实测中的几个坑：布局循环、附加属性残留、大数据量
4.1 布局循环：Measure 里重建 Definition 的危险
这个坑前面已经提到了，但我觉得有必要单独拿出来再说一遍，因为它太隐蔽了。现象是：窗口启动后 CPU 占用率飙升到 100%，但界面看起来一切正常，通过 Visual Studio 的实时可视化树也看不出明显异常，只有用 Performance Profiler 才会发现 Layout pass 在无限循环。
根源在于我最初在 BuildStructure 里用了类似这样的代码：
RowDefinitions.Clear(); for (int i = 0; i < rows; i++) RowDefinitions.Add(new RowDefinition());RowDefinitions集合一旦发出变化通知，Grid 就认为自己的布局结构需要重新计算，于是请求新的一轮 Measure；新的一轮 Measure 又进到 BuildStructure，又触发一次集合变化，循环往复。
正确的做法是每次都先判断“目标数量和当前数量是否一致”，不一致才操作集合；并且用一个_isUpdating标志位，在 BuildStructure 执行期间避免集合变化通知再次进入 BuildStructure。代码里的 EnsureRowDefinitions 和 EnsureColumnDefinitions 用的 while 增删法，就是为了避免无谓 Clear 操作和重复 new 对象。
如果你的 AutoGrid 在运行时行列数量会动态变化，建议参考我第 6 章扩展的版本，用字符串属性解析行列定义，而不是每次在 Measure 里去重建。
4.2 Grid.Row 的残留：容器复用导致的错位
这个坑在 ItemsControl 场景下特别容易踩。WPF 的 ItemsControl 在数据集合变化时，会复用已经生成过的容器元素，而不是全部销毁重建。复用的意思是，之前排在第 5 位的那个 Border，重新生成为第 2 位时，它身上的 Grid.Row 还残留着 4（因为之前被 AutoGrid 设置为 4）。
AutoGrid 的 AssignChildIndex 在每次 Measure 时都会重新计算所有子元素的位置，所以正常情况它能纠正这些残留值。但我在最初的版本里为了“优化性能”，只对新增的子元素设置位置，没有对已有子元素做校正，结果就是数据更新后卡片位置乱掉。
最终方案就是现在代码里的做法：每次 BuildStructure 都遍历所有子元素，计算期望的 Row 和 Column，先和当前值比较，不一样才设置。这样既不会因为反复 Set 触发额外布局，也能保证位置一定是正确的。
4.3 大数据量下的性能：AutoGrid 不虚拟化
AutoGrid 本身不继承 VirtualizingPanel，所以它不具备 UI 虚拟化能力。数据量在几十个以内的时候体感不明显，几百个的时候 Measure 和 Arrange 的时间会指数上升，上千个的时候界面基本上就卡得不能看了。
我实际项目里遇到过一次性加载 200 多个工位卡片的情况，打开页面的瞬间要等两秒钟，虽然能接受，但明显不够流畅。后来我换了个思路：上位机看板并不需要一次性展示所有工位，我可以让用户按产线筛选，或者加一个分页控件，一次只显示 30 个工位。这样 AutoGrid 的布局压力就降到了完全无感的水平。
如果你的场景确实需要大数据量网格并且要求流畅滚动，那不要指望 AutoGrid 能解决所有问题，考虑换成 VirtualizingStackPanel 配合 DataGrid，或者自己继承 VirtualizingPanel 重写虚拟化逻辑。那是一个更大的工程量，不适合塞进一个布局控件里。
5. 实战演示：上位机工位状态网格搭建
5.1 需求与字段设计
假设现场有 12 个工位，按 4 列布局，每张卡片显示设备名称、运行状态、关键参数。数据来自 MES 接口，可能是实时刷新的。工位数不固定，后续可能扩展到 16 台甚至更多。
这个场景如果用原生 Grid，每次数据刷新都要清空 Children 重建。用 AutoGrid 之后，后台只需要维护一个 ObservableCollection，界面自动响应。我整理一下要点：
- ViewModel 里设备卡片集合用 ObservableCollection，这是 WPF 数据绑定的标准做法。
- 卡片外观用 DataTemplate 定义，数据变化时通过属性通知刷新控件，布局部分完全不用管。
- AutoGrid 只负责按 4 列自动生成行，并把每个卡片放到对应的 Row 和 Column 上。
5.2 XAML 布局关键代码
完整可跑的 XAML 大概是下面这样，这里我加了 2 行简要注释：
<Window.Resources> <Style x:Key="StatusBorderStyle" TargetType="Border"> <Setter Property="CornerRadius" Value="4"/> <Setter Property="Padding" Value="10"/> <Setter Property="BorderThickness" Value="2"/> <Setter Property="Margin" Value="4"/> <Setter Property="Background" Value="White"/> </Style> </Window.Resources> <Grid> <ItemsControl ItemsSource="{Binding WorkCells}"> <ItemsControl.ItemsPanel> <ItemsPanelTemplate> <controls:AutoGrid Columns="4"/> </ItemsPanelTemplate> </ItemsControl.ItemsPanel> <ItemsControl.ItemTemplate> <DataTemplate> <Border Style="{StaticResource StatusBorderStyle}" BorderBrush="{Binding StatusColor}"> <StackPanel> <TextBlock Text="{Binding CellName}" FontSize="16" FontWeight="Bold"/> <TextBlock Text="{Binding StatusText}" Foreground="{Binding StatusColor}" Margin="0,6,0,0"/> <TextBlock Text="{Binding CurrentWorkOrder}" FontSize="12" Foreground="#666" Margin="0,4,0,0"/> </StackPanel> </Border> </DataTemplate> </ItemsControl.ItemTemplate> </ItemsControl> </Grid>5.3 后台数据刷新与线程处理
后台 ViewModel 里关键点如下。注意 ObservableCollection 的增删和属性更新必须发生在 UI 线程上，如果从后台线程拿到 PLC 数据，要用 Dispatcher 调度回 UI 线程：
public class WorkCellViewModel : INotifyPropertyChanged { public string CellName { get; set; } private string _statusText; public string StatusText { get => _statusText; set { _statusText = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(StatusText))); } } private Brush _statusColor; public Brush StatusColor { get => _statusColor; set { _statusColor = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(StatusColor))); } } public event PropertyChangedEventHandler PropertyChanged; } // 后台线程刷新示例，实际项目中建议封装一个 DispatcherHelper Application.Current.Dispatcher.Invoke(() => { cell.StatusText = "报警"; cell.StatusColor = Brushes.Red; });这里有个容易被忽略的问题：如果每次 PLC 刷新你都往集合里 RemoveAt/Add，AutoGrid 会频繁重建行列定义，虽然数据量不大时只是轻微卡顿，但高频刷新下还是会有明显开销。更合理的做法是只更新每个卡片对象的属性，让 WPF 走属性通知刷新 UI，而不是重新生成集合。
5.4 运行效果与在线调整
实际跑起来后，12 个工位在 4 列布局下会自动排成 3 行 4 列，每个卡片等比占满网格。如果某一天需求变成“工位分组展示，每组占一列”，我可以直接把 Columns 改成 3，或者设置 Rows 和 Orientation 来调整排列方向，改动量非常小。
如果你需要固定 2 行，比如大屏上只显示上下两排，可以直接这样写：
<controls:AutoGrid Rows="2" Orientation="Horizontal"/>这样 AutoGrid 会自动计算列数，所有卡片先从左到右填满第一行，再从左到右填满第二行。视觉上比横向滚动列表整齐得多，也不需要人肉数行数。
6. 还可以扩展的几个方向
6.1 支持字符串形式的行列权重配置
目前 AutoGrid 自动添加的行列都是1*，也就是等分。但实际布局经常有“左边这一列固定 300 像素，中间自适应，右边占两倍空间”的需求。一个比较实用的扩展，是给 AutoGrid 增加一个字符串类型的属性，比如RowDefinitionsSource="Auto,*,2*,100"，在 BuildStructure 的时候解析字符串，生成对应的 RowDefinition。
GridLengthConverter 可以直接把字符串转成 GridLength，代码量不大：
private GridLength ParseGridLength(string token) { var converter = new GridLengthConverter(); return (GridLength)converter.ConvertFromString(token.Trim()); }这个扩展建议保留我前面 EnsureRowDefinitions 的缓存逻辑，不要每次 Measure 都重新解析字符串，可以在属性变化回调里解析一次并缓存结果。
6.2 数据驱动的跨行跨列
AutoGrid 的常规用法是每个卡片占一个格子，但有些仪表盘需求是“某个重要指标卡要占两个格子”。配合数据绑定，可以让 ViewModel 里的某个卡片对象提供 RowSpan 和 ColumnSpan 属性，然后在 DataTemplate 里绑定：
<DataTemplate> <Border Grid.RowSpan="{Binding RowSpan}" Grid.ColumnSpan="{Binding ColumnSpan}" controls:AutoGrid.AutoIndex="False"> ... </Border> </DataTemplate>注意我特意设置了AutoIndex="False"，表示这个卡片不参与自动索引，它的 Row 和 Column 需要在 ViewModel 里手动指定。这样做的好处是卡片的位置和跨幅都由数据驱动，适合做中控大屏、数据驾驶舱这类灵活的宫格布局。
6.3 虚拟化与大数据量下的取舍
前面说过 AutoGrid 没有虚拟化能力。如果你确实要做几千个元素的网格，我的个人建议是不要强行扩展 AutoGrid，可以换个思路：
- 数据分页，每次只加载一页。
- 用 DataGrid 代替自定义卡片，DataGrid 自带虚拟化。
- 如果一定要自定义卡片网格，可以考虑自己实现一个继承 VirtualizingPanel 的控件，但这个工程量大得多，需要处理 IScrollInfo、容器回收、缓存等多个底层问题。
如果说这个控件还要再加一个最实用的功能，我会把行列权重字符串解析做了，因为实际项目里“等分”并不是万能答案，固定宽度加自适应混合的场景太常见了。至于跨行跨列的数据驱动和虚拟化，属于可选的进阶需求，看项目规模决定要不要投入。你现在拿到这份 AutoGrid 的实现，把前三章的核心代码读透，已经足够覆盖绝大多数上位机看板和动态卡片布局了。
