PHP项目优化应从真实瓶颈出发，通过慢日志、火焰图和SQL分析精准定位问题，聚焦数据库N+1、低效PHP执行及缓存策略，以最小改动实现可衡量提升。
PHP 项目优化不是堆砌技术名词，而是从真实瓶颈出发，用最小改动换取可衡量的性能提升。面试中考察的不是“你会不会用 OPcache”，而是“你能不能定位问题、权衡取舍、讲清为什么这么改”。
从慢请求日志切入，不猜，只看数据
优化的第一步永远是确认瓶颈在哪。盲目加缓存、换数据库、重写逻辑，大概率白忙活。
- 打开 slowlog（php-fpm.conf 中配置
slowlog = /var/log/php-fpm-slow.log和request_slowlog_timeout = 500ms），真实捕获超时请求的调用栈 - 结合 XHProf 或 Blackfire 做一次典型接口的火焰图分析，重点关注函数耗时占比高、调用次数异常多的节点（比如某个 ORM 方法被循环调用了 200 次）
- 检查 MySQL 的 slow_query_log，配合
EXPLAIN看是否缺失索引、是否触发了 filesort 或临时表
数据库层：减少往返，拒绝 N+1，善用连接池
PHP 应用的性能瓶颈，八成出在数据库交互上。重点不在“查得快”，而在“少查、查准、查得省”。
- 用 Eager Loading 替代懒加载：Laravel 的
with('user.profile')、ThinkPHP 的with(['user', 'category'])，避免循环中查数据库 - 批量操作代替单条：插入 100 条记录，用
INSERT INTO ... VALUES (...), (...), (...)一条语句搞定，而非 100 次INSERT - 读写分离 + 连接复用：用 PDO 长连接（
PDO::ATTR_PERSISTENT => true）降低握手开销；主库写，从库读，但注意从库延迟导致的数据不一致场景（如刚注册就跳转个人页）
PHP 层：别让脚本为重复劳动买单
很多性能损耗来自 PHP 自身的低效执行，而这些完全可控。
立即学习“PHP免费学习笔记（深入）”；
- 开启并验证 OPcache：确保
opcache.enable=1、opcache.validate_timestamps=0（生产环境），且opcache.memory_consumption足够（建议 128M+）；用opcache_get_status()确认命中率 > 95% - 避免运行时解析：把 JSON 配置、YAML 路由规则等，在部署时编译成原生 PHP 数组（如 Laravel 的
php artisan config:cache），省去每次请求的文件读取和解析开销 - 谨慎使用
__get/__set等魔术方法：它们比直接属性访问慢 3–5 倍；高频访问字段（如$user->name）建议用普通 public 属性或 getter 内联
缓存策略：分层设计，失效可控
缓存不是“加个 Redis 就完事”，关键在粒度、时效和一致性。
-
页面级缓存：适合内容稳定、更新频率低的列表页（如帮助中心），用 Nginx 的
proxy_cache最轻量，无需 PHP 参与 -
数据级缓存：用户资料、商品详情等，用 Redis 存序列化数组（
json_encode），设置合理 TTL（如 30 分钟），并配合“双删”或“延时双删”保证 DB 更新后缓存及时失效 - 本地缓存兜底：对极高频、极少变更的配置（如支付开关、短信模板 ID），用 APCu 缓存，避免网络 IO；但注意 APCu 是进程级，FPM 下每个 worker 独立，需预热
真正落地的优化，往往是一次 SQL 改写 + 一个 with 预加载 + 开启 OPcache，三处改动，接口响应从 1200ms 降到 180ms。比起炫技，面试官更想听你讲清楚：当时怎么发现的、为什么选这个方案、有没有副作用、上线后怎么验证效果。
