pickle比csv快因直接保存内存结构、免解析，但有python版本/架构兼容性风险和rce隐患；feather基于arrow，零拷贝、列式存储、跨语言兼容，但依赖pyarrow且不存索引名称。
为什么Pickle比CSV快但有兼容性风险
Pickle序列化直接保存Python对象内存结构，跳过文本解析和类型推断，pd.read_pickle()加载速度通常是pd.read_csv()的3–10倍。但它本质是Python专属协议，不同Python版本或不同架构（如32/64位）间可能无法反序列化，且存在远程代码执行风险——不能加载不可信来源的.pkl文件。
实操建议：
- 仅在可信环境、同Python版本（建议锁定
protocol=4或5）下用pickle；可显式指定协议：df.to_pickle("data.pkl", protocol=4) - 若需跨语言或长期存档，别选Pickle；它不是数据交换格式
- 注意：含自定义类、lambda、闭包的DataFrame无法被Pickle安全序列化
Feather格式适合高频读写但依赖Arrow生态
feather基于Apache Arrow内存格式，零拷贝读取、列式存储、天然支持null和复杂类型（list、struct），pd.read_feather()加载几乎不占CPU，尤其适合大表（>1GB）秒开。但它要求安装pyarrow（>=11.0），旧版feather-format已弃用，别再用import feather。
实操建议：
- 安装正确依赖：
pip install pyarrow（不是feather-format） - 保存时默认不压缩，如需减小体积可加
compression="zstd"（需PyArrow ≥12）：df.to_feather("data.feather", compression="zstd") - Feather不保存索引名称（
df.index.name会丢失），需手动保存/恢复：df.index.name = "id"
→ 读取后重新赋值
Pickle与Feather在实际场景中的取舍要点
选哪个不是看“谁更快”，而是看你的使用链路是否闭环：
- 纯Python内部pipeline（训练脚本→特征缓存→模型加载）→ 优先
to_pickle()，简单直接 - 需要和R、Julia或下游Spark/Flink交互 → 必须
to_feather()，Arrow是事实标准 - DataFrame含category、datetime64[ns, tz]等类型 → Feather保留更完整；Pickle可能在跨版本时把tz信息变成NaT
- 磁盘空间敏感？Feather通常比Pickle小20%–40%，尤其含重复字符串列时（自动字典编码）
别忽略的细节：路径、dtype和空值处理
无论用哪种格式，以下三点常导致下次加载失败或结果异常：
-
to_feather()不支持objectdtype中混有list/dict/None以外的任意Python对象（比如datetime.time或自定义类实例），会报NotImplementedError: Cannot serialize column with type object；提前转成string或用astype("string") - Pickle保存路径必须带
.pkl扩展名，否则read_pickle()可能静默失败（返回None）；Feather则强制要求.feather - 含大量NaN的float列，Feather默认用Arrow的null bitmap高效表示；但若后续用
pd.read_feather(..., use_threads=False)在单核机器上加载，可能比默认多线程慢2倍
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
