Tracy 比 var_dump 更适合调试，因其自动捕获异常/错误/警告、显示调用栈/SQL/内存/请求参数并自带UI界面；var_dump 易导致 headers already sent 错误且信息杂乱。
Tracy 为什么比 var_dump 更适合开发调试
因为 Tracy\Debugger 不只输出变量，它会自动捕获未捕获异常、错误、PHP 警告，还能显示调用栈、SQL 查询、内存使用、请求参数——而且默认带 UI 界面，点开就能看上下文。而 var_dump 一刷屏就找不到关键信息，还容易触发 headers already sent 错误。
常见错误现象：Warning: Cannot modify header information - headers already sent，就是因为提前输出了 var_dump 或 echo；Tracy 默认用输出缓冲 + JavaScript 注入，不干扰响应流。
- 必须在脚本最开头（甚至
require前）启用：Tracy\Debugger::enable() - 开发环境才开，生产环境禁用：
Tracy\Debugger::enable(Tracy\Debugger::DEVELOPMENT) - 不要和
error_reporting(E_ALL)冲突——Tracy 已接管错误处理，重复开启反而掩盖真实问题
如何让 Tracy 显示 SQL 查询和性能数据
Tracy 本身不执行 SQL，但能“钩住” PDO、MySQLi、Nette\Database 等操作。关键不是配置 Tracy，而是让数据库层把查询日志交给它。
使用场景：查接口慢、想确认某次请求到底执行了几条 SQL、有没有 N+1 查询。
立即学习“PHP免费学习笔记（深入）”；
- 如果是 Nette\Database：
$connection->getProfiler()->setPanel('database')就够了，Tracy 自动识别 - 如果是原生 PDO，得手动记录：
Tracy\Debugger::log("SELECT * FROM users", 'database') - 注意
Tracy\Debugger::log()第二个参数是分组名，填'database'才会归到“Database”面板里 - 性能影响：仅开发环境生效，且日志只存内存，不影响响应速度
Tracy 报错 “Cannot redeclare class Tracy\Debugger” 怎么办
这是典型的自动加载冲突，常见于 Composer 自动加载和手动 require 并存时。Tracy 的类被加载了两次，PHP 直接报致命错误。
常见错误现象：Fatal error: Cannot redeclare class Tracy\Debugger，出现在启用后第一行。
- 检查是否同时用了
require 'vendor/tracy/tracy/src/Tracy/Debugger.php'和require 'vendor/autoload.php' - 删掉所有手动
requireTracy 文件的代码，只保留require 'vendor/autoload.php' - 确认
composer.json里没重复 require 同一个包（比如既写了"tracy/tracy"又写了"nette/tracy"） - 运行
composer dump-autoload清理加载映射
怎么在 CLI 脚本里用 Tracy 查错误
CLI 模式下 Tracy 不弹 Web 面板，但它会把错误转成彩色终端输出，并保留完整堆栈——比 PHP 原生错误可读性强得多。
使用场景：跑 cron、队列任务、migration 脚本时出错，不想切日志文件翻找。
- 必须显式设置环境：
Tracy\Debugger::enable(Tracy\Debugger::CONSOLE) - 不能用
Tracy\Debugger::enable()默认模式，否则会尝试写 HTML 到 stdout，导致乱码 - CLI 下
Tracy\Debugger::log()会输出到php://stderr，可用2>&1 | grep "my_tag"过滤 - 如果脚本 fork 了子进程，每个进程要单独调用
enable()，Tracy 不跨进程共享状态
Tracy 的坑不在功能多，而在“太安静”——它默认只对未捕获异常和错误出手，如果你用 try/catch 吞掉了异常又没手动 Tracy\Debugger::fireLog()，那错误就真的消失了。
