在thinkphp中间件中，应在handle方法内用microtime(true)局部变量记录请求起止时间，避免静态属性或构造函数中记录；日志需结构化包含url、方法、耗时（4位小数）、状态码、ip等字段，敏感参数须过滤；禁用同步log::write()，推荐专用异步日志通道；swoole环境下须规避静态变量和全局变量，确保协程安全。
中间件里怎么拿到请求开始和结束时间
ThinkPHP 的中间件生命周期天然适合做耗时统计：在 handle 方法开头记下 microtime(true)，结尾再取一次，相减就是真实执行耗时。别用 time()，精度不够，接口耗时经常是毫秒级的。
常见错误是把时间戳存在类属性里（比如 $this->startTime），但中间件实例在一次请求中可能被复用多次，或在 Swoole 环境下跨请求残留——必须在 handle 方法内局部声明变量。
- 正确写法：
$start = microtime(true); $response = $next($request); $cost = microtime(true) - $start; - 不要在构造函数或
initialize()里记录起始时间 - 如果用了多层中间件，每个都要独立计时，别指望外层中间件“代劳”
日志内容该写哪些字段才够排障
光记个数字没用。线上出问题时，你得快速定位是哪个接口、谁调的、参数有无敏感信息、是否报错。ThinkPHP 默认日志格式太简略，建议手动拼成结构化字符串写入。
关键字段必须包含：$request->url()、$request->method()、$cost（秒，保留 4 位小数）、$response->getStatusCode()；可选但强烈建议加 $request->ip() 和 $request->header('user-agent', 'cli')。
- 敏感参数（如 password、token）必须过滤，用
array_filter($params, function($k) { return !in_array($k, ['password', 'token']); }, ARRAY_FILTER_USE_KEY) - 不要直接
var_export($request->param())，会把对象、资源拖进去导致日志写失败 - 耗时超过 1 秒的请求，建议额外打一条 warning 级别日志，方便 grep
为什么不能直接用 Log::write() 写耗时日志
ThinkPHP 的 Log::write() 是同步阻塞的，尤其在使用文件驱动时，高并发下容易卡住响应。中间件里调它，等于把接口瓶颈从业务逻辑转移到了 I/O 上。
更稳妥的做法是用 Log::channel('cost')->write() 单独配一个异步通道，或者干脆走 think\facade\Queue 推到队列里延迟写入——但注意，队列本身也有失败风险，得兜底。
- 推荐方案：配置一个专用日志通道，驱动设为
daily，并开启realtime_write => false - 避免在中间件里调
Db::table()->insert()直写数据库，连接池可能撑不住 - 如果用了 Redis 缓存中间件，可以先
$redis->lPush('api_cost_log', json_encode([...]))，再由后台脚本定时消费
在 Swoole 或 Hyperf 混合环境下要注意什么
ThinkPHP 原生不感知 Swoole 的常驻内存特性。如果你在 SwooleHttpServer 中跑 TP，并且中间件里用了静态变量或全局数组存耗时数据，下次请求会读到上一次的脏值。
另外，Swoole 的协程上下文（Co::getContext()）和 TP 的 Request 对象生命周期不一致，$request->url() 在协程切换后可能失效。必须确保所有耗时计算和日志拼装都在同一个协程内完成。
- 禁用所有
static变量缓存时间戳或请求信息 - 不要依赖
$_SERVER全局变量，改用$request->server()，它已被 TP 封装适配 - 若启用了协程池，确认日志驱动支持协程安全（如
monolog的StreamHandler需配合co::sleep()避免阻塞）
最麻烦的其实是日志膨胀和查询效率——别让耗时日志和业务日志混在一起，也别用 file 驱动存半年数据。按天切分、自动压缩、定期清理，这些事不做，后面查一条慢请求反而比写它还费劲。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
