生产环境laravel应用性能问题主因是部署配置缺失：必须成套执行config:cache、route:cache、view:cache；cache_driver和session_driver强制切redis；app_debug=false且log_level=error；启用opcache并配合composer --no-dev --optimize-autoloader。
生产环境的 Laravel 应用跑得慢、日志爆炸、缓存不生效，基本不是代码问题，而是部署时漏掉了几个关键配置动作。这些动作必须在 composer install 之后、Web 服务启动之前完成，且不可逆——比如 config:cache 一旦执行，.env 变更就不再实时生效。
config:cache / route:cache / view:cache 必须成套执行
这三个命令不是可选优化项，而是生产环境的强制前置步骤。单独执行其中某一个，反而可能引发隐性冲突：
-
config:cache后，所有env()调用被固化为常量值，.env修改无效；但若没同时执行route:cache，路由仍会尝试动态解析配置里的中间件名，导致 500 错误 -
route:cache要求所有路由定义不依赖闭包（即不能写Route::get('/', function () { ... })），否则直接报错Unable to serialize closure -
view:cache不影响 Blade 语法，但会跳过每次请求的模板编译；若你用了@includeWhen($condition, 'partial')这类运行时逻辑，需确认其行为是否符合预期
推荐在部署脚本中统一执行：
php artisan config:cache && php artisan route:cache && php artisan view:cache
CACHE_DRIVER 和 SESSION_DRIVER 必须切到 Redis
默认的 file 驱动在生产环境是定时炸弹：高并发下文件锁争抢严重，跨服务器部署时 session 完全不共享，缓存失效后还可能残留 stale 文件。Redis 不是“更好”，而是“唯一可行”：
- 确保 PHP 已启用
redis扩展（php -m | grep redis），且php-fpm已重启 -
.env中必须显式设置：CACHE_DRIVER=redis、SESSION_DRIVER=redis、QUEUE_CONNECTION=redis - 不要复用同一 Redis DB：建议
CACHE_REDIS_DATABASE=0、SESSION_REDIS_DATABASE=1、QUEUE_REDIS_DATABASE=2，避免 key 冲突或误清空 - 验证方式不是看
Cache::put()是否返回 true，而是用redis-cli -n 0 keys "*"确认 key 真实写入
APP_DEBUG=false 和 LOG_LEVEL=error 缺一不可
APP_DEBUG=false 关的不只是错误页面——它会禁用 Laravel 的全部调试钩子，包括 Query Log、事件监听器堆栈、视图调试信息。但很多人只改这一项，却忘了日志级别：
-
LOG_LEVEL=debug或LOG_LEVEL=info在生产环境等于主动制造 I/O 瓶颈，尤其当 Eloquent 模型触发大量toArray()或日志里混入用户数据时 -
DB_LOG_QUERIES=true必须设为false，否则每条 SQL 都会被序列化进日志，磁盘空间几小时就爆满 - 检查
config/logging.php中stackchannel 是否包含daily驱动，并确认days参数设为 7 或更小，避免日志无限堆积
OPcache + --no-dev + --optimize-autoloader 是三重保险
PHP 层面的性能损耗往往比框架层更隐蔽。这三项必须同时生效：
- OPcache 需在
php.ini或opcache.ini中启用：opcache.enable=1、opcache.enable_cli=1、opcache.interned_strings_buffer=16，且opcache.revalidate_freq=0（生产环境禁止运行时校验） -
composer install --no-dev --optimize-autoloader -o中的-o是关键：它生成 classmap，让自动加载跳过 PSR-4 的目录扫描，对大型项目提速明显 - 如果项目完全不使用
class_alias()或运行时动态类名，可加--classmap-authoritative进一步关闭 autoloader 的 fallback 机制
最容易被忽略的是 OPcache 的 opcache.validate_timestamps=0 —— 一旦设为 0，PHP 就再不会检查 PHP 文件是否被修改，所以每次部署后必须手动 sudo systemctl reload php*-fpm 或调用 opcache_reset()，否则新代码永远不会生效。
