该换 dask 的时机是 pandas 出现 memoryerror、read_csv 卡住或 groupby 耗时超 5 分钟且 cpu 利用率长期低于 30%；内存占用接近物理内存 70% 或 5gb csv 已难支撑时，迁移至 dask 可稳定处理 20gb 数据。
什么时候该换 Dask？看内存和耗时两个硬指标
不是数据大就一定用 Dask，关键看 Pandas 是否已“卡死”或“爆内存”。典型信号：MemoryError、read_csv 卡住不动、单次 groupby 耗时超过 5 分钟且 CPU 利用率长期低于 30%。
实操建议：
- 先用
psutil.Process().memory_info().rss监控 Pandas 加载后的内存占用，若接近物理内存的 70%，迁移就很有必要 - 如果数据量
- 真实阈值因机器而异：4 核 16GB 内存机器，Pandas 处理 >5GB CSV 就大概率撑不住；换成 Dask 后，20GB CSV 可稳跑
dd.read_csv 和 pd.read_csv 的参数差异必须改
Dask 不是 Pandas 的镜像，同名函数行为不同。最常踩坑的是默认不读全表、不自动推断类型、不支持所有 pd.read_csv 参数。
实操建议：
- 必须显式指定
blocksize="25MB"（或类似值），否则 Dask 可能只分 1–2 个 partition，完全无法并行 -
dtype建议全手动写，Dask 不会像 Pandas 那样自动降级类型，object列容易引发 shuffle 性能暴跌 - 删掉
parse_dates、date_parser等 Pandas 特有参数，改用converters或后续.astype("datetime64[ns]") - 不支持
skiprows（除首行外），需用sample+enforce或预处理清洗头信息
.compute() 不是可有可无的“补丁”，而是执行开关
Dask 是延迟执行，所有操作只是在构建任务图。不调 .compute()，代码看似跑完，其实什么都没算——这是新手最常以为“代码没反应”的原因。
实操建议：
- 只在真正需要结果时调用
.compute()，比如导出 CSV、画图、传给 sklearn 模型前 - 中间结果频繁复用？用
.persist()把分区缓存在内存/磁盘，避免重复计算 - 调试阶段加一句
.visualize(filename="taskgraph.png")，能立刻看清哪步在 shuffle、哪步成了单点瓶颈 - 别在循环里反复
.compute()，每调一次都重走整个图——先聚合再算，或用map_partitions拆细粒度
从 pd 换成 dd 后，哪些 Pandas 习惯会翻车
90% API 兼容是事实，但剩下 10% 是高频雷区：不是语法报错，而是结果错、性能崩、内存涨得比 Pandas 还快。
实操建议：
-
df.iloc[:1000]在 Dask 中会触发全表扫描——改用df.head(1000)，它只读前几个 partition -
df.sort_values("x")默认引发全局 shuffle，极慢；若只需局部有序，加ignore_index=True并接受非严格排序 -
df.merge要求 on 字段在左右两边都已分区对齐，否则强制 shuffle；提前用set_index对齐 key 更稳 - 自定义函数别直接塞
.apply()，优先用map_partitions+ 显式指定meta，否则 Dask 无法推断输出结构，运行时报TypeError: Cannot infer meta
最易被忽略的一点：Dask 的错误信息往往藏在 worker 日志里，而不是主进程 traceback 中。本地调试时务必开 dashboard_address=":8787"，浏览器看实时任务流和失败详情。
