dask能读内存外excel因其惰性加载：仅扫描结构、分区为delayed任务，真正读取在compute()时发生且可独立gc；但依赖openpyxl、不支持.xls及复杂格式。
为什么 Dask 能读进内存外的 Excel 文件
Pandas 的 pd.read_excel() 必须把整张表加载到 RAM，遇到 2GB+ 的 Excel 直接报 MemoryError；Dask 的 dd.read_excel() 不是真读——它只扫描文件结构、估算分区边界，按 sheet 或行范围切分成多个 delayed 任务，真正读取发生在 .compute() 阶段，且每个分区可独立 GC。
但要注意：dd.read_excel() 依赖 openpyxl 或 xlsxwriter，不支持 .xls 格式；若 Excel 含复杂公式、合并单元格或非常规格式，Dask 可能跳过或解析失败，这时得先用 Pandas 手动拆成多个 CSV 再喂给 Dask。
groupby / apply 类操作在 Dask 里为何经常报错
Dask 的惰性执行模型要求所有中间操作必须可序列化、无副作用、能跨进程复现。一旦你在 ddf.groupby(...).apply(...) 里传入闭包、lambda、带实例状态的函数，或者调用了不可 pickle 的对象（比如某些数据库连接、GUI 组件），就会触发 PicklingError 或 AttributeError。
实操建议：
- 用
def显式定义纯函数，参数全靠传入，别引用外部变量 - 避免在
apply里调用pd.DataFrame构造器——改用dd.from_pandas(..., npartitions=...)预热 - 复杂逻辑优先转回 Pandas：先
ddf.partitions[0].compute()抽样调试，确认逻辑无误再全量跑
compute() 之后内存没释放？不是 Dask 没清，是你留了引用
result = ddf.groupby('id').sum().compute() 执行完，result 是标准 Pandas DataFrame，但原始 ddf 对象仍持有全部分区的元数据和延迟任务图。如果后续没显式删掉 ddf，Python GC 不会自动回收底层磁盘缓存或临时文件。
容易被忽略的操作：
- 及时
del ddf，尤其在循环处理多个大文件时 - 用
dd.persist()替代反复compute()时，记得配套调用client.cancel()（分布式）或手动清理dd.utils.clear_memory() - Excel 场景下，Dask 默认缓存解压后的 XML 片段，路径在
/tmp/dask-*，需定期rm -rf /tmp/dask-*
从 Pandas 迁移时最痛的 API 兼容断层
90% 的 pd.xxx 在 Dask 里有同名接口，但关键差异藏在细节里：
-
ddf.sort_values('col')不保证全局有序，要加ignore_index=True+set_index('col').reset_index()才等价 -
ddf.merge()不支持how='outer'与indicator=True同时使用 -
ddf.to_parquet()是推荐出口，但ddf.to_excel()不存在——必须先.compute()成 Pandas 再写 - 时间序列操作如
resample()仅支持规则频率，且closed/label参数行为与 Pandas 不一致
真正卡住人的，往往不是“能不能做”，而是“做出来结果对不对”。建议保留一份小样本的 Pandas 基准输出，每次迁移后用 result.equals(baseline) 校验，而不是只看形状或头几行。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
