直接赋值 DataGridView.DataSource 会丢失列设置，应使用 BindingSource 作为中间层并更新其 DataSource 属性，或手动保存还原列配置；刷新需确保数据源支持通知机制且操作在 UI 线程执行。
DataGridView.DataSource 直接赋值会丢失列设置
直接给 DataGridView.DataSource 赋新数据（比如新 DataTable 或 List<T>）后，表格自动重生成列，原有列宽、可见性、排序、编辑模式等全部失效——这不是 Bug，是默认行为。
解决方法只有两个方向：
- 用
BindingSource作为中间层，只调用ResetBindings()或更新其DataSource属性（推荐） - 手动维护列定义：先保存原列配置（
DisplayIndex、Width、Visible等），再重新绑定后逐列还原
前者更安全。示例：
private BindingSource bs = new BindingSource();<br>bs.DataSource = GetInitialData();<br>dataGridView1.DataSource = bs;<br>// 刷新时：<br>bs.DataSource = GetUpdatedData(); // 自动触发 UI 更新
刷新时调用 Refresh() 没用，根本原因在数据源没变
DataGridView.Refresh() 只强制重绘控件本身，不检测数据变化。如果 DataSource 是普通 List<T> 或 DataTable，改了内容但没通知控件，UI 就不会更新。
必须让数据源支持变更通知：
- 用
BindingList<T>替代List<T>（支持Add/Remove通知） - 用
DataTable（自带INotifyPropertyChanged兼容性） - 自定义类需实现
INotifyPropertyChanged，且属性 setter 中触发事件
常见错误：把 List<User> 赋给 DataSource，然后只改 User.Name 字段——UI 不响应，因为没通知机制。
BindingSource.ResetCurrentItem() 和 ResetBindings() 的区别
这两个方法常被混淆：
-
ResetCurrentItem()：只刷新当前选中行的显示（比如某字段在后台被改了，但其他行不变） -
ResetBindings()：强制整个控件重新读取所有绑定字段，适用于数据源对象内部属性变更后整体刷新
注意：ResetBindings() 对 BindingList<T> 无效——它依赖的是集合变更事件，不是绑定刷新；而对 BindingSource 包裹的普通对象才真正起作用。
典型场景：用户双击编辑某行，保存后调用 bs.ResetCurrentItem() 即可局部更新，比全量刷新快且稳定。
异步加载数据后无法更新 UI，跨线程异常怎么绕
从后台线程（如 Task.Run）拿到新数据后，直接赋值给 DataSource 会抛出 InvalidOperationException: “线程间操作无效”。
- 最稳妥：用
Control.Invoke()回到 UI 线程再赋值this.Invoke((MethodInvoker)delegate {<br> bs.DataSource = newData;<br>}); - 简化写法（C# 8+）：
await this.InvokeAsync(() => bs.DataSource = newData); - 避免用
BackgroundWorker的RunWorkerCompleted，它虽在线程安全上下文中执行，但容易和BindingSource生命周期耦合出问题
别试图在后台线程里调用 dataGridView1.Refresh() 或 Invalidate()——它们必须由创建控件的线程调用，否则直接崩溃。
动态刷新的核心不是“怎么刷”，而是“谁来通知”和“在哪刷”。绑定层选错、通知机制缺失、线程上下文跳失，这三个点踩中任意一个，刷新就静默失败。
