openpyxl默认非只读模式会全量解析XML并构建DOM树，导致CPU密集型操作；需启用read_only=True、values_only=True及预设dtype等优化措施。
openpyxl默认加载会触发XML全量解析
Excel的.xlsx本质是ZIP包，里面包含多个XML文件（sharedStrings.xml、sheet1.xml等）。openpyxl在非只读模式下会逐个解压并构建完整DOM树，这个过程不是纯I/O，而是大量字符串解析、对象创建和引用关系绑定——CPU密集型操作。尤其当文件含大量空行、合并单元格或复杂样式时，解析逻辑分支激增，CPU使用率瞬间拉满。
常见现象：top中看到Python进程CPU持续90%+，但内存增长缓慢；用strace -e trace=clone,execve可观察到大量xml.etree.ElementTree相关调用。
- 必须启用
read_only=True才能跳过DOM构建，改用流式迭代 - 即使只读取单列，不加
read_only=True也会全量解析整张表 -
data_only=True不能降低CPU压力，它只影响公式计算阶段，不影响XML解析本身
pandas.read_excel底层引擎切换失效
很多人以为加了engine="openpyxl"就等于用了openpyxl的高效路径，其实不然。pandas.read_excel()在内部仍会把openpyxl加载的数据转成DataFrame，并执行类型推断（infer_dtype）、空值检测、索引重建等操作——这些全是CPU敏感任务。更糟的是，如果文件含混合类型列（比如一列里有数字、字符串、空值），pandas会退化为object类型并逐单元格调用isinstance()判断，导致CPU占用雪崩。
- 显式指定
dtype（如{"col_a": "string", "col_b": "int32"}）能绕过类型推断 -
usecols参数必须配合dtype使用，否则pandas仍会解析所有列以做类型推测 - 避免
na_values设为复杂正则，它会在每行每列上重复执行re.search()
后台GC与对象频繁创建导致CPU抖动
openpyxl每个Cell都是独立Python对象，含至少10+属性（样式、格式、注释等）。10万行×50列 = 500万个对象。CPython的引用计数+分代GC在对象高频创建/销毁时会频繁触发，表现为CPU占用忽高忽低、卡顿明显。这不是代码写错，而是openpyxl的设计使然——它优先保证功能完整性，而非内存/CPU友好。
立即学习“Python免费学习笔记（深入）”；
- 用
values_only=True（在iter_rows()中）可跳过Cell对象构造，直接返回元组 - 禁用
keep_vba=False（默认True），VBA解析极其耗CPU - 处理完工作簿后务必调用
wb.close()，否则GC无法及时回收底层C结构体
Excel文件本身埋了性能雷区
很多“大文件”实际数据量不大，但因人为操作引入隐形负担：比如整列设置为日期格式但只填了10行数据，openpyxl仍要为剩余百万空单元格分配格式对象；又比如用Excel手动插入1000个空白行再删掉，这些行仍保留在XML中，成为“幽灵行”。这类文件解析时CPU会反复遍历无效区域。
- 用
openpyxl打开后检查ws.max_row和ws.max_column是否远超实际数据范围 - 导出前在Excel里按
Ctrl+End看光标停在哪，那个位置就是openpyxl认为的“末尾” - 真正有效的清理方式：另存为新文件 → 选择“仅保留值” → 关闭所有格式/条件格式/批注
read_only、不预设dtype、不清理幽灵行列，光换库或升配置没用。 
