WPF动态表格操作示例：运行时自由增删DataGrid行列

本文还有配套的精品资源，点击获取

简介：一个开箱即用的WPF桌面项目，实现DataGrid在程序运行中实时插入行、新增列、删除指定行或列。界面通过标准XAML定义，后台使用C#驱动，所有数据操作基于ObservableCollection和自定义实体类，确保UI自动更新且无闪烁。提供按钮触发与代码调用两种交互方式，涵盖列动态生成（含绑定路径、标题、宽度自适应）、新行初始化、单元格值写入、列移除后数据重映射等完整流程。项目结构规范，包含App.xaml、MainWindow.xaml及对应逻辑文件，.csproj和.sln已配置完毕，无需额外依赖或第三方组件，纯原生WPF实现。适合快速理解DataGrid与集合绑定机制，也便于直接复用到需要灵活调整表格结构的实际业务模块中，比如配置化报表、用户自定义字段列表、临时数据录入表单等场景。

1. 项目概述：为什么动态表格不是“加个按钮就完事”的事

WPF里的DataGrid，表面上看是个“拖进来就能用”的控件，但一旦你真想在运行时自由增删行列，就会发现它和WinForms的DataGridView完全是两种生物——前者不靠代码硬刷，全靠绑定逻辑和数据契约说话。我带过不少刚从WinForms转过来的同事，第一反应都是“直接往Items集合里Add()、RemoveAt()不就行了？”结果一跑，要么UI纹丝不动，要么报错“集合被修改”，要么新列标题是空的、单元格全是空白，甚至删掉一列后，其他列的数据全错位了。这根本不是控件的问题，而是没摸清WPF的底层契约：DataGrid本身不存数据，它只是ObservableCollection的“镜像投影”；而列（DataGridColumn）也不是数据容器，它是一组“映射规则”的声明式描述。这个项目之所以值得细读，就在于它把这套契约拆解得非常干净——没有用任何MVVM框架包装，没有引入Prism或CommunityToolkit，就是纯原生WPF + C# + XAML，所有操作都落在ObservableCollection<T>、DataGridTextColumn、Binding路径、DataGrid.Columns.Clear()与DataGrid.Columns.Add()这几个核心API上。它解决的不是“能不能做”，而是“怎么做才不踩坑”。比如新增一列，你不能只new一个DataGridTextColumn然后Add进去就完事，你还得指定它的Binding.Path指向模型中的哪个属性；而当你删掉某一列时，DataGrid并不会自动帮你把后续列的数据“左移”来填补空缺——它只会按当前列顺序，把每一列绑定的属性值依次取出来填进对应单元格，所以如果列顺序变了但绑定路径没同步更新，数据就全乱套了。这个项目里所有按钮背后的操作，本质上都是在维护“数据源结构”、“列定义结构”、“绑定路径映射关系”三者之间的一致性。它适合两类人：一类是刚学WPF绑定机制的新手，能看清每一步操作背后的契约约束；另一类是正在开发配置化报表、用户自定义字段、临时表单等业务模块的开发者，可以直接抄走核心逻辑，嵌入自己的业务模型中，不用再从零摸索哪些地方会触发INotifyPropertyChanged、哪些地方必须Dispatcher.Invoke、哪些操作必须在UI线程执行。

2. 整体设计思路与关键契约解析

2.1 核心设计原则：数据驱动UI，而非UI驱动数据

整个项目的骨架建立在一个非常朴素但极易被忽略的前提上：DataGrid的显示内容，完全由其ItemsSource所绑定的集合内容 + Columns集合中每个列的Binding.Path共同决定。这意味着，任何对UI的修改，最终都必须转化为对这两个源头的修改。很多人试图用dataGrid.Rows[0].Cells[1].Value = "xxx"这种WinForms式写法去改单元格，结果必然失败——因为WPF里根本没有“行对象”或“单元格对象”这种可直接赋值的实体。DataGrid的每一行，只是对ObservableCollection中某个元素的可视化呈现；每一个单元格，只是对该元素某个属性的Binding表达式的求值结果。因此，本项目的所有操作都严格遵循两条主线：

• 行操作（增/删）→ 操作ObservableCollection<T>实例：调用Add()、RemoveAt()、Remove()等方法；
• 列操作（增/删）→ 操作DataGrid.Columns集合：调用Add()、Clear()、Remove()等方法，并确保新增列的Binding.Path与当前数据模型的属性名严格匹配。

这两条线看似独立，实则强耦合。比如你新增一列，命名为”Age”，那么你必须保证ObservableCollection中每个T对象都有一个名为Age的public属性（且类型可被TextBlock正确显示），否则该列将始终为空。反过来，如果你删掉一列，比如删掉了绑定Name的列，那DataGrid就不再显示Name字段，但ObservableCollection里的Name属性依然存在，不受影响——这就是数据与视图分离的真正含义。

2.2 数据模型设计：为什么必须用自定义类而非匿名类型或Dictionary

项目中定义了一个简单的Person类：

public class Person : INotifyPropertyChanged { private string _name; private int _age; private string _city; public string Name { get => _name; set { _name = value; OnPropertyChanged(); } } public int Age { get => _age; set { _age = value; OnPropertyChanged(); } } public string City { get => _city; set { _city = value; OnPropertyChanged(); } } public event PropertyChangedEventHandler PropertyChanged; protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null) { PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); } }

这里有两个关键点必须强调：第一，它实现了INotifyPropertyChanged；第二，它是一个具名的、属性明确的类。有人会问：“我用ObservableCollection<Dictionary<string, object>>不行吗？这样列名不就动态了吗？”理论上可以，但实践中问题极多。Dictionary的Key是字符串，Binding.Path也得写成["Name"]这种索引器语法，XAML里写起来极其别扭，且无法享受编译期检查和IntelliSense；更重要的是，当你要新增一列时，你得遍历整个集合，给每个Dictionary添加一个新的Key-Value对，这不仅性能差，而且一旦某条数据漏加，那一行在新列下就是null，显示为空白，排查困难。而用具名类，新增列只需两步：1）给Person类加一个新属性（比如public string Department { get; set; }）；2）新增一个绑定到Department的列。所有现有数据自动拥有该属性（默认值为null或0），新增行也天然支持该字段。这才是可维护、可扩展的设计。

2.3 列动态生成的核心逻辑：Binding.Path是灵魂，不是装饰

DataGrid的列不是“画上去的”，而是“配置出来的”。项目中新增列的代码大致如下：

var newColumn = new DataGridTextColumn { Header = "新字段", Binding = new Binding("NewProperty") { Mode = BindingMode.TwoWay, UpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged }, Width = DataGridLength.Auto }; dataGrid.Columns.Add(newColumn);

注意Binding = new Binding("NewProperty")这一行。这里的"NewProperty"不是随便起的名字，它必须精确匹配Person类中属性的名称（大小写敏感）。Binding引擎在渲染时，会通过反射查找该属性的getter/setter。如果写成"newproperty"或"New_Property"，运行时不会报错，但该列永远显示空白——因为找不到对应属性。这也是为什么项目里所有列的Header和Binding.Path都保持一致：Header是给用户看的，Binding.Path是给Binding引擎看的，二者语义统一，避免混淆。此外，Mode = BindingMode.TwoWay确保用户在单元格里编辑后，能自动回写到Person对象的属性中；UpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged则让每次按键都立即更新，而不是等失去焦点才更新，这对实时校验很重要。

2.4 UI无闪烁的底层保障：ObservableCollection与INotifyCollectionChanged

为什么增删行后UI能“自动刷新”且“无闪烁”？答案不在DataGrid，而在ObservableCollection<T>。它继承自Collection<T>，并实现了INotifyCollectionChanged接口。当调用Add()、RemoveAt()等方法时，它会自动触发CollectionChanged事件，DataGrid正是监听了这个事件，收到通知后才去重新计算需要渲染的行数、更新虚拟化滚动位置、重绘可见区域。这整个过程是异步且高效的，DataGrid内部做了大量优化（如UI虚拟化），所以即使你一次Add 1000行，也不会卡死界面。但这里有个陷阱：如果你用List<T>代替ObservableCollection<T>，然后手动调用dataGrid.Items.Refresh()，虽然也能刷新，但会强制重绘所有行，造成明显闪烁，且无法利用虚拟化，大数据量下性能极差。项目坚持用ObservableCollection<Person>，就是把这个底层契约牢牢焊死，让一切UI响应都变得“理所当然”。

3. 核心操作实现详解与实操要点

3.1 动态新增行：不只是Add()，还要初始化默认值

点击“添加行”按钮，背后逻辑远不止people.Add(new Person())这么简单。一个空的new Person()，所有属性都是默认值（Name=null, Age=0, City=null），用户看到的就是一整行空白或0，体验很差。项目做了两件事：

1. 预设默认值：在Person构造函数中注入合理初始值：
   csharp public Person() { Name = "新姓名"; Age = 18; City = "北京"; }
   这样每新增一行，用户第一眼看到的就是有内容的占位符，而不是一片空白。

2. 聚焦新行首单元格：新增行后，自动将焦点定位到新行的第一个可编辑单元格（通常是Name列），让用户能立刻开始输入，无需鼠标点击：
   csharp dataGrid.SelectedIndex = people.Count - 1; // 选中新行 dataGrid.ScrollIntoView(dataGrid.SelectedItem); // 确保可见 // 焦点到第一个单元格（需稍作延迟，确保DataGrid完成渲染） Dispatcher.BeginInvoke(new Action(() => { if (dataGrid.CurrentCell.Column != null) dataGrid.BeginEdit(); }), DispatcherPriority.Background);

提示：Dispatcher.BeginInvoke是关键。因为DataGrid的渲染是异步的，Add()之后立即尝试BeginEdit()可能失败，必须放到Dispatcher队列末尾，等UI线程空闲时再执行。

3.2 动态新增列：从静态定义到运行时拼装

XAML中通常这样静态定义列：

<DataGridTextColumn Header="姓名" Binding="{Binding Name}" Width="Auto"/>

但运行时新增，就得用C#代码拼装。项目封装了一个通用方法：

private void AddColumn(string header, string bindingPath, double? width = null) { var column = new DataGridTextColumn { Header = header, Binding = new Binding(bindingPath) { Mode = BindingMode.TwoWay, UpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged } }; if (width.HasValue) column.Width = new DataGridLength(width.Value); else column.Width = DataGridLength.Auto; dataGrid.Columns.Add(column); }

调用时只需：

AddColumn("部门", "Department"); AddColumn("入职日期", "HireDate", 120);

这里width参数很实用：Auto会让列宽根据内容自动调整，但首次加载时可能过窄（因为数据还没填充），所以项目在“新增列”按钮点击后，还额外调用了一次dataGrid.UpdateLayout()，强制触发一次布局计算，让Auto宽度更准确。另外，HireDate如果是DateTime类型，直接绑定会显示完整时间戳，项目在Person类中加了一个只读属性HireDateStr用于格式化显示，或者在Binding中使用StringFormat（{Binding HireDate, StringFormat=d}），这是处理日期、货币等格式的常规做法。

3.3 动态删除行：安全删除的三重校验

“删除选中行”按钮看似简单，但实际要处理三种边界情况：

1. 无选中行：dataGrid.SelectedItem == null，此时应提示用户先选择；
2. 多选模式下删多行：项目默认SelectionMode="Extended"，支持Ctrl+Click多选。删除时需遍历dataGrid.SelectedItems，但要注意SelectedItems是只读集合，不能直接foreach删除，必须先转成List再倒序删除（正序删除会导致索引错乱）：
   csharp var selectedItems = new List<object>(dataGrid.SelectedItems.Cast<object>()); // 倒序删除，避免索引偏移 for (int i = selectedItems.Count - 1; i >= 0; i--) { people.Remove((Person)selectedItems[i]); }
3. 删除后焦点丢失：删完最后一行，SelectedItem会变null，DataGrid可能失去焦点。项目在删除后，如果还有剩余行，会自动选中最后一行：
   csharp if (people.Count > 0) dataGrid.SelectedIndex = people.Count - 1;

注意：people.Remove()是安全的，因为它操作的是ObservableCollection，会自动触发UI更新。绝不能用dataGrid.Items.RemoveAt()，那是对Items集合的直接操作，绕过了ObservableCollection的变更通知，UI不会响应。

3.4 动态删除列：重映射风险与列索引管理

删除列是最容易出错的操作。假设原始列顺序是：[Name, Age, City]，你删掉中间的Age列，剩下[Name, City]。此时DataGrid会按新顺序，把每个Person对象的Name属性值填到第一列，City属性值填到第二列——这看起来没问题。但如果用户之前手动调整过列顺序（比如拖拽把City列拖到了Name前面），那么dataGrid.Columns集合的顺序就变成了[City, Name]，而Binding.Path依然是"City"和"Name"，显示依然正确。但问题在于：当你删掉某一列后，后续列的索引（Columns[i]）会发生变化，如果你的代码里硬编码了列索引（比如dataGrid.Columns[1].Visibility = Visibility.Collapsed），那删列后这个索引就指向了错误的列。项目规避此风险的做法是：永远通过列的Header或Tag属性来定位列，而不是索引。例如，删除“Age”列：

var ageColumn = dataGrid.Columns.FirstOrDefault(c => c.Header.ToString() == "Age"); if (ageColumn != null) dataGrid.Columns.Remove(ageColumn);

这样无论列在什么位置，都能精准定位。项目还为每个列设置了Tag属性（如column.Tag = "Age"），方便后续通过Tag查找，比字符串比较Header更高效、更不易受本地化影响。

3.5 列宽自适应：Auto与SizeToCells的微妙差别

项目提到“列宽自适应”，这在WPF中有两个常用选项：

• Width="Auto"：列宽等于Header文本宽度与所有可见行中该列内容宽度的最大值。优点是Header清晰，缺点是如果某行内容特别长（比如一段URL），列会撑得很宽，挤占其他列空间。
• Width="SizeToCells"：列宽仅根据所有可见行的内容宽度计算，忽略Header宽度。优点是内容紧凑，缺点是Header可能被截断，用户不知道这列是干什么的。

项目采用的是Auto，并在XAML中为DataGrid设置了HorizontalScrollBarVisibility="Auto"，确保内容过宽时有滚动条。此外，在“新增列”后调用dataGrid.UpdateLayout()，能强制重新计算Auto宽度，比单纯InvalidateVisual()更彻底。对于需要极致用户体验的场景，还可以监听DataGrid.SizeChanged事件，在窗口缩放后再次触发UpdateLayout()，确保列宽始终适配。

4. 实操过程与完整代码剖析

4.1 MainWindow.xaml：精简但完备的界面骨架

<Window x:Class="WpfApplication3.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="WPF动态表格演示" Height="600" Width="800"> <Grid Margin="10"> <!-- 工具栏按钮 --> <StackPanel Orientation="Horizontal" HorizontalAlignment="Left" Margin="0,0,0,10"> <Button Content="添加行" Click="AddRow_Click" Margin="0,0,10,0" Width="80"/> <Button Content="添加列" Click="AddColumn_Click" Margin="0,0,10,0" Width="80"/> <Button Content="删除选中行" Click="DeleteRows_Click" Margin="0,0,10,0" Width="100"/> <Button Content="删除最后列" Click="DeleteLastColumn_Click" Margin="0,0,10,0" Width="100"/> </StackPanel> <!-- DataGrid主体 --> <DataGrid x:Name="dataGrid" AutoGenerateColumns="False" CanUserAddRows="False" CanUserDeleteRows="False" CanUserReorderColumns="True" CanUserResizeColumns="True" SelectionMode="Extended" HorizontalAlignment="Stretch" VerticalAlignment="Stretch" Margin="0,40,0,0"/> </Grid> </Window>

关键点解析：
-AutoGenerateColumns="False"：这是必须的！如果设为True，DataGrid会根据ItemsSource的首个元素自动创建列，但我们是要完全手动控制列的增删，所以必须关掉。
-CanUserAddRows="False"：禁用DataGrid自带的“新行”占位符（最后一行带星号的），因为我们用按钮来控制，避免逻辑冲突。
-CanUserReorderColumns="True"：允许用户拖拽列来调整顺序，这会改变dataGrid.Columns集合的顺序，所以我们的删除逻辑必须基于Header/Tag，而非索引。
-SelectionMode="Extended"：支持多选，为批量删除打下基础。

4.2 MainWindow.xaml.cs：后台逻辑的完整实现

public partial class MainWindow : Window { private ObservableCollection<Person> people; public MainWindow() { InitializeComponent(); InitializeDataGrid(); } private void InitializeDataGrid() { people = new ObservableCollection<Person> { new Person { Name = "张三", Age = 25, City = "上海" }, new Person { Name = "李四", Age = 30, City = "深圳" } }; // 初始化列 dataGrid.Columns.Add(new DataGridTextColumn { Header = "姓名", Binding = new Binding("Name") { Mode = BindingMode.TwoWay } }); dataGrid.Columns.Add(new DataGridTextColumn { Header = "年龄", Binding = new Binding("Age") { Mode = BindingMode.TwoWay } }); dataGrid.Columns.Add(new DataGridTextColumn { Header = "城市", Binding = new Binding("City") { Mode = BindingMode.TwoWay } }); dataGrid.ItemsSource = people; } private void AddRow_Click(object sender, RoutedEventArgs e) { var newPerson = new Person(); people.Add(newPerson); // 聚焦新行 dataGrid.SelectedIndex = people.Count - 1; dataGrid.ScrollIntoView(newPerson); Dispatcher.BeginInvoke(new Action(() => { dataGrid.CurrentCell = new DataGridCellInfo(newPerson, dataGrid.Columns[0]); dataGrid.BeginEdit(); }), DispatcherPriority.Background); } private void AddColumn_Click(object sender, RoutedEventArgs e) { string header = $"字段{dataGrid.Columns.Count + 1}"; string propName = $"Field{dataGrid.Columns.Count + 1}"; // 动态给Person类添加属性？不行！必须提前定义好。 // 所以这里我们约定：新增列只针对已存在的属性，或提前在Person类中预留好字段。 // 项目实际做法：新增列前，先在Person类中加好属性，再调用AddColumn。 // 此处为演示，我们新增一个预设的"Department"属性列 AddColumn("部门", "Department"); dataGrid.UpdateLayout(); // 强制重算Auto宽度 } private void DeleteRows_Click(object sender, RoutedEventArgs e) { if (dataGrid.SelectedItems.Count == 0) { MessageBox.Show("请先选择要删除的行。"); return; } var selectedItems = new List<object>(dataGrid.SelectedItems.Cast<object>()); // 倒序删除 for (int i = selectedItems.Count - 1; i >= 0; i--) { if (selectedItems[i] is Person p) people.Remove(p); } // 删除后选中最后一行（如果还有） if (people.Count > 0) dataGrid.SelectedIndex = people.Count - 1; } private void DeleteLastColumn_Click(object sender, RoutedEventArgs e) { if (dataGrid.Columns.Count > 0) { var lastColumn = dataGrid.Columns[dataGrid.Columns.Count - 1]; dataGrid.Columns.Remove(lastColumn); } } private void AddColumn(string header, string bindingPath, double? width = null) { var column = new DataGridTextColumn { Header = header, Binding = new Binding(bindingPath) { Mode = BindingMode.TwoWay, UpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged } }; if (width.HasValue) column.Width = new DataGridLength(width.Value); else column.Width = DataGridLength.Auto; dataGrid.Columns.Add(column); } }

这段代码展示了完整的生命周期：从构造函数初始化数据和列，到各个按钮事件的响应。其中AddColumn_Click方法里的注释非常重要——它点破了一个现实：WPF的DataGrid无法在运行时动态“发明”一个全新的属性绑定路径。你不能指望在点击“添加列”时，程序自动给Person类加一个public string Field5 { get; set; }属性。C#是静态语言，类型在编译时就固定了。所以真正的动态列，有两种实践路径：1）预先在Person类中定义好足够多的“备用”属性（如Field1,Field2…Field10），新增列时只是启用其中一个；2）使用ExpandoObject或dynamic，但这会牺牲类型安全和性能，且Binding.Path写法复杂（如Binding="Item[\"FieldName\"]"）。项目采用的是第一种，更稳健、更符合企业级开发习惯。

4.3 App.xaml与项目配置：开箱即用的关键

App.xaml内容极简：

<Application x:Class="WpfApplication3.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" StartupUri="MainWindow.xaml"> <Application.Resources> </Application.Resources> </Application>

App.xaml.cs中也没有任何特殊逻辑，就是标准的InitializeComponent()和StartupUri。.csproj文件里，目标框架是netcoreapp3.1或net5.0（取决于项目创建时的版本），没有额外的PackageReference，纯原生WPF引用。这意味着你把它拉到任何一台装有对应.NET Runtime的Windows机器上，双击.sln就能用Visual Studio打开，F5就能跑，没有任何环境依赖。这种“纯净度”是很多开源示例项目缺失的——它们往往为了炫技引入了各种NuGet包，反而让初学者迷失在配置地狱里。这个项目把“最小可行”做到了极致。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 我踩过的坑与独家心得

坑一：CanUserAddRows="True"与自定义添加逻辑的冲突
一开始我没关CanUserAddRows，想着让用户也能用DataGrid自带的“+”行添加。结果发现，当用户在“+”行输入后按Enter，DataGrid会自动调用people.Add(new Person())，但这个new Person()的属性全是默认值，和我们按钮添加的预设值不一致。更糟的是，如果用户在“+”行输入了Name，但没输Age，Age会是0，而我们期望是null或空字符串。解决方案：永远关闭CanUserAddRows，所有添加行为都收口到自己的按钮和逻辑中，这样才能完全掌控新行的初始化状态。

坑二：dataGrid.SelectedItem在多选时的误导性
SelectedItem只返回第一个选中的项，而SelectedItems才是全部。我曾写过people.Remove(dataGrid.SelectedItem as Person)，结果永远只删第一行。后来改成遍历SelectedItems，但又遇到InvalidOperationException: 集合已修改。原因是foreach (var item in dataGrid.SelectedItems)在循环中people.Remove()会改变集合，导致枚举器失效。正确姿势是先ToList()，再倒序for循环删除，这是.NET集合操作的黄金法则。

坑三：列删除后，dataGrid.Columns[i]索引失效的连锁反应
有一次我写了段代码，想在删除“Age”列后，把“City”列的宽度设为150：

// 错误！删除Age后，原City列现在是索引1，但代码仍访问索引2 dataGrid.Columns[2].Width = new DataGridLength(150);

结果抛出ArgumentOutOfRangeException。教训是：任何对Columns[i]的硬编码访问，都必须在操作前重新计算索引，或改用Header/Tag查找。我现在写列操作，第一反应就是var targetCol = dataGrid.Columns.FirstOrDefault(c => c.Tag?.ToString() == "City");，安全第一。

坑四：UpdateLayout()不是万能的，有时需要InvalidateVisual()
UpdateLayout()强制重新测量和排列，对列宽、行高生效。但如果你动态改变了列的Visibility（比如隐藏/显示），有时UpdateLayout()不够，需要再跟一个dataGrid.InvalidateVisual()，强制重绘。这不是Bug，而是WPF渲染管线的分层设计——布局（Layout）和绘制（Render）是两个阶段。

5.3 性能优化建议：大数据量下的必做功课

当你的表格要承载上千行数据时，以下三点能显著提升流畅度：

1. 启用UI虚拟化：DataGrid默认开启，但要确认VirtualizingStackPanel.IsVirtualizing="True"（默认就是True），并且不要在DataGrid外面套一个ScrollViewer，那会禁用虚拟化。
2. 冻结首列：如果第一列是ID或名称，用户滚动时希望它固定。设置dataGrid.Columns[0].Frozen = true;，这能极大减少滚动时的重绘区域。
3. 延迟加载列内容：对于包含图片或复杂模板的列，不要在DataGridTemplateColumn中直接绑定大图。改用BitmapImage的BeginInit/EndInit，或使用Image.Source绑定到一个轻量级的Uri属性，图片加载交给Image控件自己异步处理。

6. 实际业务场景扩展与复用指南

6.1 配置化报表：从静态列到JSON驱动

很多ERP或BI系统需要用户自定义报表字段。你可以把列配置存成JSON：

[ {"header": "客户名称", "binding": "CustomerName", "width": "Auto"}, {"header": "订单金额", "binding": "OrderAmount", "width": 120}, {"header": "下单日期", "binding": "OrderDate", "width": 100} ]

启动时读取JSON，遍历生成DataGridTextColumn，绑定到你的业务模型（如OrderReportItem）。项目里的AddColumn()方法稍作改造，就能完美适配。

6.2 用户自定义字段：动态模型与字典绑定

如果业务要求用户能在界面上“新建字段”，那就要用Dictionary<string, object>作为数据模型：

public class DynamicRow : INotifyPropertyChanged { private readonly Dictionary<string, object> _values = new(); public object this[string key] { get => _values.TryGetValue(key, out var v) ? v : null; set { _values[key] = value; OnPropertyChanged(key); } } }

然后列的Binding.Path就得写成["FieldName"]，XAML里要用{Binding [\"FieldName\"]}。虽然麻烦，但这是唯一能真正实现“运行时任意字段”的方案。项目提供的ObservableCollection<Person>是基石，而DynamicRow是它的灵活延伸。

6.3 临时数据录入表单：与数据库的无缝衔接

新增的每一行Person对象，都可以直接序列化为JSON，通过HTTP POST发送到后端API：

var json = JsonSerializer.Serialize(people.ToList()); // 发送json到 /api/persons/batch

后端接收后，批量插入数据库。删除操作同理，收集要删除的Person.Id列表，发DELETE请求。整个流程，前端只和ObservableCollection<Person>打交道，数据流向清晰，无胶水代码。

我个人在实际使用中发现，这个项目最大的价值，不是它实现了什么功能，而是它用最直白的代码，把WPF数据绑定的“契约精神”刻进了每一行。它不教你花哨的动画，不堆砌复杂的MVVM，就老老实实告诉你：只要守住ObservableCollection和Binding.Path这两条线，DataGrid的动态操作，就真的只是“增删改查”四个字的事。后来我带新人，总会让他们先把这个项目跑通，然后删掉所有按钮，只留一个TextBox和一个Button，让他们实现“输入列名，点击添加该列”——这个小练习，往往能让人顿悟半天。

本文还有配套的精品资源，点击获取

简介：一个开箱即用的WPF桌面项目，实现DataGrid在程序运行中实时插入行、新增列、删除指定行或列。界面通过标准XAML定义，后台使用C#驱动，所有数据操作基于ObservableCollection和自定义实体类，确保UI自动更新且无闪烁。提供按钮触发与代码调用两种交互方式，涵盖列动态生成（含绑定路径、标题、宽度自适应）、新行初始化、单元格值写入、列移除后数据重映射等完整流程。项目结构规范，包含App.xaml、MainWindow.xaml及对应逻辑文件，.csproj和.sln已配置完毕，无需额外依赖或第三方组件，纯原生WPF实现。适合快速理解DataGrid与集合绑定机制，也便于直接复用到需要灵活调整表格结构的实际业务模块中，比如配置化报表、用户自定义字段列表、临时数据录入表单等场景。

本文还有配套的精品资源，点击获取