不换框架也能把 PHP 应用响应时间砍掉 70% ​

设想这样一个场景：接手一个平均响应时间 840 毫秒的 PHP 应用。

它没坏，也没崩。只是慢——那种用户能感知到的慢，那种会出现在 Core Web Vitals 报告里的慢，那种监控面板已经默默记录了好几个月，而团队的注意力却一直放在需求迭代上的慢。

应用是 Laravel，数据库是 MySQL，服务器是配置合理的云主机。代码库存在了三年，前后有十七位开发者在上面修改过。谁也没有做过大动作，慢是一点点累积起来的，就像技术债务惯常累积的方式那样。

接手这样一个项目时，直觉往往是归咎于框架。Laravel 太重了，也许该考虑更轻量的方案；也许该用原生 PHP 重写关键路径；也许该迁移到微服务架构。

这些直觉都是错的。它们代价高、风险大，并且几乎都没有必要——因为瓶颈几乎从来不在框架本身。

下面要讲的是真正的瓶颈在哪里、如何被定位，以及具体做了哪些改动，把平均响应时间从 840 毫秒降到 250 毫秒。没有换框架，没有换基础设施，没有重写。

TL;DR 速览 ​

瓶颈包括：长期未修复的 N+1 查询、两张高流量表缺失的索引、几乎每次请求都会加载但很少用到的会话数据、在引导阶段做了昂贵工作的自动加载服务提供者，以及让首屏传输增加了 400 毫秒的未压缩静态资源。

所有改动集中投入的时间约为三周，铺排在两个月的周期里完成。

响应时间总体改善：840 毫秒 → 平均 250 毫秒，降低约 70%。

业务逻辑没有改动任何一行。框架并不是问题所在。

定位全部瓶颈所使用的工具：Laravel Debugbar、Telescope、EXPLAIN、Blackfire——在花一分钱升级基础设施之前就已经可用。

本文要点 ​

• 如何系统地剖析一个 PHP 应用，而不是靠猜测判断瓶颈
• 真实代码库中的 N+1 查询模式，以及如何彻底消除
• PHP opcode 缓存是什么，为什么它永远应是第一项检查
• HTTP 响应缓存如何让符合条件的请求完全绕过服务端
• 会话与服务提供者自动加载——那个常被忽略测量的启动成本
• 静态资源分发——那 400 毫秒其实和 PHP 毫无关系
• 如何正确度量，才能判断一项改动是否真的有效

动手之前先做度量 ​

设想一下，花两周优化了错误的地方：给一个 3 毫秒就能返回的查询加上 Redis 缓存；重写一个每天只调用两次的服务类；把真实的工程时间投入到对用户感知延迟贡献为零的事情上。

缺乏度量就动手优化，就会变成这个样子。任何性能工程的开端都应遵循同一个纪律：动手之前先做剖析。

本次排查使用的工具栈：

• Laravel Debugbar——在开发环境安装，按请求维度展示查询数量、查询耗时、内存占用以及加载了哪些服务提供者。第一天就安装好。
• Laravel Telescope——记录每一次请求、查询、任务和异常，并提供可搜索的界面。用来在上千次真实请求中寻找模式，而不仅仅是当下手动触发的那几次。
• MySQL 慢查询日志，开启 log_queries_not_using_indexes = ON——在生产环境的只读副本上运行，以避免主库被额外开销影响。它能捕获每一个走全表扫描的查询。
• Blackfire——函数级别的剖析器，不只是到查询级别。当 Debugbar 定位了大致区域之后，用 Blackfire 定位到具体行。它不是免费的，但对严肃的性能工作而言物有所值。

基线数据：任何改动之前，所有核心端点都在一个接近生产配置、灌入生产规模数据的预发环境中用 ab -n 100 -c 10 进行压测。每一项优化都相对这条基线衡量。如果数字没有变化，改动会被回滚。

原则是：改动之前度量，改动之后度量，相信数字而不是直觉。

瓶颈一，N+1 查询（节省约 180 毫秒） ​

第一次使用 Debugbar 就暴露出任何运行超过一年的 PHP 应用最常见的性能问题：N+1 查询。

受影响最严重的端点是订单仪表盘——一个展示最近五十条订单的页面，包含客户名、商品数量和状态。Debugbar 显示这个页面发出了 54 次查询，而理论上一次就够。

// 控制器——看起来人畜无害
$orders = Order::latest()->take(50)->get();
return view('dashboard.orders', compact('orders'));

{{-- 模板——N+1 藏在这里 --}}
@foreach ($orders as $order)
    <tr>
        <td>{{ $order->customer->name }}</td>      {{-- 每个订单一次查询 --}}
        <td>{{ $order->items->count() }}</td>       {{-- 每个订单一次查询 --}}
        <td>{{ $order->latestStatus->label }}</td>  {{-- 每个订单一次查询 --}}
    </tr>
@endforeach

五十条订单，每条访问三个关联。加上最初一次查询，总计 151 次查询。

修复方式——对视图中访问到的每个关联使用预加载：

$orders = Order::with(['customer', 'items', 'latestStatus'])
    ->latest()
    ->take(50)
    ->get();

查询数量降为 4 次（订单、客户、商品、状态各一次），从 151 次降下来。

对应端点的页面加载时间：720 毫秒 → 190 毫秒。

但仪表盘并不是唯一问题。Debugbar 在所有核心端点上都运行了一遍，Telescope 里搜索了查询次数超过 20 次的请求。整轮审计结束后，在代码库中共发现并修复了十四处独立的 N+1 模式。所有端点合起来平均节省了大约 180 毫秒。

根本原因并不是大意，而是 Eloquent 的懒加载——默认行为会在访问关联时隐式地发出查询，而且发生在模板中。每一次关联访问在 Blade 中都像普通的属性读取，没有任何迹象表明它其实是一次数据库查询。

Laravel 8+ 引入了 Model::preventLazyLoading()——在未进行预加载就访问关联时抛出异常：

// AppServiceProvider::boot()
Model::preventLazyLoading(! app()->isProduction());

这样就能在开发阶段捕获 N+1，而不是等它流入生产。该设置一经启用后，再未出现新的 N+1 漏到线上。

瓶颈二，两个缺失的索引（节省约 210 毫秒） ​

慢查询日志（在只读副本上启用，long_query_time = 0.5）显示有两条查询占据了绝大部分条目：

-- 查询 1：24 小时出现 847 次，平均 380 毫秒
SELECT * FROM products WHERE category_id = ? AND is_active = 1 ORDER BY sort_order ASC;

-- 查询 2：24 小时出现 1,203 次，平均 290 毫秒
SELECT * FROM orders WHERE customer_id = ? AND status IN ('pending', 'processing');

两条都做了 EXPLAIN：

EXPLAIN SELECT * FROM products WHERE category_id = ? AND is_active = 1 ORDER BY sort_order ASC;
-- 结果：type = ALL，key = NULL，rows = 284,000

对一张 284,000 行的表做全表扫描，每天 847 次。category_id 列没有索引，is_active 没有，sort_order 也没有。

-- 通过迁移新增：
ALTER TABLE products
    ADD INDEX idx_category_active_sort (category_id, is_active, sort_order);

ALTER TABLE orders
    ADD INDEX idx_customer_status (customer_id, status);

加上索引之后：

EXPLAIN SELECT * FROM products WHERE category_id = ? AND is_active = 1 ORDER BY sort_order ASC;
-- 结果：type = ref，key = idx_category_active_sort，rows = 43
-- Extra: Using index（覆盖索引——完全不需要回表）

检查行数从 284,000 降到 43。ORDER BY 由索引天然覆盖，不需要额外的 filesort。

查询 1：380 毫秒 → 2 毫秒。查询 2：290 毫秒→ 4 毫秒。

命中这两条查询的端点平均响应时间节省约 210 毫秒。

两个列从应用上线之初就存在于表结构中，从未加过索引。数据量较小时这些查询"足够快"，因此没人注意。一旦商品增长到 28.4 万条、订单增长到 120 万条，"足够快"也就不复存在了。

瓶颈三，OPcache 配置不当（节省约 95 毫秒） ​

这一条有点令人尴尬。

PHP 执行每个 .php 文件之前都要先把它编译成字节码。如果没有 OPcache，这个编译会在每次请求中重复进行——自动加载器引入的每个文件、Laravel 启动时加载的每个类、执行时编译的每个 Blade 模板，全部都要重新来一遍。

OPcache 会把编译后的字节码放在内存里，后续请求直接跳过编译步骤，加载已编译的字节码。对一个每次请求加载数百个类文件的 Laravel 应用而言，这笔节省相当可观。

OPcache 是装好的（PHP 7.0+ 自带），但采用了默认配置，严重限制了它的有效性：

; 默认配置——对 Laravel 来说不够用
opcache.memory_consumption = 128      ; 对完整 Laravel 应用来说偏小
opcache.max_accelerated_files = 2000  ; Laravel 需要 10000+
opcache.validate_timestamps = 1       ; 每个请求都检查每个文件是否变更

问题在于 opcache.max_accelerated_files = 2000：一旦缓存文件数超过上限，OPcache 会悄悄把文件从缓存里驱逐，被驱逐的文件下一次请求又要重新编译。一个包含 vendor 目录的 Laravel 应用轻松就能超过 10,000 个文件。

调整后的配置：

; php.ini——生产环境 OPcache 配置
opcache.enable                 = 1
opcache.memory_consumption     = 256      ; 足以容纳所有文件
opcache.max_accelerated_files  = 20000    ; 对 Laravel + vendor 绰绰有余
opcache.validate_timestamps    = 0        ; 生产禁用——由部署脚本负责清理
opcache.revalidate_freq        = 0        ; validate_timestamps = 0 时无意义
opcache.interned_strings_buffer = 16
opcache.fast_shutdown          = 1

生产环境设置 opcache.validate_timestamps = 0 意味着 PHP 不再检查文件是否变更——始终使用缓存的字节码。前提是部署脚本在每次发布后清理 OPcache：

# 部署脚本，在文件更新之后执行
php artisan opcache:clear
# 或者直接：
php -r "opcache_reset();"

正确配置 OPcache 之后，平均响应时间下降了大约 95 毫秒。这也是改动最简单的一项——仅修改配置文件——却带来了第三大幅度的改善。

验证 OPcache 是否工作正常的简便方法：

// 临时诊断端点（确认后请移除）
$status = opcache_get_status();
echo "Cached scripts: " . $status['opcache_statistics']['num_cached_scripts'];
echo "Memory used: "    . round($status['memory_usage']['used_memory'] / 1024 / 1024, 1) . "MB";
echo "Hit rate: "       . round($status['opcache_statistics']['opcache_hit_rate'], 2) . "%";

命中率低于 95% 说明 OPcache 在驱逐文件——需要增大 opcache.memory_consumption 和 opcache.max_accelerated_files。

瓶颈四，每次请求都加载会话（节省约 45 毫秒） ​

Laravel 的会话中间件会为每一次请求加载会话——包括完全没有会话概念的 API 端点、Webhook 处理器和健康检查 URL。

本项目的会话存储走的是数据库（保存于 sessions 表）。凡是经过会话中间件的请求都会执行：

SELECT * FROM sessions WHERE id = ?   -- 读取会话
UPDATE sessions SET ... WHERE id = ?  -- 写入会话（哪怕是只读请求）

每次请求两次 SQL，每一个端点都不例外，哪怕它从未调用 session()。在那些承载最高流量的 API 端点上，这完全是纯粹的开销。

修复分为两步。

第一步：把高流量的 API 路由移出会话中间件组。

// routes/api.php——不使用会话的 API 路由
Route::withoutMiddleware([StartSession::class, ShareErrorsFromSession::class])
    ->group(function () {
        Route::get('/products',         [ProductController::class, 'index']);
        Route::get('/products/{id}',    [ProductController::class, 'show']);
        Route::post('/webhooks/stripe', [StripeWebhookController::class, 'handle']);
    });

第二步：把剩余的会话存储从数据库切换到 Redis。

数据库会话需要 SQL 查询，Redis 会话只是一次内存键值查找，性能差距是数量级的：

// config/session.php
'driver' => env('SESSION_DRIVER', 'redis'),

对于确实需要会话数据的端点，Redis 查询大约 1 毫秒，替代了原来约 12 毫秒的数据库查询。

综合所有端点，平均节省约 45 毫秒。

瓶颈五，服务提供者全量自动加载（节省约 55 毫秒） ​

Laravel 每次请求都会引导所有已注册的服务提供者。config/app.php 的 providers 数组有 34 项，其中不少只在特定场景下才会用到。

Blackfire 揭示了两个消耗了过多引导时间的元凶：

• 一个 PDF 生成包，它在服务提供者中连接了外部字体授权 API——哪怕当前请求根本不生成 PDF。每次请求的启动开销大约 30 毫秒，来自于服务提供者构造函数里的外部 HTTP 调用。
• 一个遗留的报表包，每次启动都会加载并编译一个 400KB 的配置文件。

修复方式：

使用延迟提供者，让 PDF 服务按需加载：

// PdfServiceProvider.php
class PdfServiceProvider extends ServiceProvider
{
    // 延迟提供者只会在服务真正被使用时引导
    protected $defer = true;

    public function provides(): array
    {
        return [PdfGenerator::class];
    }

    public function register(): void
    {
        $this->app->singleton(PdfGenerator::class, function () {
            // 只有第一次解析 PdfGenerator 时才会执行这段昂贵的初始化
            return new PdfGenerator(config('pdf'));
        });
    }
}

缓存报表包的配置：

// ReportingServiceProvider.php
public function boot(): void
{
    $config = Cache::remember('reporting_config', 3600, function () {
        return $this->loadExpensiveConfiguration();
    });

    $this->app->singleton(ReportingEngine::class, fn () => new ReportingEngine($config));
}

合计大约节省 55 毫秒，适用于之前会被强制加载这两个提供者的所有请求。

更广义的经验是：config/app.php 里的每一个服务提供者都会在每次请求中执行。运行 php artisan route:list 并按使用情况过滤，然后对每个提供者自问：是不是真的每一个端点都需要它在启动阶段就位？如果答案是否定的，就延迟它。

瓶颈六，HTTP 响应缓存（对符合条件的请求节省约 120 毫秒） ​

并不是所有请求都需要落到 PHP 上。

商品列表页——整个应用中流量最高的端点——对所有未登录用户返回完全相同的内容。相同的 HTML，由相同的数据库查询构建，带着相同的静态资源，每分钟重复几百次。

通过反向代理（这里是 Nginx）做 HTTP 响应缓存，可以直接从内存返回这些响应，完全绕过 PHP、MySQL 以及整个应用栈：

# nginx.conf
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m max_size=1g
                 inactive=60m use_temp_path=off;

server {
    location / {
        proxy_cache            app_cache;
        proxy_cache_valid      200 60s;  # 成功响应缓存 60 秒
        proxy_cache_key        "$scheme$request_method$host$request_uri";
        proxy_cache_bypass     $http_authorization; # 已鉴权请求不缓存
        proxy_cache_bypass     $cookie_session;     # 已登录用户请求不缓存

        add_header X-Cache-Status $upstream_cache_status;
        proxy_pass             http://php_upstream;
    }
}

PHP 侧的响应也要配合输出合适的缓存响应头：

// 可缓存端点的控制器
public function index(): Response
{
    $products = Cache::remember('products:listing', 60, fn () =>
        Product::active()->with('category')->get()
    );

    return response()
        ->view('products.index', compact('products'))
        ->header('Cache-Control', 'public, max-age=60')
        ->header('Vary', 'Accept-Encoding');
}

Vary: Accept-Encoding 头保证 Nginx 为使用 gzip 的客户端和未使用 gzip 的客户端分别缓存对应版本，这对压缩响应处理很重要。

以商品列表端点为例：

• 改造前：每次请求 → PHP → MySQL → 220 毫秒
• 改造后（缓存未命中）：首个请求 → PHP → MySQL → 220 毫秒，响应写入 Nginx 缓存
• 改造后（缓存命中）：后续请求 → Nginx 直接从内存返回 → 约 8 毫秒

24 小时之后商品页面的缓存命中率达到 94%。该端点的平均响应时间从 220 毫秒降到大约 21 毫秒（已考虑剩余 6% 的未命中）。

所有符合缓存条件的端点汇总下来，这部分在关键指标上——也就是高流量端点上——额外节省了约 120 毫秒。

瓶颈七，未压缩的静态资源（首次加载节省约 400 毫秒） ​

这一条和 PHP 毫无关系。

应用通过 HTTP/1.1 直接分发未压缩的 JavaScript 和 CSS。主 bundle 未压缩总大小 2.4MB。在典型宽带网络下，这意味着 400–600 毫秒的传输时间，浏览器才能开始渲染。

修复包含三部分：

在 Web 服务器上启用 gzip 压缩：

# nginx.conf
gzip              on;
gzip_types        text/plain text/css application/javascript application/json;
gzip_min_length   1000;
gzip_comp_level   6;
gzip_vary         on;

JavaScript 的压缩比大约 70%，2.4MB 的 bundle 变成了 720KB。

使用 Vite 进行预压缩（适用于 Laravel Mix / Vite 用户）：

// vite.config.js
import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import viteCompression from 'vite-plugin-compression';

export default defineConfig({
    plugins: [
        laravel({ input: ['resources/css/app.css', 'resources/js/app.js'] }),
        viteCompression({ algorithm: 'gzip' }),    // 生成 .gz
        viteCompression({ algorithm: 'brotli' }),  // 生成 .br
    ],
});

为静态资源加上 Cache-Control：

location ~* \.(js|css|png|jpg|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

带内容哈希文件名的资源（Vite 的默认行为）可以缓存一整年——相同 URL 永远对应相同内容。

主 bundle 的首次加载传输时间：480 毫秒 → 95 毫秒。

这部分节省不会体现在服务端响应时间里，而是体现在 Core Web Vitals、LCP、Time to Interactive 上。这些指标全部显著改善，真实用户体验显著改善，而服务端本身并未发生任何变化。

最终数字概览 ​

对每项优化都以基线为参照记录：

服务端平均响应时间：840 毫秒 → 235 毫秒（下降 72%）。包含静态资源传输的首次加载体验显著改善，具体幅度取决于用户网络。

不是每一项节省都能作用到每一次请求。会话的节省只对 API 端点生效；响应缓存的节省只对可缓存端点生效；N+1 的修复覆盖面最广；索引的改进主要影响高流量端点。

按流量权重加权之后的综合平均值落在 250 毫秒，足够支撑"下降 70%"这个描述——在真正有意义的维度上是准确的。

框架从来不是问题 ​

把性能问题归咎于框架，这种想法几乎总是错的，而且往往是面对慢应用时代价最高的一种应对方式。

在配置合理的服务器上，Laravel 相对于同等工作量的原生 PHP 脚本大约带来 10–15 毫秒的额外开销。这个开销是真实存在的，但在本项目 840 毫秒的问题里它占比还不到 5%。

其余的 95%——N+1、缺失索引、错配的 OPcache、会话开销、服务提供者浪费、未压缩的静态资源——没有一项是 Laravel 的问题。它们是应用层的问题。在 Symfony、CodeIgniter 乃至原生 PHP 里同样会出现。框架不是制造这些问题的原因，也没办法替开发者预防它们，因为本质上这些都是度量和纪律的问题。

设想另一条路径：花六个月重写框架。新的代码库、重写的测试、迁移风险、团队上下文切换，放弃六个月的业务迭代。到头来，新框架里仍然存在同样的 N+1，因为没人去找；缺失的索引依然缺失，因为没人跑过 EXPLAIN；OPcache 依然配置错误，因为之前就错，这次也没人再检查。

更换框架解决不了应用层面的性能问题，只是把问题换到了另一个代码库里。

需要避开的陷阱 ​

不度量就优化。本次项目里每一次改动都有改动前后的数据佐证。有两次改动被回滚，因为数字并不支持当初的判断。相信剖析器，不要相信直觉。

在修复查询之前就到处加缓存。给慢查询套一层缓存只是掩盖问题，并不能解决。缓存命中时是快了，缓存过期之后问题依旧。先修查询本身，合适时再叠加缓存。

把 opcache.validate_timestamps = 0 打开却不在部署时清理缓存。如果部署流程没有清理 OPcache，发布之后用户看到的仍会是上一版代码的字节码。每一个部署脚本都必须包含 opcache_reset()。

缓存已鉴权用户的响应。任何包含用户专属数据——账号信息、个性化内容、CSRF 令牌——的响应都不能由反向代理缓存。proxy_cache_bypass $cookie_session 不是可选项。做错会把用户 A 的响应返回给用户 B。

延迟存在依赖关系的服务提供者。延迟加载仅当启动过程中没有其他代码依赖它时才是安全的。在把一个提供者标记为延迟之前，要检查其他提供者中的所有 app()->make() 与 app()->bind() 调用。

在开发环境度量。开发环境的 OPcache 配置、数据规模、并发水平都和生产不同，还常常启用了 Xdebug，这些都会严重影响耗时。度量只能放在与生产等价的预发环境中。

简明 Q&A ​

Q：怎么知道 OPcache 确实在工作？
用 opcache_get_status()['opcache_statistics']['opcache_hit_rate'] 查看命中率。低于 95% 通常意味着发生了驱逐，需要调大内存与文件上限。命中率为 0% 一般代表 OPcache 被禁用，或者 CLI 与 FPM 配置不一致（它们各自维护独立的 OPcache 池）。

Q：应该在应用层还是 HTTP 层做缓存？
两者各有用途。应用层缓存（Redis、Memcached）适合昂贵计算、数据库查询结果以及用户专属数据；HTTP 层缓存（Nginx、CDN）适合完全公开、内容一致的响应。HTTP 缓存更快，因为它完全绕过 PHP——只要内容公开且允许短时间的陈旧，就应该优先使用。

Q：在 Laravel 代码库中定位 N+1 的最快方式是什么？
在非生产环境启用 Model::preventLazyLoading()。任何懒加载的关联访问都会抛出异常，修复它们就变成必须完成的事。对于线上代码，Laravel Telescope 的查询面板按查询数过滤高开销请求，可以还原真实流量里的 N+1 模式。

Q：Blackfire 值得付费吗？
对严肃的性能工程而言值得。它在函数与方法层面揭示执行时间，不止停留在查询层面。免费档位能覆盖大多数优化场景，付费档位增加持续剖析与 CI 中的性能测试。本文这种排查工作，免费档位已经够用。

Q：HTTP 缓存响应的失效怎么处理？
使用较短的 TTL（对大多数目录页来说 60 秒已经足够激进），并尽量使用基于内容哈希的缓存键。对那些变化不频繁、但一旦变化需要立刻生效的数据，可以借助缓存标签（Nginx 商业模块或 Varnish 都支持），在内容变更时精确失效对应条目，而不是等待 TTL 到期。

7 天迷你方案 ​

第 1 天：安装 Laravel Debugbar，在流量最高的 5 个端点上运行，记录每个请求的查询数量与查询总耗时。

第 2 天：修复第 1 天发现的全部 N+1，并在非生产环境启用 Model::preventLazyLoading()。

第 3 天：在副本或预发服务器上启用 MySQL 慢查询日志并打开 log_queries_not_using_indexes = ON，对最慢的 5 条查询执行 EXPLAIN。

第 4 天：补齐缺失索引，重新 EXPLAIN 确认索引被使用，记录改动前后的响应时间。

第 5 天：检查 OPcache 配置，确认命中率在 95% 以上。如有必要，调大内存与文件上限，并确保部署脚本清理 OPcache。

第 6 天：审查会话中间件，把它从不使用会话的 API 路由和 Webhook 处理器中移除。如果还在使用数据库会话，迁移到 Redis。

第 7 天：在 Web 服务器启用 Gzip 压缩，记录改动前后的 TTFB 与 First Contentful Paint。

需要跟踪的关键指标是 P95 响应时间，而不是平均值。平均值会掩盖长尾延迟——最慢的那 5% 请求常常比中位数慢十倍，代表了最差的用户体验。把 P95 拉下来，平均值自然会跟着走。

需要避免的常见错误：只在开发环境或者启用 Xdebug 的情况下度量。Xdebug 会给 PHP 执行带来 2–10 倍的开销，任何在其启用状态下的测量结果对性能优化都没有参考价值。请在与生产等价、未启用 Xdebug 的环境中进行剖析。

行动号召 ​

读者遇到过最意外的 PHP 性能瓶颈是什么？那种最后查出来和一开始怀疑完全不同的情况？

欢迎在评论区分享。最值得记录的性能故事，往往都是"问题出在谁都没想过去看的地方"——那个已经错误存在两年的 OPcache 配置、那个每次请求都在向外部 API 报到的服务提供者、那个只因为字段名看起来"理所应当"就被忽略添加的索引。

如果本文为读者提供了一套可执行的性能排查方法，请转发给同样在拖延此事的同行。剖析器早就装好了，慢查询日志只需要五分钟就能启用。其余步骤都会从度量中自然浮现。

回到开头 ​

设想半年后打开监控面板，P95 响应时间是一条平直的绿色曲线，稳定在 250 毫秒。不是因为重写了任何东西，不是因为换了框架，不是因为迁移到了新的数据库引擎。

而是因为去看了时间真正被消耗在哪里，修复了那些真正慢的地方，并且通过度量确认改动真的起到了作用。

这就是性能优化的全部。不靠直觉，不靠换框架，不靠在应用效率达标之前先扩容。

度量。修复。再度量。

那 70% 的改进一直就在那里。

"相关问答"——8 个常见问题 ​

1. 不换框架的前提下如何改善 PHP 应用的响应时间？
先用 Laravel Debugbar、Telescope 和 MySQL 慢查询日志做剖析。最常见的瓶颈包括：N+1 查询（用预加载修复）、缺失的数据库索引（跑过 EXPLAIN 之后补齐）、错配的 OPcache（检查命中率与文件上限）、非会话路由上的会话开销（移除对应中间件）、未压缩的静态资源（在 Web 服务器开启 Gzip/Brotli）。

2. OPcache 是什么，它如何提升 PHP 性能？
OPcache 把编译后的 PHP 字节码放在内存里，避免每次请求重新解析和编译。没有它，每次请求都要把涉及的所有文件重新编译一遍。对加载大量文件的框架型应用来说，配置得当的 OPcache 能把 PHP 执行时间降低 50%–80%。

3. 如何在 Laravel 应用中找到 N+1 查询？
在 AppServiceProvider 中启用 Model::preventLazyLoading()。没有预加载的关联访问都会抛出异常，强制在开发阶段解决每一个 N+1。对现有生产代码，用 Laravel Debugbar 查看按请求维度的查询数量，用 Laravel Telescope 按查询次数高的请求做过滤。

4. Laravel 生产环境的 OPcache 应该用什么配置？
设置 opcache.memory_consumption = 256、opcache.max_accelerated_files = 20000、opcache.validate_timestamps = 0（并在部署脚本中清理 OPcache）。默认配置对 Laravel 来说不够——2000 的文件上限在包含 vendor 依赖的完整 Laravel 工程中会导致持续驱逐。

5. PHP 应用应该用 Redis 还是数据库会话？
生产环境建议 Redis。数据库会话每次请求都要执行读+写两条 SQL，而 Redis 会话是内存键查找，仅需约 1 毫秒。规模越大，性能差距越明显。另外，彻底从 API 路由、Webhook 处理器以及其他不使用会话的端点中移除会话中间件。

6. 如何在 Nginx 中缓存 PHP 的 HTTP 响应？
在 nginx.conf 中配置 proxy_cache_path，并在 server 块中添加 proxy_cache、proxy_cache_valid、proxy_cache_bypass 等指令。设置 proxy_cache_bypass $cookie_session，确保不缓存已鉴权响应。在 PHP 控制器里对可缓存端点输出 Cache-Control: public, max-age=N 响应头。

7. PHP 应用响应时间里框架开销占多少？
对配置合理的 Laravel 或 Symfony 应用，框架开销大约 10–15 毫秒。在响应很慢的应用里，这通常还不到总响应时间的 5%。其余 95%+ 几乎都是应用层问题：多余的查询、缺失的索引、错配的缓存、低效的资源分发。

8. PHP 性能优化首选的剖析器是什么？
Blackfire 是最精细的 PHP 剖析器，可以到函数和方法级别定位执行时间，还能与 CI 集成做持续性能测试。对大多数 Laravel 优化工作，Laravel Debugbar 和 Telescope 提供的可见度已经足够，还是免费的。Debugbar 定位到慢区域但无法精确到行时，再用 Blackfire。

基准说明：文中的响应时间数字（840 毫秒的基线、各项优化对应的节省）是真实一类 PHP 性能项目的代表性数据，为了叙事清晰做了归并处理。实际结果会因服务器硬件、数据规模、流量模式以及既有配置而显著不同。请在自己的环境中进行基准测试——方法论比具体数字更有参考价值。