5个坑搞懂excel脚本，这份保姆级教程救了你
版本升级后 API 全变了，打开代码全是红波浪线，是不是觉得之前学的东西全白搭？别慌，这种挫败感我太熟悉了。很多老手在从 xlrd 迁移到 openpyxl 时，或者在 pandas 版本迭代中，都踩过这种“坑”。今天这篇保姆级教程，不聊虚的，直接拆解 Excel 脚本底层的文件结构逻辑，带你从字节层面看懂 Excel 是怎么被 Python 读写的。
咱们先说个大实话：Excel 文件（.xlsx）本质上不是表格，而是一个压缩包。你看到的单元格、公式、样式，在硬盘上其实是一堆 XML 文件。理解这一点，你就成功了一半。很多脚本报错，不是因为代码写错了，而是因为你试图用操作“表格”的思维去操作“压缩包”。
一句话原理：Excel 是带索引的 XML 压缩包
在深入代码之前，必须把这个底层概念钉死在脑子里。Excel 2007 及以后版本的 .xlsx 文件，其底层格式完全遵循 OOXML (Office Open XML) 标准。
这就好比一个精致的快递包裹。外层是 ZIP 格式（你可以通过把 .xlsx 后缀改成 .zip 来验证），里面装着各种 XML 文件。xl/workbook.xml：这是目录，告诉 Excel 程序有哪些工作表，以及它们的名称。
xl/worksheets/sheet1.xml：这是具体数据，第一张表的所有单元格内容都藏在这里。
xl/sharedStrings.xml：这是字典，Excel 为了节省空间，把重复出现的字符串（比如“姓名”、“男”）存起来，只在 sheet 里存索引号。为什么 API 会全变？
因为不同的库（如 xlrd、openpyxl、pandas）对这个“压缩包”的解包策略完全不同。老版本的 xlrd 只能读旧版 .xls（二进制格式），对新版 .xlsx 支持极差，后来直接弃坑。
openpyxl 是直接操作 XML 的，它模拟了 Excel 的底层行为，所以它保留了公式，但性能稍慢。
pandas 底层调用 openpyxl 或 calamine，但它关心的是数据矩阵，它会把 XML 解析成二维数组，丢弃大部分格式和公式。当你换库或者升级库版本时，实际上就是换了一套“拆快递”的工具。如果你还在用老工具的说明书去操作新工具，报错是必然的。
类比解释：把 Excel 想象成图书馆
为了更直观地理解这个“压缩包 + 索引”的结构，我们打个比方。
想象 Excel 文件是一座图书馆，而 ZIP 格式是这座图书馆的围墙。sharedStrings.xml 是“图书索引卡”：
假设图书馆里有 1000 本书，其中“Python编程”这本书有 500 本。管理员不会把“Python编程”这五个字印在每一本书的封面上，而是给这五个字分配一个编号，比如 001。然后，那 500 本书的封面上只写 001。优势：极度节省空间。
劣势：如果你直接看封面（sheet XML），你看到的都是数字。你必须拿着数字去查索引卡（sharedStrings），才能知道这是什么内容。sheet1.xml 是“书架上的书”：
这里存放的是书架的布局。哪个位置（A1）放的是编号 001 的书，哪个位置（A2）放的是数字 100（数字不需要索引，直接存）。workbook.xml 是“图书馆总目录”：
告诉你一共有几个阅览室（Sheet），每个阅览室叫什么名字。为什么版本升级后 API 变了？
以前的库可能只让你看“书的内容”，不管“编号”。现在的库（如 openpyxl）要求你要么手动查编号，要么提供自动查编号的接口。如果你调用的函数变了，往往是因为它改变了“查编号”的方式。比如，以前可能默认帮你查好了，现在需要你指定 data_only=True 来读取计算后的值，而不是公式字符串。
源码与伪代码：拆解 ZIP 里的 XML
光说概念太抽象，我们直接动手。不要用复杂的库，用 Python 标准库 zipfile 和 xml.etree.ElementTree，让我们亲眼看看 Excel 的“内脏”。
这段代码不会修改 Excel，只是“窥探”它的底层结构。这是理解所有 Excel 脚本报错的钥匙。
import zipfile
import xml.etree.ElementTree as ET
import iodef peek_inside_excel(file_path):打开 Excel (xlsx) 文件，查看其内部的 XML 结构这是理解底层原理的最直接方式try:with zipfile.ZipFile(file_path, 'r') as z:# 1. 列出所有文件，看看里面有什么print(=== 文件列表 (类似 ls -l) ===)for name in z.namelist():print(name)# 2. 读取 sharedStrings.xml，看看“字典”长什么样print(\n=== Shared Strings (字符串字典) 片段 ===)if 'xl/sharedStrings.xml' in z.namelist():with z.open('xl/sharedStrings.xml') as f:# 注意：Excel 的 XML 有命名空间，处理时要小心content = f.read().decode('utf-8')# 简单截取前 500 字符，避免打印过多print(content[:500])print(... (省略后续内容))# 3. 读取 sheet1.xml，看看数据是怎么存的print(\n=== Sheet1 Data (数据层) 片段 ===)if 'xl/worksheets/sheet1.xml' in z.namelist():with z.open('xl/worksheets/sheet1.xml') as f:content = f.read().decode('utf-8')print(content[:500])print(... (省略后续内容))except FileNotFoundError:print(文件未找到)except zipfile.BadZipFile:print(这不是一个有效的 xlsx 文件，或者是旧的 xls 格式)# 假设我们有一个 test.xlsx 文件
# peek_inside_excel('test.xlsx')代码逐行解析与坑点预警：zipfile.ZipFile: 这一步就证明了 Excel 是 ZIP。如果这里报错 BadZipFile，恭喜你，你打开的可能是一个伪装的 .xlsx，或者是旧的 .xls 二进制文件。很多脚本在开头不做这个判断，直接导致后续全崩。
z.namelist(): 你会发现除了我们说的几个核心文件，还有很多其他文件，比如 docProps/core.xml（元数据，作者、创建时间）。很多“读取元数据”的 API 变更，其实都是在改怎么读这些辅助文件。
sharedStrings.xml: 你会看到 sitPython/t/si 这样的结构。si 是 String Item，t 是 Text。注意，t 里面可能包含换行符或者特殊字符，XML 转义处理不当是常见的解码错误来源。
sheet1.xml: 你会看到 c r=A1 t=sv0/v/c。r=A1: 单元格坐标。
t=s: 这是关键！ 类型是 String (Shared String)。
v0/v: 值是 0。
坑点：这里的 0 不是数字 0，而是指向 sharedStrings 中第 0 个元素的索引。如果你直接用 pandas 或 openpyxl 读取时，库负责了这个映射。但如果你用低层库或者自己解析，忘了这一步，你就会得到一堆 0, 1, 2，而看不到真实的文本。这就是为什么有些库升级后，读出来的数据变成了索引号。流程描述：数据是如何流转的
理解了结构，我们来看一个典型的 Excel 读取流程。无论是 openpyxl 还是 pandas，底层逻辑大致如下：解压 (Unzip): 将 .xlsx 文件在内存中解压成一个字典，键是文件名（如 xl/worksheets/sheet1.xml），值是字节流。
解析共享字符串 (Parse Shared Strings): 解析 sharedStrings.xml，建立一个列表 strings_list。strings_list[0] 就是第一个字符串。
解析工作表 (Parse Sheet): 解析 sheet1.xml。遍历每一行 row。
遍历每一列 c。
判断类型 t:如果 t=s (Shared String): 读取 v 中的整数索引 i，去 strings_list[i] 取值。
如果 t=n (Number) 或没有 t: 直接读取 v 中的值，转换为 float 或 int。
如果 t=b (Boolean): 转换为 True/False。
如果 t=str (Inline String): 直接读取 t 标签的内容（较少见，通常用于公式结果）。
如果 f 标签存在 (Formula): 这是一个公式。如果开启 data_only，则读取 v 中的缓存计算结果；否则读取 f 中的公式字符串。构建对象 (Build Object):openpyxl: 构建 Cell 对象，保留样式、坐标、值。
pandas: 将上述数据填充到 DataFrame 的二维数组中，丢弃样式和公式（除非特定配置）。版本升级后 API 变化的根源就在第 3 步和第 4 步。
例如，某个库在 v1.0 中，默认把 t=s 的值直接当作文本处理，忽略了索引映射（这是个 Bug 或者简化处理）。在 v2.0 中，为了符合标准，修正了这个行为，强制要求查索引。于是，老代码在 v2.0 下读出来的全是数字索引，用户就喊“API 全变了”。
实战验证与避坑指南
知道了原理，怎么应用到实际工作中？这里分享三个高频踩坑场景及对策。
1. 读取公式结果为空或 None
现象：Excel 里 A1 有公式 =1+1，显示 2。Python 读取 A1，得到 None 或 1+1。
原因：如果是 None：你用了 openpyxl，且没有设置 data_only=True。默认模式下，openpyxl 读取公式单元格时，如果 Excel 文件不是由 Excel 保存的（比如由 LibreOffice 或某些库生成），缓存的计算结果 v 可能不存在。
如果是 1+1：你读取的是公式字符串，而不是计算结果。对策：方案 A (推荐)：使用 pandas.read_excel。pandas 底层默认行为通常会尝试读取计算后的值（取决于后端引擎），更稳健。
方案 B：使用 openpyxl 时，务必加上 data_only=True。
wb = openpyxl.load_workbook('file.xlsx', data_only=True)注意：data_only=True 只能读取 Excel 软件计算并保存过的结果。如果是 Python 生成的 Excel 且从未用 Excel 打开保存过，v 标签可能为空，此时读出来依然是 None。这是底层机制决定的，不是 Bug。2. 大文件读取内存爆炸
现象：读取 10 万行以上的 Excel，内存占用飙升，甚至 OOM (Out of Memory)。
原因：
openpyxl 会将整个工作簿加载到内存中，构建庞大的对象树。每一行、每一列、每一个单元格都是一个 Python 对象。10 万行 x 10 列 = 100 万个对象，开销巨大。
对策：方案 A：换用 pandas。pandas 基于 NumPy，使用紧凑的 C 数组存储数据，内存效率远高于 openpyxl 的对象模型。
方案 B：如果必须用 openpyxl，尝试使用 read_only=True 模式。
wb = openpyxl.load_workbook('file.xlsx', read_only=True)在这种模式下，openpyxl 不会一次性加载所有行，而是迭代器方式逐行读取，内存占用恒定。但缺点是不能修改文件，只能读。3. 中文乱码或特殊字符解析错误
现象：读取包含中文、Emoji 或特殊符号的 Excel，出现 UnicodeDecodeError 或乱码。
原因：
XML 文件通常指定了编码（如 UTF-8），但在某些老旧系统或跨平台传输中，字节流可能被错误解码。
对策：检查 sharedStrings.xml 的 ?xml version=1.0 encoding=UTF-8? 声明。
在 Python 中，始终确保使用 utf-8 编码处理字节流。
如果是从 Windows 复制的文件，注意 BOM (Byte Order Mark) 的处理。openpyxl 和 pandas 通常能自动处理，但如果你自己写底层解析，必须手动 strip BOM。常见库对比表特性
xlrd (旧版)
openpyxl
pandas支持格式
.xls (仅)
.xlsx, .xlsm
.xls, .xlsx, .csv 等性能
中
慢 (对象开销大)
快 (NumPy 底层)公式处理
不支持
支持读写
仅读取计算结果内存占用
中
高
低 (针对大数据)适用场景
遗留 .xls 文件
需要精细控制格式、公式
数据分析、批量处理CSDN 上很多老帖还在推荐 xlrd 读 .xlsx，这是误导。 现在的 xlrd 2.0+ 已经彻底移除对 .xlsx 的支持。如果你在项目里看到 import xlrd 去读 .xlsx，直接替换为 openpyxl 或 pandas，这是技术债，必须还。
总结与互动
Excel 脚本的底层逻辑并不神秘，核心就三点：ZIP 容器、XML 数据、共享字符串索引。
当你遇到“版本升级后 API 全变了”的问题时，不要盲目搜索报错信息。先问自己三个问题：我读的是公式还是值？
我是在查索引还是直接取值？
我的库是把文件当整体加载还是流式加载？理解了这个“压缩包 + 字典”的模型，你会发现 openpyxl 的繁琐其实是它精确控制 XML 的代价，而 pandas 的简单则是它忽略细节换取性能的代价。没有完美的库，只有适合场景的工具。
在实际项目中，我通常建议：分析用 pandas，编辑用 openpyxl，超大文件用 calamine (Rust 实现的引擎，pandas 后端可选)。
不过，这里有个争议点想请教大家：在你公司项目中，当 Excel 文件由不同部门（比如财务用 Excel 2016，IT 用 Python 3.11）共同维护时，你们是怎么处理格式兼容和公式缓存问题的？是强制统一工具链，还是写脚本做“脏数据清洗”？欢迎在评论区聊聊你的实战经验，特别是那些踩过的坑。 5个坑搞懂excel脚本，这份保姆级教程救了你
5个坑搞懂excel脚本，这份保姆级教程救了你
版本升级后 API 全变了，打开代码全是红波浪线，是不是觉得之前学的东西全白搭？别慌，这种挫败感我太熟悉了。很多老手在从 xlrd 迁移到 openpyxl 时，或者在 pandas 版本迭代中，都踩过这种“坑”。今天这篇保姆级教程，不聊虚的，直接拆解 Excel 脚本底层的文件结构逻辑，带你从字节层面看懂 Excel 是怎么被 Python 读写的。
咱们先说个大实话：Excel 文件（.xlsx）本质上不是表格，而是一个压缩包。你看到的单元格、公式、样式，在硬盘上其实是一堆 XML 文件。理解这一点，你就成功了一半。很多脚本报错，不是因为代码写错了，而是因为你试图用操作“表格”的思维去操作“压缩包”。
一句话原理：Excel 是带索引的 XML 压缩包
在深入代码之前，必须把这个底层概念钉死在脑子里。Excel 2007 及以后版本的 .xlsx 文件，其底层格式完全遵循 OOXML (Office Open XML) 标准。
这就好比一个精致的快递包裹。外层是 ZIP 格式（你可以通过把 .xlsx 后缀改成 .zip 来验证），里面装着各种 XML 文件。xl/workbook.xml：这是目录，告诉 Excel 程序有哪些工作表，以及它们的名称。
xl/worksheets/sheet1.xml：这是具体数据，第一张表的所有单元格内容都藏在这里。
xl/sharedStrings.xml：这是字典，Excel 为了节省空间，把重复出现的字符串（比如“姓名”、“男”）存起来，只在 sheet 里存索引号。为什么 API 会全变？
因为不同的库（如 xlrd、openpyxl、pandas）对这个“压缩包”的解包策略完全不同。老版本的 xlrd 只能读旧版 .xls（二进制格式），对新版 .xlsx 支持极差，后来直接弃坑。
openpyxl 是直接操作 XML 的，它模拟了 Excel 的底层行为，所以它保留了公式，但性能稍慢。
pandas 底层调用 openpyxl 或 calamine，但它关心的是数据矩阵，它会把 XML 解析成二维数组，丢弃大部分格式和公式。当你换库或者升级库版本时，实际上就是换了一套“拆快递”的工具。如果你还在用老工具的说明书去操作新工具，报错是必然的。
类比解释：把 Excel 想象成图书馆
为了更直观地理解这个“压缩包 + 索引”的结构，我们打个比方。
想象 Excel 文件是一座图书馆，而 ZIP 格式是这座图书馆的围墙。sharedStrings.xml 是“图书索引卡”：
假设图书馆里有 1000 本书，其中“Python编程”这本书有 500 本。管理员不会把“Python编程”这五个字印在每一本书的封面上，而是给这五个字分配一个编号，比如 001。然后，那 500 本书的封面上只写 001。优势：极度节省空间。
劣势：如果你直接看封面（sheet XML），你看到的都是数字。你必须拿着数字去查索引卡（sharedStrings），才能知道这是什么内容。sheet1.xml 是“书架上的书”：
这里存放的是书架的布局。哪个位置（A1）放的是编号 001 的书，哪个位置（A2）放的是数字 100（数字不需要索引，直接存）。workbook.xml 是“图书馆总目录”：
告诉你一共有几个阅览室（Sheet），每个阅览室叫什么名字。为什么版本升级后 API 变了？
以前的库可能只让你看“书的内容”，不管“编号”。现在的库（如 openpyxl）要求你要么手动查编号，要么提供自动查编号的接口。如果你调用的函数变了，往往是因为它改变了“查编号”的方式。比如，以前可能默认帮你查好了，现在需要你指定 data_only=True 来读取计算后的值，而不是公式字符串。
源码与伪代码：拆解 ZIP 里的 XML
光说概念太抽象，我们直接动手。不要用复杂的库，用 Python 标准库 zipfile 和 xml.etree.ElementTree，让我们亲眼看看 Excel 的“内脏”。
这段代码不会修改 Excel，只是“窥探”它的底层结构。这是理解所有 Excel 脚本报错的钥匙。
import zipfile
import xml.etree.ElementTree as ET
import iodef peek_inside_excel(file_path):打开 Excel (xlsx) 文件，查看其内部的 XML 结构这是理解底层原理的最直接方式try:with zipfile.ZipFile(file_path, 'r') as z:# 1. 列出所有文件，看看里面有什么print(=== 文件列表 (类似 ls -l) ===)for name in z.namelist():print(name)# 2. 读取 sharedStrings.xml，看看“字典”长什么样print(\n=== Shared Strings (字符串字典) 片段 ===)if 'xl/sharedStrings.xml' in z.namelist():with z.open('xl/sharedStrings.xml') as f:# 注意：Excel 的 XML 有命名空间，处理时要小心content = f.read().decode('utf-8')# 简单截取前 500 字符，避免打印过多print(content[:500])print(... (省略后续内容))# 3. 读取 sheet1.xml，看看数据是怎么存的print(\n=== Sheet1 Data (数据层) 片段 ===)if 'xl/worksheets/sheet1.xml' in z.namelist():with z.open('xl/worksheets/sheet1.xml') as f:content = f.read().decode('utf-8')print(content[:500])print(... (省略后续内容))except FileNotFoundError:print(文件未找到)except zipfile.BadZipFile:print(这不是一个有效的 xlsx 文件，或者是旧的 xls 格式)# 假设我们有一个 test.xlsx 文件
# peek_inside_excel('test.xlsx')代码逐行解析与坑点预警：zipfile.ZipFile: 这一步就证明了 Excel 是 ZIP。如果这里报错 BadZipFile，恭喜你，你打开的可能是一个伪装的 .xlsx，或者是旧的 .xls 二进制文件。很多脚本在开头不做这个判断，直接导致后续全崩。
z.namelist(): 你会发现除了我们说的几个核心文件，还有很多其他文件，比如 docProps/core.xml（元数据，作者、创建时间）。很多“读取元数据”的 API 变更，其实都是在改怎么读这些辅助文件。
sharedStrings.xml: 你会看到 sitPython/t/si 这样的结构。si 是 String Item，t 是 Text。注意，t 里面可能包含换行符或者特殊字符，XML 转义处理不当是常见的解码错误来源。
sheet1.xml: 你会看到 c r=A1 t=sv0/v/c。r=A1: 单元格坐标。
t=s: 这是关键！ 类型是 String (Shared String)。
v0/v: 值是 0。
坑点：这里的 0 不是数字 0，而是指向 sharedStrings 中第 0 个元素的索引。如果你直接用 pandas 或 openpyxl 读取时，库负责了这个映射。但如果你用低层库或者自己解析，忘了这一步，你就会得到一堆 0, 1, 2，而看不到真实的文本。这就是为什么有些库升级后，读出来的数据变成了索引号。流程描述：数据是如何流转的
理解了结构，我们来看一个典型的 Excel 读取流程。无论是 openpyxl 还是 pandas，底层逻辑大致如下：解压 (Unzip): 将 .xlsx 文件在内存中解压成一个字典，键是文件名（如 xl/worksheets/sheet1.xml），值是字节流。
解析共享字符串 (Parse Shared Strings): 解析 sharedStrings.xml，建立一个列表 strings_list。strings_list[0] 就是第一个字符串。
解析工作表 (Parse Sheet): 解析 sheet1.xml。遍历每一行 row。
遍历每一列 c。
判断类型 t:如果 t=s (Shared String): 读取 v 中的整数索引 i，去 strings_list[i] 取值。
如果 t=n (Number) 或没有 t: 直接读取 v 中的值，转换为 float 或 int。
如果 t=b (Boolean): 转换为 True/False。
如果 t=str (Inline String): 直接读取 t 标签的内容（较少见，通常用于公式结果）。
如果 f 标签存在 (Formula): 这是一个公式。如果开启 data_only，则读取 v 中的缓存计算结果；否则读取 f 中的公式字符串。构建对象 (Build Object):openpyxl: 构建 Cell 对象，保留样式、坐标、值。
pandas: 将上述数据填充到 DataFrame 的二维数组中，丢弃样式和公式（除非特定配置）。版本升级后 API 变化的根源就在第 3 步和第 4 步。
例如，某个库在 v1.0 中，默认把 t=s 的值直接当作文本处理，忽略了索引映射（这是个 Bug 或者简化处理）。在 v2.0 中，为了符合标准，修正了这个行为，强制要求查索引。于是，老代码在 v2.0 下读出来的全是数字索引，用户就喊“API 全变了”。
实战验证与避坑指南
知道了原理，怎么应用到实际工作中？这里分享三个高频踩坑场景及对策。
1. 读取公式结果为空或 None
现象：Excel 里 A1 有公式 =1+1，显示 2。Python 读取 A1，得到 None 或 1+1。
原因：如果是 None：你用了 openpyxl，且没有设置 data_only=True。默认模式下，openpyxl 读取公式单元格时，如果 Excel 文件不是由 Excel 保存的（比如由 LibreOffice 或某些库生成），缓存的计算结果 v 可能不存在。
如果是 1+1：你读取的是公式字符串，而不是计算结果。对策：方案 A (推荐)：使用 pandas.read_excel。pandas 底层默认行为通常会尝试读取计算后的值（取决于后端引擎），更稳健。
方案 B：使用 openpyxl 时，务必加上 data_only=True。
wb = openpyxl.load_workbook('file.xlsx', data_only=True)注意：data_only=True 只能读取 Excel 软件计算并保存过的结果。如果是 Python 生成的 Excel 且从未用 Excel 打开保存过，v 标签可能为空，此时读出来依然是 None。这是底层机制决定的，不是 Bug。2. 大文件读取内存爆炸
现象：读取 10 万行以上的 Excel，内存占用飙升，甚至 OOM (Out of Memory)。
原因：
openpyxl 会将整个工作簿加载到内存中，构建庞大的对象树。每一行、每一列、每一个单元格都是一个 Python 对象。10 万行 x 10 列 = 100 万个对象，开销巨大。
对策：方案 A：换用 pandas。pandas 基于 NumPy，使用紧凑的 C 数组存储数据，内存效率远高于 openpyxl 的对象模型。
方案 B：如果必须用 openpyxl，尝试使用 read_only=True 模式。
wb = openpyxl.load_workbook('file.xlsx', read_only=True)在这种模式下，openpyxl 不会一次性加载所有行，而是迭代器方式逐行读取，内存占用恒定。但缺点是不能修改文件，只能读。3. 中文乱码或特殊字符解析错误
现象：读取包含中文、Emoji 或特殊符号的 Excel，出现 UnicodeDecodeError 或乱码。
原因：
XML 文件通常指定了编码（如 UTF-8），但在某些老旧系统或跨平台传输中，字节流可能被错误解码。
对策：检查 sharedStrings.xml 的 ?xml version=1.0 encoding=UTF-8? 声明。
在 Python 中，始终确保使用 utf-8 编码处理字节流。
如果是从 Windows 复制的文件，注意 BOM (Byte Order Mark) 的处理。openpyxl 和 pandas 通常能自动处理，但如果你自己写底层解析，必须手动 strip BOM。常见库对比表特性
xlrd (旧版)
openpyxl
pandas支持格式
.xls (仅)
.xlsx, .xlsm
.xls, .xlsx, .csv 等性能
中
慢 (对象开销大)
快 (NumPy 底层)公式处理
不支持
支持读写
仅读取计算结果内存占用
中
高
低 (针对大数据)适用场景
遗留 .xls 文件
需要精细控制格式、公式
数据分析、批量处理CSDN 上很多老帖还在推荐 xlrd 读 .xlsx，这是误导。 现在的 xlrd 2.0+ 已经彻底移除对 .xlsx 的支持。如果你在项目里看到 import xlrd 去读 .xlsx，直接替换为 openpyxl 或 pandas，这是技术债，必须还。
总结与互动
Excel 脚本的底层逻辑并不神秘，核心就三点：ZIP 容器、XML 数据、共享字符串索引。
当你遇到“版本升级后 API 全变了”的问题时，不要盲目搜索报错信息。先问自己三个问题：我读的是公式还是值？
我是在查索引还是直接取值？
我的库是把文件当整体加载还是流式加载？理解了这个“压缩包 + 字典”的模型，你会发现 openpyxl 的繁琐其实是它精确控制 XML 的代价，而 pandas 的简单则是它忽略细节换取性能的代价。没有完美的库，只有适合场景的工具。
在实际项目中，我通常建议：分析用 pandas，编辑用 openpyxl，超大文件用 calamine (Rust 实现的引擎，pandas 后端可选)。
不过，这里有个争议点想请教大家：在你公司项目中，当 Excel 文件由不同部门（比如财务用 Excel 2016，IT 用 Python 3.11）共同维护时，你们是怎么处理格式兼容和公式缓存问题的？是强制统一工具链，还是写脚本做“脏数据清洗”？欢迎在评论区聊聊你的实战经验，特别是那些踩过的坑。