直接缓存json字符串性能最优，避免json_decode/json_encode开销；apcu需启用并校验json合法性；redis推荐setex()设ttl；文件缓存需防并发写崩。
PHP 用 apcu_store() 缓存 JSON 字符串最直接
JSON 数据本质是字符串，缓存它不需要“解析再存”，反而先解析再序列化是多余操作，徒增开销。直接把 $json_string 当作值传给 apcu_store() 即可，读取时也原样取出——省去 json_encode()/json_decode() 循环，性能更好，也避免因精度丢失或对象/数组混用导致的意外差异。
常见错误现象：apcu_store('key', json_decode($json, true)) 后读取发现数据类型变、浮点数被截断、null 变成空数组；或者缓存命中但返回 false（因为 json_decode() 失败后返回 null，而 apcu_store() 不允许存 null）。
- 确认 APCu 已启用：
extension_loaded('apcu')返回true，且apc.enabled=1在php.ini中生效 - 缓存前建议校验 JSON 合法性：
json_last_error() === JSON_ERROR_NONE，避免把无效 JSON 存进去却查不到问题 - 键名别硬编码，建议拼接业务标识，比如
'user_profile_' . $uid，方便清理和排查
Redis 存 JSON 要注意 set() 和 setex() 的 TTL 选择
用 Redis 缓存 JSON 时，set() 默认无过期时间，容易堆积脏数据；而 setex() 强制带 TTL，更适合缓存场景。但注意：TTL 设太短会导致频繁穿透，设太长又可能数据 stale——得结合业务更新频率来定，比如用户资料 30 分钟，API 响应 5 秒。
使用场景：需要跨进程/多机器共享缓存，或已有 Redis 基础设施；不推荐仅为了缓存 JSON 单独上 Redis。
立即学习“PHP免费学习笔记（深入）”；
-
setex()是原子操作，比先set()再expire()更安全，避免中间状态丢失 - 如果 JSON 含二进制内容（如 base64 图片），Redis 默认没问题；但若含控制字符，需确保客户端连接使用
binary模式（如Predis\Client默认支持，phpredis需确认版本 ≥ 5.3.2） - 不要用
hset()存整个 JSON 字符串到 hash field，这会让 key 结构混乱，后期难以批量清理
文件缓存 JSON 用 file_put_contents() + file_get_contents() 就够了
没装 APCu、又不想引入 Redis？临时性、低并发场景下，文件缓存最轻量。关键不是“怎么存”，而是“怎么防并发写崩”——多个请求同时写同一文件，可能产生空文件或截断。
性能影响：磁盘 I/O 比内存慢 2–3 个数量级，仅适合 QPS
- 务必加锁：
flock($fp, LOCK_EX)写前锁定，写完fclose()自动释放，否则高并发下大概率出错 - 文件路径别写死，用
sys_get_temp_dir()或明确配置的缓存目录，避免权限问题 - 记得检查
file_put_contents()返回值是否为false，失败时别静默吞掉，至少记录error_get_last()
缓存失效时别忘清掉关联的 JSON 键
JSON 数据常来自数据库查询结果，一旦 DB 更新，对应缓存必须失效。最容易被忽略的是“关联键”——比如用户信息变了，除了 user_123，还有 user_list_page_1、user_search_keyword_xxx 这些也含该用户数据，但没人主动删。
复杂点在于：你没法从一个 JSON 字符串反推出它被哪些键引用过。所以设计阶段就得约定好键命名规则，并在更新逻辑里显式清理。
- 用前缀统一管理，比如所有用户相关缓存都以
user:开头，失效时apcu_delete_by_prefix('user:')（APCu ≥ 5.1.18）或 Redis 的keys user:* | xargs redis-cli del（仅开发环境，生产禁用） - 不要依赖“缓存自然过期”，尤其对强一致性要求的场景（如余额、库存），该删就删，别等 TTL
- 如果用 Memcached，没有前缀删除功能，只能靠应用层维护“键映射表”，代价高，不如换 APCu 或 Redis
