dump() 不显示或为空因HTTP头已发送导致输出缓冲失效；trace面板需APP_DEBUG=true且非CLI环境，halt()会跳过其渲染。
为什么 dump() 有时不显示、或显示成空白？
因为 ThinkPHP 的 dump() 默认依赖 html_entity_decode() 和输出缓冲，一旦页面已发送 HTTP 头（比如提前 echo、开启 session、或前置中间件输出），dump() 就会静默失败，甚至导致“headers already sent”错误。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确保在控制器方法最开始调用
dump()，避开任何可能触发输出的逻辑（如Session::start()、日志写入、header()） - 若必须在响应后调试，改用
think\facade\Log::debug()记录到日志文件，再配合tail -f runtime/log/*.log实时查看 - 在 CLI 环境下
dump()会自动降级为var_dump()，但不会加 HTML 格式——这是正常行为，不是 bug
trace() 的开关和位置怎么配才不漏信息？
trace() 不是函数，而是 ThinkPHP 内置的调试面板入口，它的可见性完全由配置驱动。默认只在 APP_DEBUG = true 且请求为 HTTP（非 CLI）时启用，且需满足「当前请求未被缓存」+「未禁用 trace 配置」两个条件。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 检查
config/app.php中'trace' => true是否开启（5.1+ 版本默认开启，但 6.x 某些模板项目可能关掉） - 确认
APP_DEBUG是布尔true，而不是字符串"true"—— 字符串会导致 trace 面板直接不加载 - 如果用了 Nginx + FastCGI，注意
fastcgi_buffering off或设置output_buffering = Off，否则 trace 面板 JS/CSS 可能被截断
用 halt() 中断执行时，为什么 trace 面板没出来？
halt() 是硬终止，它会跳过所有后续生命周期钩子（包括 trace 面板的渲染逻辑），所以你只会看到原始 var_dump 输出，而看不到顶部的 tab 式调试面板。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 想保留 trace 面板就别用
halt()，改用throw new \think\Exception('debug stop')，这样异常会被框架捕获并展示在 trace 面板的「Exception」tab 里 - 如果只是临时打断流程看变量，优先用
dump($var); exit;，比halt()更可控 -
halt()在 CLI 下会直接退出进程，trace 面板天然不可用——这点容易被忽略，尤其在写命令行任务时
自定义 trace 面板里加自己的调试数据，要改哪儿？
ThinkPHP 允许通过 think\facade\Debug::remark() 和 think\facade\Debug::getRemark() 注入标记点，这些会自动出现在 trace 面板的「Debug」tab 下，无需修改核心代码。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在关键路径开头加
Debug::remark('before_query');，结尾加Debug::remark('after_query');，面板里就能看到耗时差值 - 避免在循环内高频调用
Debug::remark()，它会累积内存，影响 trace 渲染速度（尤其是大数据量场景） - 想加结构化数据（比如 SQL 参数），用
Debug::remark('sql_bind', $params)，trace 面板会自动识别并格式化数组/对象
trace 面板的数据收集是惰性的，只有在最终渲染阶段才汇总；所以中间件里提前抛出异常、或 response 被手动 send()，都会导致部分调试数据丢失——这点没有报错提示，得靠经验排查。
