线上商城部署前必须检查5个PHP配置项：opcache.enable=1且validate_timestamps=0、memory_limit≥256M（建议512M）、max_execution_time=30、upload_max_filesize与post_max_size同步调高但不超过client_max_body_size、display_errors=Off且log_errors=On。
PHP 线上商城部署前必须检查的 5 个配置项
直接上线 localhost 跑通的商城代码，90% 会在生产环境出问题。不是代码有 bug，而是 PHP 运行时环境没对齐。
重点核对以下配置（以 PHP 8.1+ + Nginx 为例）：
-
opcache.enable=1且opcache.validate_timestamps=0（上线后必须关掉热重载，否则每次请求都校验文件时间戳） -
memory_limit至少设为256M，含图片上传、PDF 生成等模块时建议512M -
max_execution_time=30—— 别改大！超时应由前端降级或队列异步处理，而非延长脚本生命周期 -
upload_max_filesize和post_max_size需同步调高，但别超过 Nginx 的client_max_body_size，否则会卡在 413 错误 - 关闭
display_errors=Off，打开log_errors=On，错误日志路径确保 Web 用户可写（如/var/log/php-fpm/www-error.log）
Nginx + PHP-FPM 高并发下最常被忽略的瓶颈点
压测时 QPS 上不去，第一反应是“加机器”，其实 70% 的情况卡在 PHP-FPM 进程模型和 Nginx 缓冲区协同上。
关键参数组合要匹配：
立即学习“PHP免费学习笔记（深入）”；
- PHP-FPM 的
pm = static或pm = dynamic？小流量用dynamic，但高并发必须用static并固定pm.max_children；算公式：max_children ≈ 总内存 × 0.8 / 单个 PHP 进程平均内存（用ps aux --sort=-%mem | head -n 5观察） - Nginx 的
fastcgi_buffer_size和fastcgi_buffers必须覆盖商城典型响应体（商品列表 JSON 约 8–15KB），建议设为fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; -
fastcgi_busy_buffers_size至少是fastcgi_buffer_size的 2 倍，否则缓冲区满会导致 502 - 务必开启
fastcgi_keep_conn on;，让 Nginx 与 PHP-FPM 复用 TCP 连接，减少三次握手开销
MySQL 查询慢？先看这 3 个商城高频误操作
订单页加载 3 秒？别急着加索引。先查是否踩了这些坑：
- 在
ORDER BY created_at DESC LIMIT 20前没加WHERE status IN ('paid', 'shipped')—— 全表扫描百万订单再排序，索引失效 - 用
SELECT *查商品详情，实际只用 4 个字段，却把description（TEXT 类型）、images_json（可能几 MB）全拖过来，带宽和序列化都成瓶颈 - 购物车合并逻辑写成
INSERT ... ON DUPLICATE KEY UPDATE，但UNIQUE KEY只建在user_id上，导致锁整张表；正确做法是UNIQUE KEY (user_id, sku_id)
临时缓解：给慢查询加 SQL_NO_CACHE（仅调试），长期方案是用 EXPLAIN FORMAT=JSON 看执行计划，重点关注 type 是否为 range 或 ref，而非 ALL。
静态资源与 API 分离后，CDN 回源怎么不打垮 PHP
把 JS/CSS/图片扔到 CDN 后，看似省了带宽，但用户首次访问 HTML 仍要走 PHP 渲染，而 HTML 里内联的 api/v1/products?category=phone 请求，若没做限流，CDN 大量并发回源会瞬间打满 PHP-FPM。
必须做的两件事：
- 所有 API 接口强制加
X-Requested-With: XMLHttpRequest校验，并在 Nginx 层用limit_req限制频率，例如：limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api/ {
limit_req zone=api burst=20 nodelay;
} - HTML 页面里的关键数据（如导航栏分类、热销榜）改用
Edge Side Includes (ESI)或服务端 SSI 包含，让 CDN 缓存主页面，只回源请求动态片段 - 避免在
标签里拼接用户 ID 做自动登录态请求，这类 JS 会被 CDN 缓存并跨用户复用，造成数据错乱或越权
真实线上环境里，优化效果往往取决于最弱的一环——可能是某条没走索引的统计 SQL，也可能是 CDN 配置漏掉了 Cache-Control: private 导致用户信息泄露。盯住监控里的 slowlog、php-fpm.status 和 MySQL Slow_queries，比盲目调参有用得多。
