xml.etree.elementtree是解析xml最稳选择，兼容性好、内存低、无需外部依赖；应避免lxml除非必需高级功能，用iter()而非findall()更安全，命名空间需预注册，文本需strip()，insert须参数化防注入，字段顺序需对齐数据库schema，大文件用iterparse()流式处理并及时clear()，批量提交提升性能。
用 Python 的 xml.etree.ElementTree 解析 XML 更稳
XML 结构千差万别，但 xml.etree.ElementTree 是标准库中兼容性最好、内存占用低、且不依赖外部包的选择。别一上来就用 lxml——除非你明确需要 XPath 1.0+ 或命名空间高级操作，否则它反而容易在生产环境因缺失 C 库报 ImportError: No module named 'lxml'。
- 只读取非嵌套扁平结构时，用
tree.iter(tag)比findall()更安全，能跳过空元素和注释 - 遇到带命名空间的 XML（比如
{http://example.com/ns}user），必须提前用namespaces=参数注册前缀，否则所有find()都返回None - 节点文本含换行或空格？别直接取
elem.text，先用elem.text.strip() if elem.text else ''，否则 INSERT 会多出不可见字符导致字段截断或类型转换失败
INSERT 语句生成要防 sql 注入，别拼字符串
把 XML 字段值直接用 f"INSERT intO t VALUES ('{val}')" 拼进去，等于给数据库开后门。哪怕数据来源“可信”，字段里只要有个单引号或反斜杠，整条语句就崩，还可能触发意外的语义执行。
- 用数据库驱动原生参数化支持：sqlite 用
?，postgresql 用%s，mysql 用%s或%(name)s，值统一塞进cursor.execute(sql, tuple(values)) - XML 中的
、<code>>、&不用 HTML 转义——SQL 不吃这套；但字符串里的单引号'必须由驱动自动处理，人不用管 - 数值字段如
<age>25</age>，解析后得转成int()或Float()，别留着字符串传给Integer列，否则 SQLite 可能静默转成 0，PostgreSQL 直接报invalid input syntax for integer
字段顺序错位会导致 INSERT 报错或数据写歪
XML 元素顺序 ≠ 数据库表字段顺序。比如 XML 是 <email>...</email><name>...</name>，但表定义是 CREATE table users (name TEXT, email TEXT)，硬按 XML 顺序插就会把邮箱写进 name 字段。
- 务必从数据库查 Schema：用
PRAGMA table_info(table_name)（SQLite）或select column_name FROM information_schema.columns WHERE table_name='users' ORDER BY ordinal_position（PG/MySQL）拿到真实字段顺序 - XML 解析阶段，建议把每条记录存成字典：
{'name': 'Alice', 'email': 'a@b.c'}，再按 Schema 顺序提取值，生成tuple(d[k] for k in db_columns) - 如果 XML 字段名和 DB 列名不一致（比如 XML 用
usr_name，DB 是username），建个映射字典比硬编码下标更可靠：xml_to_db = {'usr_name': 'username', 'usr_email': 'email'}
大文件别一次性 load 进内存
一个 200MB 的 XML，用 ET.parse() 直接加载，Python 进程内存飙升到 1GB+ 很常见，还可能被系统 OOM kill。这不是性能问题，是能不能跑通的问题。
- 改用
ET.iterparse()，边读边处理：监听start和end事件，在end时提取完整 record 元素，立刻生成 INSERT 并执行/缓存，然后调用elem.clear()释放子树内存 - 批量提交更关键：别每条 record 都
commit()，攒够 100–1000 条再 commit，速度能快一个数量级；但注意事务太大可能锁表或日志爆满 - 如果 XML 是流式来源（比如 HTTP 响应体），别写临时文件，直接用
iterparse(source=response.raw)接原始 socket 流
实际迁移时，最常卡住的不是语法，是 XML 里混着非法字符（比如控制符 x00）、编码声明和文件实际编码不一致（声明 UTF-8 但存了 GBK 字节）、或者某条 record 缺了必填字段导致字典键缺失——这些都得在生成 INSERT 前做防御性检查，不能指望数据库报错再回头修。