手动建立列名到属性名的映射字典，缓存PropertyInfo数组与列索引，用PropertyDescriptor或Expression.Lambda优化反射性能，读取前判空DBNull并使用可空类型或默认值逻辑。
DataTable转List时属性名对不上怎么办
直接用反射硬匹配会失败——DataTable列名是 "User_ID"，而实体类属性是 UserId，默认不识别下划线转驼峰。别指望 Activator.CreateInstance 自动猜映射关系。
实操建议：
- 手动建立列名到属性名的映射字典，比如
new Dictionary<string string> { ["User_ID"] = "UserId" }</string>，在反射赋值前做一次键映射 - 用
PropertyDescriptor替代直接PropertyInfo.SetValue，它支持DisplayName等特性，可配合自定义特性如[Column("User_ID")]显式声明 - 避免用
DataTable.Columns[i].ColumnName做字符串相等判断，大小写敏感且无法处理空格、特殊字符；改用StringComparer.OrdinalIgnoreCase
反射遍历属性太慢，10万行DataTable卡死
每行都调用 GetProperty + SetValue 是典型性能陷阱。.NET 6+ 中单次反射调用开销约 50–100ns，但 10 万行 × 每行 20 个属性 ≈ 1 亿次反射操作，实际耗时可能超秒级。
实操建议：
- 提前缓存
PropertyInfo[]数组和对应列索引，避免循环内重复查找：var props = typeof(T).GetProperties(); var colIndices = props.Select(p => dt.Columns.IndexOf(p.Name)).ToArray(); - 对高频场景，用
Expression.Lambda编译委托（如Func<datarow t></datarow>），首次编译稍慢，后续调用接近原生速度 - 别在循环里反复调用
Convert.ChangeType—— 它内部有类型检查和装箱，换成预定义的转换函数，比如int.TryParse(row["Age"].ToString(), out int a) ? a : default
DateTime列为空值（DBNull）导致InvalidCastException
DataRow["BirthDate"] 返回 DBNull.Value，但直接传给 DateTime.Parse 或强制转型 (DateTime)row["BirthDate"] 就崩。
实操建议：
- 所有值读取必须先判空：
row["BirthDate"] == DBNull.Value ? default(DateTime?) : (DateTime)row["BirthDate"] - 实体类中对应字段声明为可空类型
DateTime?，否则即使判空也无法赋值 - 如果数据库列允许 NULL 但实体要求非空（如
DateTime），得明确默认值逻辑，比如row["BirthDate"] == DBNull.Value ? DateTime.Today : (DateTime)row["BirthDate"]
用JsonSerializer.Serialize再Deserialize绕过反射可行吗
可以，但不推荐——把 DataTable 先序列化成 JSON 字符串，再反序列化为 List<t></t>，看似“无反射”，实则把问题转嫁给 JSON 库，且引入额外内存与 CPU 开销。
实操建议：
- 仅当已有现成 JSON 流水线、且数据量小（
-
System.Text.Json默认不支持DataTable直接序列化，需先转JsonDocument或用第三方库如Newtonsoft.Json的DataTableConverter - 这种方案会丢失类型信息（比如
int列变成 JSON number，但反序列化时若实体是long可能溢出），不如直面反射控制权
