OpCache 必须启用并正确配置，Redis 与 WP Super Cache 不可混用；PHP-FPM 进程数需按内存动态调整；MySQL 应开启慢日志、添加索引并增大 buffer_pool_size。
OpCache 必须开，Redis 对象缓存和 WP Super Cache 别一起用——否则缓存互相打架，首页能缓、内页全动态，还容易触发全量失效。
确认 OpCache 真正启用并调对参数
宝塔默认可能只开了 opcache.enable=1，但其他关键参数没动，等于白开。尤其 opcache.validate_timestamps=1（默认值）在生产环境会每请求都读文件时间戳，拖慢明显。
- 进宝塔 → 网站 → PHP 设置 → 配置修改，确认以下几项已设且未被注释：
opcache.enable=1-
opcache.validate_timestamps=0（上线后必须关） -
opcache.revalidate_freq=60（别设 0，否则校验太勤） -
opcache.memory_consumption=256（WordPress 插件多时，128MB 容易踢缓存） -
opcache.max_accelerated_files=7963（PHP 7.4+ 推荐质数，防哈希冲突）
改完点「重载配置」或重启 PHP，再执行 php -r "print_r(opcache_get_status()['opcache_statistics']);"，看 opcache_hit_rate 是否 ≥ 80%；低于这个数，说明缓存没真正稳住。
Redis Object Cache 要配对，别和 WP Super Cache 混用
WP Super Cache 写的是静态 HTML 文件，Redis Object Cache 缓存的是 wp_options 和数据库查询结果——两者逻辑不同，但冲突点在于：插件调用 wp_cache_flush()（比如更新设置、清空缓存）时，Redis 会清掉所有对象缓存，而 WP Super Cache 的预加载机制又依赖这些数据生成页面，一清就断链。
立即学习“PHP免费学习笔记（深入）”；
构建并排查Microsoft Word邮件合并及DOCX模板工作流，使用合并域、内容控件、文档属性、重复区块、数据等
- 如果已装 WP Super Cache，建议关掉 Redis Object Cache，专注优化其「预加载」+「缓存 PHP 页面」选项
- 如果坚持用 Redis，就禁用 WP Super Cache 的「缓存 PHP 页面」，只留「缓存静态 HTML」，并确保
object-cache.php正确放入wp-content目录（不是插件目录） - 检查 Redis 连接是否真通：在 WordPress 根目录跑
php -r "var_dump((new Redis())->connect('127.0.0.1', 6379));"，返回true才算连上
PHP-FPM 进程数不够，OpCache 再好也卡在排队
宝塔 PHP 7.4 默认用 pm = static + pm.max_children = 10，而一个 WordPress 前台页面平均占 3–5 个 PHP 进程。3 个用户同时刷页面，请求就开始排队，TTFB 直接飙到 1s+，这时查 OpCache 命中率反而虚高（因为多数请求根本没走到 PHP 执行层，卡在 FPM 队列里）。
- 进宝塔 → PHP 设置 → 配置修改 → 找到
www.conf片段，改成pm = dynamic - 按实际内存算：先跑
ps aux | grep "php-fpm: pool www" | awk '{sum+=$6} END {print sum/NR/1024 " MB"}'得单进程均值（比如 48MB） - 若服务器有 2GB 可用内存，保守给 PHP-FPM 分 1.5GB →
1536 / 48 ≈ 32，设pm.max_children = 32 - 同步调
pm.start_servers = 16、pm.min_spare_servers = 16、pm.max_spare_servers = 32
改完重启 PHP-FPM，再用 ss -s | grep "tcp:" 看 ESTAB 连接数是否回落，或者访问 /status?full（需先在 www.conf 开 pm.status_path）观察 active processes 是否长期贴近上限。
容易被忽略的 MySQL 层瓶颈
即使 OpCache 和 Redis 都跑着，WordPress 多数慢查询其实卡在数据库——比如后台文章列表页查 wp_posts，没索引的 post_status = 'publish' 条件会全表扫描；或者插件用 meta_query 查自定义字段，没加索引就更慢。
- 进宝塔 → 数据库 → MySQL 设置 → 配置修改，在
[mysqld]块末尾加： slow_query_log = 1long_query_time = 1log_queries_not_using_indexes = 1- 重启 MySQL，访问几个页面后，去日志路径（如
/www/server/data/mysql-slow.log）找含SELECT.*FROM wp_posts WHERE post_status = 'publish'的行 - 对高频查询字段加联合索引：
ALTER TABLE wp_posts ADD INDEX idx_status_type (post_status, post_type);
MySQL 的 innodb_buffer_pool_size 如果还是默认 128MB，2GB 内存服务器至少得提到 800MB，否则查询总要刷盘——这个值不改，上面所有缓存优化效果都会打折扣。
