thinkphp 6.x需同时配置app_debug=true、注册tracedebug中间件、trace类型设为file、日志level含debug且启用trace通道，才能开启慢请求堆栈采样；仅靠app_debug或日志无法记录完整调用栈。
ThinkPHP 6.x 如何开启慢请求堆栈采样
默认不开启，必须手动配置中间件 + 日志级别 + trace 开关三者协同，缺一不可。仅开 app_debug 或仅写日志不会记录完整调用栈。
- 确保
app_debug = true（app.php中），否则所有 trace 逻辑被跳过 - 在
app/middleware.php中注册think\middleware\TraceDebug中间件（TP6.1+ 默认已配，但需确认未被注释） - 设置
trace' => ['type' => 'html']或'type' => 'file'（app.php的trace配置项），type为html时仅在浏览器显示，不落盘；要分析堆栈必须用file - 关键：在
log.php中将level设为['error', 'info', 'debug']，且trace日志通道需启用 —— 否则think\facade\Trace::dump()调用不会写入文件
如何定位单个接口的耗时热点和调用栈
TP 自带的 think\facade\Trace 不直接暴露调用栈深度，得靠 debug_backtrace() 手动打点，配合 microtime(true) 做区间采样。
- 在控制器入口加
Trace::start('api_start')，出口加Trace::end('api_start')，可测整层耗时，但看不到内部函数级热点 - 真正抓热点要插桩：在可能慢的环节（如
Db::table()->where()->select()、Http::get()、Cache::get()前后）手动记录时间戳 +debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 10) - 注意
debug_backtrace()第二个参数控制栈深度，设太小（如 3）会漏掉关键中间件或模型方法；设太大（>20）影响性能，建议 8–12 - 不要在循环里频繁调用，一次请求最多插 3–5 个关键点，否则日志爆炸且失真
为什么 think\facade\Trace::save() 不保存调用栈？
因为 Trace::save() 只序列化当前 trace 数据快照（SQL、路由、变量等），不包含运行时堆栈。它本质是“快照记录器”，不是 profiler。
-
Trace类里没有内置调用栈采集逻辑，它的__call()方法只处理预设 key（如sql、route），对backtrace这类动态数据无响应 - 想存堆栈，必须自己调用
debug_backtrace()并显式写进日志：例如Log::info('slow_db_call', ['backtrace' => debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 10)]) - TP 的
Log默认会自动 JSON 化数组，但debug_backtrace()返回的数组含资源/闭包时会报错，务必加DEBUG_BACKTRACE_IGNORE_ARGS参数过滤 - 别用
var_export()或print_r()直接塞进日志——会产生大量不可读的嵌套字符串，后续 grep 分析困难
生产环境能否用类似方案做轻量采样？
能，但必须关闭全量 trace，改用条件触发 + 低频采样，否则 I/O 和 CPU 开销会反噬性能。
- 禁用
TraceDebug中间件，改用自定义中间件，在handle()中判断请求路径、耗时阈值（如 >500ms）、或随机概率（如rand(1, 100) === 1）决定是否采样 - 采样时只记录关键帧：入口时间、DB 耗时、HTTP 调用耗时、最终响应时间，再补一层
debug_backtrace()到 Controller 方法即可，不必每层都采 - 日志写入必须异步：用
Log::channel('slow')->write(...)指向独立文件通道，并在log.php中配置'realtime_write' => false，避免阻塞主流程 - TP7 将移除
Trace类的 HTML 输出能力，trace配置项语义更偏向调试开关而非监控，老项目升级前需重写采样逻辑
调用栈不是越深越好，关键是把 DB、HTTP、Cache 这三类外部依赖的上下文链路串起来。没串上中间件或服务容器注入点的栈，基本等于没采。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
