laravel 上线后响应慢的首要排查点是 php-fpm 配置调优：应将 pm 改为 static/dynamic，合理设置 pm.max_children；关闭未使用的 status/ping 接口；设 request_terminate_timeout=30s；开启并优化 opcache（enable=1、validate_timestamps=0、memory_consumption≥128mb）；nginx 需正确配置静态资源缓存、path_info 解析及 storage 映射；确保 .env 和 storage 权限正确（www-data 所属、644/755），并部署时清空配置与缓存。
PHP-FPM 配置调优是 Laravel 上线后响应慢的首要排查点
很多 Laravel 应用一上云服务器就卡，不是代码问题，而是 php-fpm 默认配置太保守。它常以 ondemand 模式启动，请求一多就排队等进程，504 Gateway Timeout 或高延迟随之而来。
实操建议：
- 把
pm改成static或dynamic，并根据服务器内存设合理值（比如 2GB 内存的机器，pm.max_children = 20是较安全起点） - 关掉
pm.status_path和ping.path（除非真要监控），它们会额外引入 IPC 开销 -
request_terminate_timeout建议设为30s，避免长请求拖垮整个池；Laravel 的队列或大文件上传应走异步，不该卡在 FPM 进程里 - 检查
php-fpm.conf中是否启用了slowlog，上线后保留它，能快速定位卡住的请求
OPcache 必须开启且禁用验证，否则 autoload 效率打五折
Laravel 大量依赖 Composer 自动加载，没开 OPcache 或开着却验证文件时间戳（opcache.validate_timestamps=1），等于每次请求都重新解析几百个 PHP 文件。
实操建议：
- 确认
opcache.enable=1、opcache.enable_cli=1（Artisan 命令也受益） - 生产环境务必设
opcache.validate_timestamps=0，改代码后用php artisan opcache:clear或重启php-fpm -
opcache.memory_consumption至少设为128（MB），Laravel + 常用包一般占 60–90MB，留余量防抖动 - 别碰
opcache.fast_shutdown—— PHP 8.0+ 已废弃，设了反而报Unknown opcode
Nginx 静态资源缓存和 PATH_INFO 陷阱要一起处理
很多人配完 Laravel 的 try_files $uri $uri/ /index.php?$query_string 就以为完事，结果 CSS/JS 不缓存、$_SERVER['PATH_INFO'] 为空、Storage 链接 404，全是 Nginx 规则漏项。
实操建议：
- 对
.css、.js、.woff2等加expires 1y和add_header Cache-Control "public, immutable" - 确保
location ~ \.php$块里有fastcgi_split_path_info ^(.+\.php)(/.+)$;和fastcgi_param PATH_INFO $fastcgi_path_info;，否则路由模型绑定或Request::path()可能出错 -
storage/app/public要用alias映射，别用root，否则符号链接权限容易崩；路径末尾斜杠必须一致，alias /var/www/html/storage/app/public/;和location /storage/要严格匹配
Env 文件和日志权限是上线后 500 错误最常被忽略的两个点
.env 权限不对，PHP 读不到配置，APP_KEY 缺失 → Target class [App\Http\Controllers\...] does not exist；日志目录不可写 → 所有错误静默，只留空白页。
实操建议：
-
.env必须属主为 web 用户（如www-data），权限644或更严（600），绝不能777或属主是 root -
storage/logs和storage/framework要递归 chown 到 web 用户，并确保写权限（chmod -R 755 storage/足够，不用 777） - 部署脚本里加一句
php artisan config:clear && php artisan cache:clear，避免旧配置残留；但别在部署中执行php artisan migrate，除非你确定锁表不影响线上 - 用
php -d display_errors=Off -d log_errors=On artisan tinker快速验证 PHP 是否真按预期加载了配置和扩展
真正卡住人的从来不是 Laravel 本身，而是 PHP 运行时、Web 服务器、Linux 权限这三层交界处那些不报错、只沉默的细节。
