优先选json用于跨语言交互，serialize()用于纯php环境且需保留完整类型、私有属性及引用关系；json安全可读兼容性强，serialize()支持更多php特有类型但存在反序列化风险。
选 JSON 还是 serialize()，关键看用途：对外交互优先 JSON，内部 PHP 存储且需保留完整类型和结构时考虑 serialize()。性能差异不大，但语义、兼容性和安全性差别明显。
数据用途决定首选
如果数据要传给 JavaScript、移动端、第三方 API 或跨语言系统，必须用 json_encode()/json_decode()。JSON 是通用文本格式，所有主流语言原生支持；而 serialize() 生成的是 PHP 专用二进制风格字符串，其他语言无法直接解析。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
如果是纯 PHP 环境下的临时缓存、Session 序列化、或写入数据库后只由本项目读取（如配置快照、任务队列 payload），serialize() 能完整保留：
• 数组键的原始类型（如整数键 0 不会变成字符串 "0"）
• null、布尔值、资源句柄外的所有 PHP 类型
• 对象的私有/受保护属性（含类名前缀）
• 数组或对象内的引用关系（如循环引用）
类型兼容性与边界情况
json_encode() 会丢弃非标量内容：
• 对象默认只序列化 public 属性；private/protected 属性不可见
• 无法直接处理资源（resource）、闭包（closure）、GMP 对象等
• 枚举（enum）默认转为标量值，丢失类型信息；需实现 JsonSerializable 接口自定义行为
• 浮点数精度受 serialize_precision 配置影响，可能截断
serialize() 的限制则不同：
• 不支持 resource 类型（如文件句柄、数据库连接）
• 某些扩展对象（如 cURL 句柄、PDOStatement）可能无法安全序列化
• 若反序列化时类定义缺失，会触发警告并返回 false；而 JSON 解码失败通常返回 null（需配合 json_last_error() 判断）
存储与安全建议
存数据库时：
• JSON 字符串可放心存在 VARCHAR 或 TEXT 字段，人类可读、便于调试
• serialize() 输出含 null 字节，**不能存入 CHAR/VARCHAR 字段**（会被截断），应使用 BLOB 或确保字段支持二进制存储（如 MySQL 的 MEDIUMTEXT 并设为 binary 校对）
安全方面：
• unserialize() 存在反序列化漏洞风险（尤其处理用户输入时），PHP 官方已明确不建议反序列化不可信数据
• json_decode() 是安全的纯解析操作，无代码执行风险
• 若必须用 serialize()，务必校验来源，并避免在 unserialize 前执行任何用户可控逻辑
性能不是主要决策依据
现代 PHP（7.4+）中，两者性能差距极小。实测常见数组规模下：
• json_encode() 略快于 serialize()（约 5–15%）
• json_decode() 通常比 unserialize() 快 10–20%，但差异随数据复杂度上升而收窄
• 真正瓶颈往往在 I/O（如数据库写入、网络传输）或后续业务逻辑，而非序列化本身
不必为微小性能差异牺牲可维护性或安全性。优先按场景选型，再用 microtime(true) 在真实环境中验证是否真成瓶颈。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
