OPcache预加载和APCu预热是ThinkPHP 8.0性能关键，需分别配置php.ini中opcache.preload路径和手动调用apcu_store；漏掉任一，接口响应仍慢。
接口响应慢，不是框架不行，而是 OPcache 没预热、热点数据没常驻——这两步漏掉，ThinkPHP 8.0 再快也跑不起来。
OPcache 预加载（preload）必须配对 php.ini + preload.php
只改 opcache.enable=1 不够，opcache.preload 是独立开关，不配它，PHP 启动时根本不会提前编译任何文件。
-
opcache.preload必须写在 php.ini 的[opcache]段落里，路径要绝对且可读：比如opcache.preload=/var/www/tp8/runtime/preload.php -
preload.php里不能用require_once APP_PATH . 'common.php'这类动态路径，所有require必须是字面量字符串，否则预加载失败静默跳过 - ThinkPHP 8.0 的核心类（如
think\Container、think\App、think\facade\Db）建议全量预加载；vendor 里的psr/container、psr/simple-cache也应包含，但不要 include 整个 vendor/autoload.php —— 它会触发自动加载器，破坏预加载语义 - 验证是否生效：重启 PHP-FPM 后执行
php -v，输出末尾应带(with Zend OPcache, preloaded)字样；再用opcache_get_status()['preload_statistics']查看scripts数量是否 > 0
APCu 预热必须避开 ThinkPHP 缓存层直接调用
用 Cache::store('apcu')->get() 或 Cache::get() 永远做不到“常驻”，因为它们走的是驱动封装，每次请求仍需解析 key 前缀、反序列化、加锁——和 Redis 一样有开销。
- 真正有效的写法只有
apcu_store('hot_user_ids', $ids, 3600)和apcu_fetch('hot_user_ids')，绕过框架缓存抽象层 - 预热时机不能放在中间件或控制器里：首次请求才执行，首屏必然卡顿；必须用命令行触发，例如新建
app/command/PreloadHotData.php，在部署脚本中跑php think preload:hot - 检查
apcu.enabled=1和apcu.shm_size=64M（不是 32M），否则高并发下很快写满，apcu_cache_info()['mem_size']接近apcu.shm_size就得扩容 - 别存大数组：APCu 对 value 大小敏感，单条超 1MB 容易触发写失败；超过 10 万条 ID 就该分片，比如
hot_user_ids_0~hot_user_ids_9
validate_timestamps=0 不等于可以不重启服务
设成 0 确实禁掉了运行时文件校验，但代码更新后，旧 opcode 仍在内存里——用户看到的还是老逻辑，这不是缓存命中率问题，是缓存污染。
立即学习“PHP免费学习笔记（深入）”；
- 上线新版本后，必须执行
opcache_reset()或重启 PHP-FPM；opcache_reset()更轻量，但仅对当前 worker 生效，多进程下需配合kill -USR2（PHP-FPM）或systemctl reload php-fpm -
opcache_get_status()['opcache_enabled']为 true 且['memory_usage']['used_memory'] > 0才算真启用；如果['cache_full']为 true，说明opcache.memory_consumption太小，得调大 - JIT 编译依赖 OPcache，若
opcache.jit=1255但opcache_get_status()['jit']['enabled']是 false，先查zend_jit_is_enabled()返回值，再确认opcache.jit_buffer_size是否 ≥128M（PHP 8.2+ 要求 ≥256M）
预加载和 APCu 预热不是一劳永逸的事——ThinkPHP 8.0 的路由、配置、Schema 缓存都得单独维护，而 OPcache 本身不感知这些变化；改了路由规则却不重跑 php think optimize:route，或者更新了数据库字段却不刷新 Schema 缓存，性能优化反而会掩盖真实瓶颈。
