PHP 中 session 数据不能直接 json_encode
直接对 $_SESSION 调用 json_encode() 很可能返回空字符串或报错，尤其是当 session 里存了资源句柄（如 fopen() 返回的 file pointer）、闭包、对象但没实现 JsonSerializable，或者开启了 session.use_strict_mode=1 且 session 尚未启动。
真正能安全序列化的，只有标量、数组、以及可被 JSON 序列化的对象。常见踩坑点：把数据库连接、cURL handle、mysqli 实例塞进 $_SESSION 后再尝试转 JSON —— 这些值在 json_encode() 时会被静默忽略或触发警告。
- 务必先调用
session_start()，否则$_SESSION是未定义的 - 用
array_filter($_SESSION, 'is_scalar')快速筛出基础类型值（但会丢掉嵌套数组） - 更稳妥的做法是显式构造白名单数组：
$safe = ['user_id' => $_SESSION['user_id'], 'role' => $_SESSION['role']]
用 json_encode 处理 session 前必须清理不可序列化内容
PHP 的 session 数据本质是 PHP 序列化格式（serialize()），和 JSON 不兼容。强行转，等于拿二进制杂糅体去喂 JSON 解析器 —— 不报错已是侥幸。
典型错误现象：json_encode($_SESSION) 返回 false，配合 json_last_error_msg() 查到 "Type is not supported"；或者返回空字符串，但 var_dump() 显示 $_SESSION 明明有数据。
立即学习“PHP免费学习笔记（深入）”；
- 检查是否有对象：用
array_walk_recursive($_SESSION, function($v) { if (is_object($v)) { echo get_class($v); } }) - 避免存储
DateTime对象，改用时间戳time()或 ISO8601 字符串 - 若必须存对象，确保其实现
JsonSerializable接口，或提前调用__toString()/format()转成字符串
session_write_close() 后再 json_encode 更安全
PHP 默认 session 是阻塞式文件锁，如果在脚本中途调用 json_encode($_SESSION)，而 session 文件还没释放，可能引发并发写冲突或意外延迟 —— 尤其在 AJAX 请求或 CLI 场景下。
这不是 JSON 本身的问题，而是 session 生命周期管理疏忽导致的副作用。比如在输出 JSON 响应前没关 session，后续请求卡住等锁。
- 在确定不再读写 session 后，立刻调用
session_write_close() - 之后再执行
json_encode($safe_session_data)，彻底规避锁竞争 - 注意：关掉后
$_SESSION变为只读，再赋值无效，所以清理和提取必须在这之前做完
替代方案：用 $_SESSION 当缓存，JSON 存储走 Redis 或临时数组
硬要把 session 转 JSON，往往说明设计上混淆了「状态维持」和「数据交换」两个目标。Session 是服务端状态容器，JSON 是跨系统数据载体 —— 它们职责不同。
更合理的做法是：只把需要外发的数据（如用户基本信息、权限列表）从 $_SESSION 提取出来，组成独立数组，再 json_encode()；其余 session 内容（如 flash 消息、表单 token）留在原处不动。
- 不要用
json_encode($_SESSION)做“备份”或“调试打印”，改用print_r($_SESSION, true) - 如需持久化结构化数据，优先考虑
Redis::set('sess_json_' . session_id(), json_encode($data)) - 前端要读用户信息？后端提供
/api/user/profile接口，返回精简 JSON，而不是暴露整个$_SESSION
session 和 JSON 的交集很小，强行融合只会放大类型不匹配、锁竞争、调试困难这些问题。真正该花时间的，是厘清哪些数据属于会话状态，哪些属于 API 响应载荷。
