WordPress高并发下session文件堆积导致inode耗尽，根本解决方法是将PHP session从文件系统迁移至Redis：需确保Redis服务与php-redis扩展就绪，配置CI4和WordPress共用同一Redis库但加不同key前缀（如wp_、ci_session:），并禁用文件型session插件，从而消除/tmp或/www/sess目录小文件爆炸式增长。
WordPress 默认使用 PHP 文件系统存储 session，当并发高、用户多或站点启用了大量插件（尤其含登录态、购物车、表单临时状态等）时，/tmp 或 wp-content 下的 session 文件会迅速堆积，导致磁盘 I/O 升高、inode 耗尽、甚至服务假死。这不是 WordPress 本身的问题，而是 PHP 默认 session 处理机制在高负载下的天然瓶颈。
要真正解决 WP 会话存储占用高，核心思路是：把 session 从文件系统迁移到 Redis 内存中。但注意——WordPress 官方并不直接管理 session 生命周期（它主要靠 cookie + 用户认证令牌），真正依赖原生 PHP session 的，往往是自定义功能、第三方插件（如会员系统、多步表单、CI4 集成模块等）。你提到的 “CI4Redis 会话改造”，大概率是指将 CodeIgniter 4（CI4）与 WordPress 共存时，让 CI4 的 session 也走 Redis，避免两者各自写文件造成双重压力。
下面分三块讲清楚怎么做：
✅ 确保 Redis 服务和 PHP 扩展已就位
这是前提，缺一不可：
- Redis 服务正在运行（
systemctl status redis-server返回 active） - 当前 PHP 版本已安装
redis扩展（不是memcached）：在宝塔或命令行执行php -m | grep redis，有输出即正常 - 若用宝塔：软件商店 → 找到对应 PHP 版本 → 设置 → 安装扩展 → 勾选
redis
小提示：不要用
predis（纯 PHP 客户端）替代扩展，CI4 和 WP 插件级 session 都依赖原生ext-redis才能无缝接管session.save_handler。
Redis Skill - 高性能缓存管理下载Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
✅ 改造 CI4 的 session 配置走 Redis
CI4 默认 session 存文件，需手动切到 Redis。编辑你的 CI4 项目中的 app/Config/Session.php：
public $driver = 'redis'; public $savePath = 'tcp://127.0.0.1:6379?database=1'; // database=1 避免和 WP 缓存混用 public $matchIP = false; public $timeToUpdate = 300; public $regenerateDestroy = false;
确保 savePath 中的 host、port、database 与你 Redis 实际配置一致（默认端口 6379，database 0 是常用缓存库，建议 session 单独用 database 1）。
再检查 php.ini 中是否启用：
session.save_handler = redis session.save_path = "tcp://127.0.0.1:6379?database=1"
改完重启 PHP-FPM 或 Apache/Nginx。
✅ 让 WordPress 生态不干扰、不冲突
WordPress 本身不强制用 session，但如果你在主题 functions.php 或自定义插件里写了 session_start()，就必须确保它和 CI4 共用同一套 Redis 连接参数：
-
统一 save_path：CI4 和 PHP 全局 session 必须指向同一个 Redis db（比如都用
database=1） -
加 key 前缀防碰撞：在
wp-config.php顶部加入：ini_set('session.save_handler', 'redis'); ini_set('session.save_path', 'tcp://127.0.0.1:6379?database=1&prefix=wp_');这样 WP 相关 session key 会自动带
wp_前缀，和 CI4 的ci_session:分开，互不覆盖。 - 禁用文件 session 插件：检查是否误装了“PHP Session Handler”类插件，这类插件若没配 Redis，反而会强行写文件，加重负担。
✅ 验证是否生效
- 登录服务器，执行
redis-cli -n 1 keys "*"，应看到类似wp_abc123和ci_session:xyz789的 key - 查看 PHP 错误日志（
/var/log/php-fpm/www-error.log或宝塔日志），确认无Failed to write session报错 - 用
lsof -p $(pgrep php-fpm) | grep tmp检查 php-fpm 进程是否还在频繁写/tmp下的sess_*文件 —— 正常情况下应大幅减少或消失
不复杂但容易忽略。
