DBF导出必须先定义字段结构再写入数据，因文件头需预声明全部字段名、类型、长度，且结构与数据紧耦合；字段名≤10字节、纯ASCII、不能数字开头；类型仅支持C/N/F/D/L五种，须严格映射；中文字段名易乱码，建议用英文命名。

DBF导出时字段定义和数据写入必须分两步走

dbf格式不支持“先建表再填数据”式的动态追加，dbf 文件头里必须提前声明全部字段名、类型、长度——哪怕某列全为空。结构（schema）和数据（records）物理上紧耦合在同一个文件里，所谓“分离提取”，本质是人工拆成两阶段操作：先生成空表结构，再逐条写入数据。

• 用 dbfpy 或 simpledbf 时，Table.create() 或 DbfWriter() 初始化就强制要求传入完整字段列表，不能留空或后期追加
• pyodbc + ODBC 驱动直连 DBF 目录时，驱动会把整个 .dbf 当作只读表看待，无法绕过结构直接 dump 数据
• 跨库（比如从 PostgreSQL 导出到 DBF）时，必须先查源表 information_schema.columns 或用 ORM 的 __table__.columns 获取字段元信息，再映射为 DBF 支持的类型（如 VARCHAR → C, INTEGER → N, DATE → D）

字段类型映射错一个，DBF 就打不开或乱码

DBF 的类型系统极简且不可扩展：C（字符）、N（数字）、F（浮点）、D（日期）、L（逻辑）五种。没有布尔、JSON、TIMESTAMP、TEXT 等现代类型，也没有 null 概念——所有字段默认非空，空值靠填充空格/0/19000101 表示。

• BOOLEAN 字段必须转成 L 类型，值映射为 True→T, False→F；若存成 C 会显示为 "True"/"False" 字符串，Excel 打开后识别为文本
• NUMERIC(10,2) 要写成 N 类型并指定 field_length=10, decimal_count=2；漏设 decimal_count 会导致小数全截断
• TIMESTAMP 必须截断为 DATE（D 类型），DBF 不存时间部分；强行塞 datetime 对象会报 ValueError: year is out of range

跨表导出要防字段名重复或非法字符

DBF 规范要求字段名 ≤10 字节、纯 ASCII、不能以数字开头、不能含空格或点号。而现代数据库常有 user_id、created_at、order.total 这类命名，直接照搬会触发 InvalidFieldNameError 或静默截断。

• 自动清洗建议：用正则 re.sub(r'[^a-zA-Z0-9_]', '_', name) 替换非法字符，再用 name[:10].strip('_') 截断，最后确保首字符非数字（前面补 _）
• 多个源表导出到同一 DBF 时，注意字段名全局唯一——例如两张表都有 id，得重命名为 user_id 和 order_id，否则 dbfpy 写入时会报 Duplicate field name
• 大小写不敏感：SQL 中的 UserId 和 userid 在 DBF 里视为同名，合并前必须人工检查

中文字段名或数据导出后乱码？别碰 Code Page

DBF 文件头里有个 code_page 字节，决定如何解释字节流。常见误区是以为设成 936（GBK）就能显示中文字段名——但绝大多数 DBF 工具（包括 Excel、FoxPro 兼容工具）根本不读这个字段，而是按当前系统区域设置硬解码。结果就是字段名看着是乱码，但数据能对上。

• 真正稳妥的做法：字段名坚持用英文（cust_name 而非 客户姓名），数据内容用 UTF-8 编码写入，然后用支持 UTF-8 的工具（如 dbfread 或 Python 脚本）读取
• 如果必须用中文字段名，导出后用 chcp 936 & dbfview xxx.dbf 在 Windows 命令行下查看，避免用 Excel 直接双击——它默认用 ANSI 解码
• simpledbf 库默认用 cp1252 编码字段名，写入中文会崩；必须显式传 encoding='gbk'，且仅限 Windows 环境有效

字段名长度限制、类型映射规则、编码处理方式——这三处不手动抠细节，导出来的 DBF 文件大概率在下游系统里打不开，或者打开后字段错位、数值变零、日期全成 1900 年。