本文还有配套的精品资源点击获取简介一个开箱即用的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所有操作都落在ObservableCollectionT、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表达式的求值结果。因此本项目的所有操作都严格遵循两条主线行操作增/删→ 操作ObservableCollectionT实例调用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第二它是一个具名的、属性明确的类。有人会问“我用ObservableCollectionDictionarystring, 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而在ObservableCollectionT。它继承自CollectionT并实现了INotifyCollectionChanged接口。当调用Add()、RemoveAt()等方法时它会自动触发CollectionChanged事件DataGrid正是监听了这个事件收到通知后才去重新计算需要渲染的行数、更新虚拟化滚动位置、重绘可见区域。这整个过程是异步且高效的DataGrid内部做了大量优化如UI虚拟化所以即使你一次Add 1000行也不会卡死界面。但这里有个陷阱如果你用ListT代替ObservableCollectionT然后手动调用dataGrid.Items.Refresh()虽然也能刷新但会强制重绘所有行造成明显闪烁且无法利用虚拟化大数据量下性能极差。项目坚持用ObservableCollectionPerson就是把这个底层契约牢牢焊死让一切UI响应都变得“理所当然”。3. 核心操作实现详解与实操要点3.1 动态新增行不只是Add()还要初始化默认值点击“添加行”按钮背后逻辑远不止people.Add(new Person())这么简单。一个空的new Person()所有属性都是默认值Namenull, Age0, Citynull用户看到的就是一整行空白或0体验很差。项目做了两件事预设默认值在Person构造函数中注入合理初始值csharp public Person() { Name 新姓名; Age 18; City 北京; }这样每新增一行用户第一眼看到的就是有内容的占位符而不是一片空白。聚焦新行首单元格新增行后自动将焦点定位到新行的第一个可编辑单元格通常是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} WidthAuto/但运行时新增就得用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, StringFormatd}这是处理日期、货币等格式的常规做法。3.3 动态删除行安全删除的三重校验“删除选中行”按钮看似简单但实际要处理三种边界情况无选中行dataGrid.SelectedItem null此时应提示用户先选择多选模式下删多行项目默认SelectionModeExtended支持CtrlClick多选。删除时需遍历dataGrid.SelectedItems但要注意SelectedItems是只读集合不能直接foreach删除必须先转成List再倒序删除正序删除会导致索引错乱csharp var selectedItems new Listobject(dataGrid.SelectedItems.Castobject()); // 倒序删除避免索引偏移 for (int i selectedItems.Count - 1; i 0; i--) { people.Remove((Person)selectedItems[i]); }删除后焦点丢失删完最后一行SelectedItem会变nullDataGrid可能失去焦点。项目在删除后如果还有剩余行会自动选中最后一行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中有两个常用选项WidthAuto列宽等于Header文本宽度与所有可见行中该列内容宽度的最大值。优点是Header清晰缺点是如果某行内容特别长比如一段URL列会撑得很宽挤占其他列空间。WidthSizeToCells列宽仅根据所有可见行的内容宽度计算忽略Header宽度。优点是内容紧凑缺点是Header可能被截断用户不知道这列是干什么的。项目采用的是Auto并在XAML中为DataGrid设置了HorizontalScrollBarVisibilityAuto确保内容过宽时有滚动条。此外在“新增列”后调用dataGrid.UpdateLayout()能强制重新计算Auto宽度比单纯InvalidateVisual()更彻底。对于需要极致用户体验的场景还可以监听DataGrid.SizeChanged事件在窗口缩放后再次触发UpdateLayout()确保列宽始终适配。4. 实操过程与完整代码剖析4.1 MainWindow.xaml精简但完备的界面骨架Window x:ClassWpfApplication3.MainWindow xmlnshttp://schemas.microsoft.com/winfx/2006/xaml/presentation xmlns:xhttp://schemas.microsoft.com/winfx/2006/xaml TitleWPF动态表格演示 Height600 Width800 Grid Margin10 !-- 工具栏按钮 -- StackPanel OrientationHorizontal HorizontalAlignmentLeft Margin0,0,0,10 Button Content添加行 ClickAddRow_Click Margin0,0,10,0 Width80/ Button Content添加列 ClickAddColumn_Click Margin0,0,10,0 Width80/ Button Content删除选中行 ClickDeleteRows_Click Margin0,0,10,0 Width100/ Button Content删除最后列 ClickDeleteLastColumn_Click Margin0,0,10,0 Width100/ /StackPanel !-- DataGrid主体 -- DataGrid x:NamedataGrid AutoGenerateColumnsFalse CanUserAddRowsFalse CanUserDeleteRowsFalse CanUserReorderColumnsTrue CanUserResizeColumnsTrue SelectionModeExtended HorizontalAlignmentStretch VerticalAlignmentStretch Margin0,40,0,0/ /Grid /Window关键点解析-AutoGenerateColumnsFalse这是必须的如果设为TrueDataGrid会根据ItemsSource的首个元素自动创建列但我们是要完全手动控制列的增删所以必须关掉。-CanUserAddRowsFalse禁用DataGrid自带的“新行”占位符最后一行带星号的因为我们用按钮来控制避免逻辑冲突。-CanUserReorderColumnsTrue允许用户拖拽列来调整顺序这会改变dataGrid.Columns集合的顺序所以我们的删除逻辑必须基于Header/Tag而非索引。-SelectionModeExtended支持多选为批量删除打下基础。4.2 MainWindow.xaml.cs后台逻辑的完整实现public partial class MainWindow : Window { private ObservableCollectionPerson people; public MainWindow() { InitializeComponent(); InitializeDataGrid(); } private void InitializeDataGrid() { people new ObservableCollectionPerson { 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 Listobject(dataGrid.SelectedItems.Castobject()); // 倒序删除 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写法复杂如BindingItem[\FieldName\]。项目采用的是第一种更稳健、更符合企业级开发习惯。4.3 App.xaml与项目配置开箱即用的关键App.xaml内容极简Application x:ClassWpfApplication3.App xmlnshttp://schemas.microsoft.com/winfx/2006/xaml/presentation xmlns:xhttp://schemas.microsoft.com/winfx/2006/xaml StartupUriMainWindow.xaml Application.Resources /Application.Resources /ApplicationApp.xaml.cs中也没有任何特殊逻辑就是标准的InitializeComponent()和StartupUri。.csproj文件里目标框架是netcoreapp3.1或net5.0取决于项目创建时的版本没有额外的PackageReference纯原生WPF引用。这意味着你把它拉到任何一台装有对应.NET Runtime的Windows机器上双击.sln就能用Visual Studio打开F5就能跑没有任何环境依赖。这种“纯净度”是很多开源示例项目缺失的——它们往往为了炫技引入了各种NuGet包反而让初学者迷失在配置地狱里。这个项目把“最小可行”做到了极致。5. 常见问题与排查技巧实录5.1 典型问题速查表问题现象可能原因排查与解决方法新增行后DataGrid没显示新行或显示空白ItemsSource未正确绑定或ObservableCollection未赋值给dataGrid.ItemsSource检查InitializeDataGrid()中是否执行了dataGrid.ItemsSource people;用调试器查看dataGrid.ItemsSource是否为null确认people集合Add后Count是否增加。新增列后该列始终显示空白Binding.Path写错大小写、拼写或Person类中没有对应属性或属性不是public在XAML中临时加一个TextBlock Text{Binding PathYourPropertyName}放在窗口里看能否显示用反射检查typeof(Person).GetProperty(YourPropertyName)是否返回null。删除行后UI没刷新或报错“集合被修改”直接操作了dataGrid.Items而非ObservableCollection或在非UI线程调用了Add/Remove确保所有集合操作都发生在people实例上检查调用栈确认事件处理函数是否在UI线程WPF事件默认在UI线程若从后台线程调用必须用Dispatcher.Invoke。列宽Auto后内容被截断或Header被挤没了Auto宽度计算时机不对或DataGrid未获得足够渲染空间在AddColumn()后立即调用dataGrid.UpdateLayout()检查父容器如Grid的Margin、Padding是否过大挤压了DataGrid可用空间用Snoop工具查看实际渲染宽度。用户编辑单元格后Person对象的属性没更新Binding.Mode不是TwoWay或UpdateSourceTrigger不是PropertyChanged或Person属性setter中没调用OnPropertyChanged()检查Binding定义在Person属性setter中加断点确认是否被调用确认INotifyPropertyChanged事件是否被正确订阅DataGrid会自动订阅。5.2 我踩过的坑与独家心得坑一CanUserAddRowsTrue与自定义添加逻辑的冲突一开始我没关CanUserAddRows想着让用户也能用DataGrid自带的“”行添加。结果发现当用户在“”行输入后按EnterDataGrid会自动调用people.Add(new Person())但这个new Person()的属性全是默认值和我们按钮添加的预设值不一致。更糟的是如果用户在“”行输入了Name但没输AgeAge会是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 性能优化建议大数据量下的必做功课当你的表格要承载上千行数据时以下三点能显著提升流畅度启用UI虚拟化DataGrid默认开启但要确认VirtualizingStackPanel.IsVirtualizingTrue默认就是True并且不要在DataGrid外面套一个ScrollViewer那会禁用虚拟化。冻结首列如果第一列是ID或名称用户滚动时希望它固定。设置dataGrid.Columns[0].Frozen true;这能极大减少滚动时的重绘区域。延迟加载列内容对于包含图片或复杂模板的列不要在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 用户自定义字段动态模型与字典绑定如果业务要求用户能在界面上“新建字段”那就要用Dictionarystring, object作为数据模型public class DynamicRow : INotifyPropertyChanged { private readonly Dictionarystring, 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\]}。虽然麻烦但这是唯一能真正实现“运行时任意字段”的方案。项目提供的ObservableCollectionPerson是基石而DynamicRow是它的灵活延伸。6.3 临时数据录入表单与数据库的无缝衔接新增的每一行Person对象都可以直接序列化为JSON通过HTTP POST发送到后端APIvar json JsonSerializer.Serialize(people.ToList()); // 发送json到 /api/persons/batch后端接收后批量插入数据库。删除操作同理收集要删除的Person.Id列表发DELETE请求。整个流程前端只和ObservableCollectionPerson打交道数据流向清晰无胶水代码。我个人在实际使用中发现这个项目最大的价值不是它实现了什么功能而是它用最直白的代码把WPF数据绑定的“契约精神”刻进了每一行。它不教你花哨的动画不堆砌复杂的MVVM就老老实实告诉你只要守住ObservableCollection和Binding.Path这两条线DataGrid的动态操作就真的只是“增删改查”四个字的事。后来我带新人总会让他们先把这个项目跑通然后删掉所有按钮只留一个TextBox和一个Button让他们实现“输入列名点击添加该列”——这个小练习往往能让人顿悟半天。本文还有配套的精品资源点击获取简介一个开箱即用的WPF桌面项目实现DataGrid在程序运行中实时插入行、新增列、删除指定行或列。界面通过标准XAML定义后台使用C#驱动所有数据操作基于ObservableCollection和自定义实体类确保UI自动更新且无闪烁。提供按钮触发与代码调用两种交互方式涵盖列动态生成含绑定路径、标题、宽度自适应、新行初始化、单元格值写入、列移除后数据重映射等完整流程。项目结构规范包含App.xaml、MainWindow.xaml及对应逻辑文件.csproj和.sln已配置完毕无需额外依赖或第三方组件纯原生WPF实现。适合快速理解DataGrid与集合绑定机制也便于直接复用到需要灵活调整表格结构的实际业务模块中比如配置化报表、用户自定义字段列表、临时数据录入表单等场景。本文还有配套的精品资源点击获取