Python对象序列化有明确边界：json仅支持基本类型且安全通用，pickle功能强但限于Python环境且有安全风险；含文件句柄、线程锁等对象不可直接序列化；应依场景选方案，避免越界误用。

Python对象序列化不是万能的，它有明确的适用边界和典型场景。用对地方能大幅提升开发效率，用错地方反而引发安全、性能或兼容性问题。

哪些对象可以被安全序列化

Python内置类型（如字典、列表、字符串、数字、None）和简单自定义类实例（不含可调用属性、文件句柄、线程锁等）通常可被pickle或json处理。

• json只支持：dict、list、str、int、float、bool、None —— 且key必须是字符串
• pickle支持更多（如函数、类、带状态的对象），但仅限Python环境间交换，且反序列化存在执行任意代码风险
• 含lambda、open()返回的文件对象、threading.Lock、数据库连接等，基本无法直接序列化

典型可用场景与对应方案

不同场景需匹配不同序列化方式，不能一概而用：

• 跨进程/网络传递简单数据：用json（安全、通用、人可读），比如Flask API返回值、HTTP请求体
• Python内部缓存或临时持久化：用pickle（保留类型和方法），比如joblib缓存训练好的sklearn模型
• 配置或用户偏好存储：用json或toml（结构清晰、易编辑），避免用pickle——防止配置文件被恶意篡改触发代码执行
• 高并发服务间通信：考虑msgpack或protobuf（体积小、解析快），比json更高效，比pickle更安全

常见越界误用及后果

忽视序列化边界容易导致运行时错误或隐患：

立即学习“Python免费学习笔记（深入）”；

• 试图用json.dumps()序列化datetime对象 → 报TypeError；需预处理（如转为ISO字符串）或用default参数定制
• 用pickle保存带闭包或局部函数的对象 → 反序列化失败，因依赖的命名空间不可见
• 将含数据库游标或socket连接的对象塞进Redis缓存 → 序列化可能“成功”，但还原后对象已失效，后续调用直接崩溃
• 在不受信输入上使用pickle.load() → 攻击者可构造恶意字节流，执行任意系统命令

替代思路：不序列化，也能传状态

当对象本身难以序列化时，优先考虑“传描述，不传实体”：

• 不缓存整个DataFrame，而缓存其路径+读取参数（如{"path": "data.parquet", "columns": ["a","b"]}）
• 不序列化类实例，而记录初始化所需的关键参数（如{"class": "MyModel", "params": {"lr": 0.01}}），用工厂函数重建
• 对复杂对象提供__getstate__/__setstate__方法，显式控制哪些字段参与pickle，排除不可序列化部分

序列化是工具，不是目的。判断一个对象要不要、能不能、该用哪种方式序列化，关键看它要流向哪里、由谁还原、是否可信、是否长期存储。清楚边界，才能用得稳、用得准。