应启用OPcache、Redis和APCu三级缓存：OPcache禁用文件校验（opcache.validate_timestamps=0）以消除I/O开销，Redis缓存高频数据避免数据库查询，APCu提供进程内轻量缓存；三者协同可将Lumen响应压至20ms以内。
直接启用 OPcache + Redis + APCu 三级缓存，再关掉 opcache.validate_timestamps，响应时间通常能压到 20ms 以内。Lumen 本身轻量，慢几乎都出在 PHP 解析、数据库查、重复加载上，不是框架问题。
OPcache 必须开且禁用文件校验
Lumen 启动快，但没 OPcache 时每次请求都要重编译 PHP 文件，尤其路由和中间件多的时候，CPU 耗在解析上。8.2 默认可能没开，或只开了 CLI 模式。
-
opcache.enable=1和opcache.enable_cli=1都要设为 1（FPM 和 CLI 都走缓存） -
opcache.validate_timestamps=0生产环境必须关——否则每秒都去磁盘 check 文件修改时间，I/O 拖垮性能 -
opcache.revalidate_freq=0配合上一条，避免无效轮询 - 改完重启
php8.2-fpm，用opcache_get_status()确认opcache_enabled为 true 且used_memory在增长
Redis 缓存高频数据，别碰 Eloquent 自带的 cache() 方法
Lumen 的 Cache::remember() 底层走的是配置驱动，如果配成 file 或 array，等于白搭。必须显式配 Redis，并绕过 Eloquent 的懒加载陷阱。
- 确保
CACHE_DRIVER=redis，且REDIS_HOST、REDIS_PORT在.env里正确 - 查用户配置这类不变数据，直接用
Cache::get('config:api_timeout')，别写User::find(1)->settings再缓存 - 避免在循环里调
Cache::has()+Cache::get()，合并成Cache::many(['key1', 'key2']) - Eloquent 的
->cacheFor(3600)在 Lumen 里默认不生效——它依赖 Laravel 的事件系统，Lumen 默认关了
中间件里别做耗时操作，尤其是 auth 和日志
Lumen 中间件是同步链式执行的，一个卡住，整个请求就 hang。JWT 解析、DB 查询、远程 HTTP 调用放中间件里是常见雷区。
立即学习“PHP免费学习笔记（深入）”；
- JWT 校验用
firebase/php-jwt直接解 token，别查数据库验证jti是否存在（除非真需要黑名单） - 日志中间件别记录完整
$request->all()，用$request->only(['id', 'action'])控制字段 - 跨域（CORS）中间件用现成的
fruitcake/laravel-cors，别自己手写 header 设置——Lumen 8.2 对header()调用更敏感，容易触发“headers already sent” - 自定义中间件参数要用冒号传，比如
throttle:60,1，别在 handle 里硬编码阈值
数据库连接复用和预处理语句不能省
Lumen 默认用 PDO，但没开持久连接、没设预处理，高并发下光建连就能吃掉 50ms+。
- 在
config/database.php的 MySQL 配置里加'options' => [PDO::ATTR_PERSISTENT => true] - 所有查询走
DB::select('SELECT * FROM users WHERE id = ?', [$id])，别拼字符串 - 批量操作用
DB::table('logs')->insert($batch)，别在 foreach 里反复->create() - 查关联数据别用 Eloquent 的
with()，Lumen 的自动加载没优化好，容易 N+1；手动 join 或分两步查
最易被忽略的是 OPcache 的 validate_timestamps 和数据库连接的 PDO::ATTR_PERSISTENT——这两个开关一开一关，响应时间波动常超 300%，比换框架还管用。
