excel导入datatable为空是因ole db默认采样前8行判列类型，遇混合数据丢值；应设imex=1、扩展名与连接字符串一致，并安装匹配位数的access database engine。
Excel 导入时 DataTable 为空但没报错？检查 IMEX=1 和扩展名匹配
常见现象是调用 OleDbDataAdapter.Fill() 后得到空的 DataTable，尤其在 Excel 2007+（.xlsx）文件里混有文本和数字列时。本质是 OLE DB 驱动默认按首 8 行采样列类型，一旦前几行是数字、后面出现“2024-01-01”这类文本，整列会被判为 INT 并丢弃非数字值——且不报错。
解决办法不是换库，而是修正连接字符串：
-
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={path};Extended Properties="Excel 12.0 Xml;HDR=YES;IMEX=1"——IMEX=1强制以“导入模式”打开，把疑似混合列当文本处理 - 路径中文件扩展名必须和
Extended Properties一致：.xlsx 对应Excel 12.0 Xml，.xls 对应Excel 8.0；不一致会导致驱动静默失败 - 确保目标机器安装了对应版本的
Microsoft Access Database Engine（注意 32/64 位需与你的 C# 进程匹配）
大文件导入卡死或内存爆掉？别用 DataSet 全量加载
读取几十 MB 的 Excel 或 CSV 时，直接 Fill(DataSet) 或 File.ReadAllLines() 会把整个文件拉进内存，GC 压力大，还可能触发 OutOfMemoryException。
换成流式处理：
- Excel：用
EPPlus（NuGet 包EPPlus）的LoadFromCollection()或逐行读取worksheet.Cells[row, col].Value，配合using (var package = new ExcelPackage(fileStream))确保资源释放 - CSV：用
StreamReader+string.Split()（简单格式）或CsvHelper的GetRecordsAsync<t>()</t>流式反序列化，避免一次性读完 - 关键点：所有 IO 操作加
try/catch，并在finally或using中关闭流，否则文件句柄泄漏会导致后续导入失败
数据库批量插入慢如蜗牛？绕过 SqlDataAdapter 改用 SqlBulkCopy
用循环执行 INSERT INTO ... VALUES (...) 或靠 SqlDataAdapter.Update() 批量写入万级数据，耗时往往以分钟计。根本原因是每条语句都走完整 SQL 解析、计划生成、事务日志写入流程。
SqlBulkCopy 是唯一能逼近原生 BCP 性能的托管方案：
- 源数据必须是
DataTable、IDataReader或实现IColumnMapping的对象；推荐先用DataTable.Load()从流构建，再设ColumnMappings显式绑定列名（避免顺序错位） - 务必设置
BatchSize = 10000和DestinationTableName，并开启SqlBulkCopyOptions.TableLock减少锁竞争 - 注意：目标表不能有启用的触发器、外键约束或标识列（除非设
SqlBulkCopyOptions.KeepIdentity）——这些都会让 BulkCopy 自动退化为逐行插入
中文乱码、日期解析失败、空值转 0？字段映射前必须做类型预处理
用户上传的 Excel/CSV 几乎必然存在格式混乱：日期列含“-”“/”“.”混用、“N/A”“空格”“NULL”字符串、数字列夹带单位（如“123kg”）。硬塞进强类型模型会抛 InvalidCastException 或存入错误值。
安全做法是在填充实体前清洗字段：
- 对每一列，先用
Convert.IsDBNull()或string.IsNullOrWhiteSpace()判空，再根据目标类型选择转换逻辑，例如：DateTime.TryParseExact(val, "yyyy-MM-dd", null, DateTimeStyles.None, out dt) ? dt : DateTime.MinValue - 数字列用
decimal.TryParse()替代(decimal)val，失败时记录日志并跳过或设默认值 - 中文字段若入库后变问号，确认数据库字段是
NVARCHAR而非VARCHAR，且连接字符串含Charset=utf8（MySQL）或使用 Unicode 参数（SQL Server）
最易被忽略的是时间区域：用户本地 Excel 里的“2024-01-01”默认是本地时区，但 DateTime.Parse() 会按服务器时区解释。统一转成 UTC 存储，展示时再转回用户时区——这个转换点一旦漏掉，凌晨导入的数据第二天就“消失”了。
