性能监控这事儿，说大不大，说小不小。很多团队开发阶段跑得顺，一上线就卡成幻灯片，往往就差在“看不见”这三个字上。ThinkPHP跑在Linux环境里，到底怎么监控才能心里有底？不绕弯子，直接聊几条经过实战检验的路径。
1. 自定义中间件记录请求性能
从实践中间出发，第一个要推荐的方法，就是借助ThinkPHP的中间件机制。这个方案的好处是轻量、灵活，特别适合快速定位那些“不知道哪里慢”的请求。
具体步骤也不复杂：在app/middleware目录下新建一个PerformanceMiddleware.php，核心逻辑就是记录请求开始的时间，等请求执行完毕后，再记录一次结束时间，顺便抓一下峰值内存消耗。把这些信息写入日志，你就拥有了每个请求的基础性能快照。
- 创建中间件：
app/middleware目录下新建PerformanceMiddleware.php，代码如下：namespace appmiddleware;use thinkfacadeLog;use thinkmiddlewareBaseMiddleware;class PerformanceMiddleware extends BaseMiddleware{public function handle($request, Closure $next){$start_time = microtime(true); // 记录开始时间$response = $next($request); // 执行请求$end_time = microtime(true); // 记录结束时间$cost_time = $end_time - $start_time; // 计算耗时$memory_usage = memory_get_peak_usage(true) / 1024 / 1024; // 峰值内存（MB）Log::info("请求路径：{$request->path()} | 耗时：{$cost_time}秒 | 内存：{$memory_usage}MB"); // 写入日志return $response;}} - 注册中间件：在
app/middleware.php中全局注册（或按路由分组注册都一样）：return [appmiddlewarePerformanceMiddleware::class,]; - 效果：日志会乖乖躺在
runtime/log目录下，路径、耗时、内存一目了然，后续排查慢请求时就是现成的线索。
2. 集成第三方专业监控工具
如果项目已经进入生产环境，光靠日志手工翻，效率就有点跟不上了。这时就该专业工具上场，实现从追踪到报警再到可视化的完整闭环。
- Prometheus + Grafana：这套组合拳在社区里很成熟。先在Prometheus的
prometheus.yml里把ThinkPHP应用加为抓取目标（比如job: 'thinkphp'），然后通过中间件或现成的扩展（比如think-prometheus）把请求量、耗时、错误率这些指标暴露成Prometheus格式的HTTP端点。最后在Grafana里配好数据源，导入社区已有的ThinkPHP Dashboard模板，实时可视化面板就直接跑起来了。 - New Relic / Datadog：这类商业工具更“傻瓜式”，装好对应的PHP Agent（比如New Relic的
newrelic-php5扩展），把应用密钥填进去，剩下的就看平台上的实时数据吧。请求时间、数据库查询、缓存命中率，甚至分布式追踪和告警通知都替你安排好了。
3. 利用ThinkPHP内置日志功能
别小看ThinkPHP自带的日志系统，配置得当的话，它完全可以充当基础监控的底座。在config/log.php里把日志级别设好，生产环境建议只开error和warn，免得日志膨胀太快。存储路径配置成runtime_path('log')，就齐活了。
代码里手动记录关键操作的耗时也很顺手。比如数据库查询跑慢了，直接写一条info日志带上SQL和执行时间；接口响应超时了，写一条warn日志带上路径。这样一来，不管是用tail、grep现场排查，还是接入ELK这样的日志分析平台，历史性能问题都能被扒出来。
4. 结合Linux系统命令监控资源
很多时候，应用慢不一定是代码的问题，而是服务器的资源到了瓶颈。Linux自带的命令行工具这时候就是最趁手的兵器。
- top / htop：实时看CPU和内存占用，按进程排序，一眼就能发现谁在吃资源。
- vmstat 1：每秒输出一次系统整体状态。重点关注
r（运行队列）、b（阻塞进程）和free（空闲内存）。如果r长期大于CPU核数，那进程排队的问题就很明显了。 - iostat -x 1：磁盘IO的“照妖镜”。
%util超过70%意味着磁盘快撑不住了，await数值偏高则说明IO等待时间长。 - netstat -tulnp：查网络连接状态，端口占用、连接数都能看到，网络层的问题逃不过。
举个例子：用top发现PHP-FPM进程CPU占用过高，调整pm.max_children参数就能缓解；用iostat发现磁盘IO吃紧，优化数据库索引或者加一层缓存，往往比改代码更直接。
5. 优化缓存减少性能开销
最后这一点，其实是最容易被忽视的“提效捷径”。缓存做得好，很多性能问题根本不会出现。
- 页面缓存：在控制器里用
cache方法缓存静态内容。比如首页的生成逻辑可以包在闭包里，设置3600秒的缓存时间，用户访问时直接拿缓存，不跑视图逻辑。 - 模板缓存：在
config/template.php里开启tpl_cache并设置tpl_cache_time，页面模板就不会每次请求都重新编译了。 - 数据库查询缓存：用Redis或Memcached缓存高频查询结果。就像商品分类、配置信息这种被频繁调用的数据，直接用
Cache::store('redis')->remember(...)组合，既保证了数据新鲜度，又大幅降低了数据库压力。
这几条路径从轻量级日志到企业级监控工具，基本覆盖了ThinkPHP性能监控的各个层次。项目刚起步时，中间件加日志就够用；规模上去后，Prometheus和Grafana是标配；资源层面出了问题，Linux命令就是最后的兜底。怎么组合，看项目的实际需要就好。
