PHP跨请求缓存共享方案解析

本文深入剖析了PHP中实现跨请求共享缓存的四种主流方式——Session、Redis、APCu和文件存储，明确指出$_SESSION仅限单用户会话内共享，绝非全局缓存方案；Redis凭借跨进程、跨用户、高并发与高可靠特性成为生产环境首选；APCu在单机场景下性能卓越但无法用于集群；而手写文件缓存则因并发安全、IO瓶颈和维护风险被强烈不推荐。文章以实战视角厘清常见误区，给出配置要点、代码示例与兜底策略，帮助开发者根据实际架构（单机/集群、性能要求、容灾能力）精准选型，避免踩坑。

PHP内置的$_SESSION能跨请求共享缓存吗？

能，但仅限于用户会话维度，且必须启用session_start()。它底层依赖文件、Redis或数据库等存储引擎，不是内存级共享——不同用户间数据完全隔离，同一用户在不同请求中才能读写$_SESSION。

常见误区是以为$_SESSION能做全局缓存，比如存配置或热门商品列表，结果发现A用户改了值，B用户根本看不到。这不是bug，是设计使然。

• 必须在每个用到的脚本开头调用session_start()，否则$_SESSION为空
• session有效期由session.gc_maxlifetime控制，默认24分钟，超时后数据被清理
• 若用默认文件存储（session.save_handler = files），高并发下可能遇到文件锁阻塞，响应变慢

用Redis做PHP跨请求共享缓存最稳妥

Redis是PHP跨请求、跨用户、跨进程共享缓存的事实标准。只要所有PHP进程连的是同一个Redis实例，就能读写同一份数据。

推荐用ext-redis扩展（非phpredis旧名），连接和操作都更直接：

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->set('site_config', json_encode(['title' => 'My App', 'debug' => false]));
$config = json_decode($redis->get('site_config'), true);

• key命名建议加前缀，如cache:product:1024，避免冲突
• 务必设过期时间，用$redis->setex('key', 3600, $value)代替set，防止缓存无限堆积
• 如果Redis宕机，代码里要包try/catch，降级到直查数据库，别让整个页面崩掉

APCu适合单机PHP-FPM进程间共享，但不能跨机器

apcu_store()和apcu_fetch()在单台服务器上性能极高，因为数据存在PHP进程共享内存里，不走网络。但它只对当前服务器上的所有PHP-FPM worker进程有效，Nginx+PHP-FPM架构下能用，集群或多台Web服务器就完全失效。

典型误用场景：本地开发用APCu没问题，一上生产负载均衡环境，缓存就“时有时无”，其实是不同请求打到了不同机器上。

• 检查是否启用：extension=apcu.so + apc.enabled=1（PHP 8+默认开启）
• APCu缓存不自动序列化，存数组/对象需手动serialize()，取回再unserialize()
• 用apcu_clear_cache('user')可清空用户缓存，但生产环境慎用，会影响所有正在运行的请求

file_get_contents() + file_put_contents()临时共享？风险很高

有人用文件硬存JSON当缓存，靠file_get_contents('cache.json')读，file_put_contents()写。这看似简单，实际问题密集：

• 并发写入时大概率出现数据截断或覆盖，PHP没内置文件写锁保障
• 每次读写都是磁盘IO，QPS上来后I/O成为瓶颈，比Redis慢1~2个数量级
• 文件权限、路径硬编码、清理机制缺失，容易变成线上定时炸弹

除非是极低频、单机、无人值守的脚本（比如每小时跑一次的报表生成），否则别碰。

真正需要跨请求共享，优先选Redis；单机小项目且确定不扩容，APCu够用；Session只用于用户状态；手写文件缓存——多数时候只是把问题往后拖。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《PHP跨请求缓存共享方案解析》文章吧，也可关注golang学习网公众号了解相关技术文章。