pandas读CSV直接OOM是因为默认一次性加载全量数据到内存，而Dask按块延迟读取，仅在计算时加载所需块，内存中只保留活跃块和元数据。
为什么pandas读CSV直接OOM，而Dask不会立即崩
因为pandas.read_csv()默认把整个文件一次性加载进内存，哪怕你只取前10行——它仍会解析全部数据、构建完整DataFrame。千万级CSV（比如10GB）在未压缩状态下，实际内存占用常达20–30GB，远超多数机器物理内存。
Dask不这样干：它用dask.dataframe.read_csv()时，默认按块（block）延迟读取，只在真正调用.compute()或.head()等触发计算时，才按需加载和处理当前所需块。内存里始终只有“活跃块”+元数据，不是全量副本。
- 默认块大小约256MB（可调），可通过
blocksize参数控制，例如blocksize="64MB" - 不支持所有
pandas.read_csv()参数，比如skiprows若非整数块对齐，可能出错 - 列类型推断是惰性的，首次
.compute()时才统一推，易因某块异常导致类型冲突
分块读取后，哪些操作会悄悄吃光内存
Dask的“懒执行”只保你不一上来就OOM，但一旦写错链式操作，.compute()时照样爆掉。典型高危场景：
-
df.groupby('user_id').apply(lambda x: heavy_func(x))——每个分组被拉到单机内存，分组数上百万就完蛋 -
df.merge(another_df, on='key')若两表都大且无分区键对齐，Dask会做shuffle，中间临时对象堆积 -
df.sample(frac=0.1)看似轻量，但底层要先计算总行数（需扫描全量），再随机索引，对超大表很重 - 没设
dtype强制列类型，比如把纯数字ID当object读入，内存翻3–5倍
怎么用dtype + 列筛选提前压内存
千万级数据里，常有80%列你根本不用。读的时候就砍掉，比之后.drop()省得多——后者仍得先把全列载入。
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
更关键的是显式指定dtype。比如把int64能降为int32或category的字段提前声明：
df = dd.read_csv("data.csv",
usecols=["user_id", "action", "ts"],
dtype={"user_id": "uint32",
"action": "category"},
parse_dates=["ts"])
-
category对低基数字符串（如状态码、地区名）极有效，内存可降到1/10 - 时间列务必用
parse_dates，别留成字符串再转——字符串存储开销大，且后续时间运算无法向量化 - 避免
converters：它破坏块并行性，Dask会退化为逐块串行处理
OOM前最该检查的三个配置点
Dask不是设了read_csv就万事大吉。真跑起来卡死或OOM，优先盯这三项：
-
memory_limit：在Client或LocalCluster里必须设，例如memory_limit="12GB"，否则Dask默认不限，OOM前不预警 -
dashboard_address：启动时打开Dashboard（如:8787），实时看Worker内存曲线和任务图，哪个task突然涨内存一目了然 -
scheduler="threads"vs"processes"：IO密集（如读CSV）用threads够用；若含大量CPU计算（如正则、自定义函数），换processes防GIL，但进程间传数据有拷贝开销
复杂点在于：Dask的“块”是逻辑概念，底层仍依赖pandas解析——如果某块里有一行超长JSON字段，pandas解析时仍可能瞬时分配几GB内存。这种case得靠预处理切分或改用dask.delayed手控解析粒度。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
