DBF文件读取慢的根源在于内存滥用和隐式IO，应优先用迭代器遍历、显式指定编码、禁用memo加载、分批处理并校验字段定义。
DBF文件读取慢，是不是用了dbfread直接list(records)？
绝大多数卡顿来自一次性把整个文件加载进内存。dbf本身是顺序结构，但dbfread默认会把所有记录转成python对象列表，10万条记录就可能吃掉500mb+内存，gc压力大、响应停滞。
实操建议：
- 永远用迭代器模式：
for record in dbf_table，而不是list(dbf_table) - 如果必须转列表，先确认字段数和记录量：
len(dbf_table)会触发全扫描，改用dbf_table.header.num_records - 跳过不需要的字段：用
ignore_missing_memos=True和load=False（部分库支持）减少解析开销
用pandas.read_dbf导入时内存爆了或报UnicodeDecodeError
这是simpledbf或旧版dbf后端的典型问题——它底层调用struct.unpack硬解码，不处理编码声明，且默认把全部数据塞进DataFrame。
实操建议：
- 换用
dbfread+pd.DataFrame.from_records()手动控制字段和批次 - 显式指定编码：
DBF(filename, encoding='gbk')（常见中文DBF是GBK/GB2312，不是UTF-8） - 禁用memo字段加载：
DBF(filename, ignore_missing_memos=True)，避免读取大备注块拖慢速度
需要分批写入数据库，但cursor.executemany还是卡在DBF解析阶段
瓶颈往往不在SQL执行，而在DBF解析本身没分片。即使你每1000条提交一次，只要解析逻辑还在单次循环里，前面的999条已经占着内存等不到提交。
实操建议：
- 用
itertools.islice切片迭代器，而非先取全部再切片：from itertools import islice records = iter(dbf_table) while True: batch = list(islice(records, 1000)) if not batch: break cursor.executemany(sql, batch) - 对宽表（字段>50个）尤其要检查是否含
M（memo）或B（blob）类型字段，这类字段实际内容存在单独文件中，每次访问都会触发磁盘IO - 提前过滤：在
for record in dbf_table里加if条件跳过无效记录，别等进DataFrame再dropna
为什么dbfread比simpledbf快，但某些字段值却是None？
不是bug，是字段定义和实际数据错位导致的解析失败。simpledbf靠启发式猜测字段长度和类型，dbfread严格按头信息解析——如果DBF头里某字段标为C（字符型）、长度20，但实际第3条记录该字段只有2字节且含\0，dbfread就返回空字符串或None，而simpledbf会强行截出20字节“脏数据”。
实操建议：
- 用
dbf_table.field_names和dbf_table.fields核对字段类型与长度是否合理 - 对疑似损坏字段，手动用
struct.unpack读原始字节验证（路径：dbf_table.memofilename或dbf_table._raw_data） - 生产环境务必加异常捕获：
try...except ValueError:，避免单条坏记录中断整批导入
