PHP性能优化重在定位瓶颈而非死记参数，常见问题包括数据库无索引查询、同步I/O阻塞、内存滥用、Opcache未启用及自动加载低效；应通过slowlog、慢查询日志、EXPLAIN和xhprof等工具分层排查，并优先实施opcache优化、Composer类映射、SQL批量查询等见效快的措施。
PHP 性能优化基础面试问题
面试中问 PHP 性能优化，不是考你背多少参数，而是看你有没有真实调优意识和基本排查路径。重点在「知道为什么慢」和「知道怎么下手」。
常见性能瓶颈点有哪些？
PHP 层面的慢，80% 出现在这几个地方：
- 数据库查询没走索引：比如 WHERE 条件字段没建索引、用 LIKE '%xxx'、JOIN 多表没加关联索引；
- 重复加载或同步阻塞 I/O：如循环里 fopen() 读文件、curl_get_contents() 同步请求第三方接口；
- 不合理的内存使用：大数组未及时 unset、递归没设深度限制、var_dump() 或 print_r() 留在生产代码里；
-
Opcode 缓存未启用：opcache 开关关闭、缓存大小设太小（
opcache.memory_consumption=128是常用起点）； - 自动加载器效率低：PSR-4 自动加载路径配置错误导致大量 file_exists() 失败，或用了太多 classmap 却没优化 autoload_classmap.php。
如何快速定位慢请求？
别靠猜，用工具分层看：
- 先看 Web 服务器日志（Nginx/Apache）里的
$request_time或%D，确认是整体响应慢，还是某类 URL 慢； - 开启 PHP 的
slowlog（php-fpm.conf 中配slowlog = /var/log/php-fpm-slow.log+request_slowlog_timeout = 1s），直接抓出执行超时的脚本和堆栈； - 简单加
microtime(true)打点，或用xdebug.profiler_enable_trigger配合 WebGrind 查函数耗时； - 数据库层用
SHOW PROCESSLIST或慢查询日志（slow_query_log=ON），配合EXPLAIN看 SQL 是否走了索引。
几个立竿见影的优化动作
不用改架构，上线前就能做的小调整：
立即学习“PHP免费学习笔记（深入）”；
- 确保
opcache.enable=1且opcache.validate_timestamps=0（生产环境关掉时间戳校验）； - 把 Composer 的自动加载优化成静态映射：
composer dump-autoload --optimize --classmap-authoritative； - 避免在循环中做 DB 查询，改用 IN 或 JOIN 一次查完；
- 用
json_encode($data, JSON_UNESCAPED_UNICODE)替代默认选项，减少字符编码开销； - 静态资源加 HTTP 缓存头，PHP 输出前用
header('Cache-Control: public, max-age=3600')减少重复请求。
面试时怎么答才显靠谱？
别只说「加缓存」「用 Redis」。可以这样说：
- “我一般先看 slowlog 和数据库慢日志，确认是 PHP 执行慢，还是 DB 慢，或者网络 IO 慢”；
- “如果是 PHP 脚本本身慢，我会用 xhprof 或 Blackfire 快速跑一次，看哪个函数占 CPU 最多”；
- “线上不敢直接开 profiler，所以会先开 opcache slowlog，再结合 error_log 打点缩小范围”；
- “优化不是一步到位，我会对比修改前后的 ab 或 wrk 压测数据，比如 QPS 提升多少、平均响应时间降了多少。”
不复杂但容易忽略：很多性能问题，其实就卡在一条没走索引的 SQL，或一个忘关的 debug 输出上。
