PHP错误显示需error_reporting与display_errors配合生效：前者设错误级别（如E_ALL），后者控制是否输出；Tracy调试需Debugger::enable()在首行调用且无前置输出，日志路径须确保权限与时区正确，生产环境应关display_errors但开log_errors。
PHP 的 error_reporting 和 display_errors 怎么配才生效
PHP 调试模式不是开个开关就完事，display_errors 必须配合 error_reporting 才能真正看到错误。常见现象是开了 display_errors = On 却看不到 Notice，因为默认 error_reporting 可能被设为 E_ALL & ~E_NOTICE 或更保守的值。
实操建议：
-
error_reporting推荐设为E_ALL（开发环境），或E_ALL & ~E_DEPRECATED & ~E_STRICT（兼容老项目） -
display_errors = On仅对 Web SAPI（如 Apache、FPM）有效；CLI 下需额外加ini_set('display_errors', '1') - 如果用 Nginx + PHP-FPM，改的是
php.ini或www.conf中的php_admin_flag[display_errors] = on，不能靠 .htaccess - 某些托管环境会强制关闭
display_errors，此时只能靠log_errors = On配合error_log查看
Tracy Debugger 的 Debugger::enable() 为什么没反应
Tracy 不是装上就能用，Debugger::enable() 必须在任何输出（包括空格、BOM、echo）之前调用，否则会因 headers already sent 报错或静默失效。
实操建议：
- 确保
Debugger::enable()是整个请求生命周期中最早执行的 PHP 代码之一，推荐放在入口文件（如index.php）顶部第一行 - 检查是否重复启用：
Debugger::enable()多次调用不会报错，但第二次起无效；若已通过tracy/tracy的自动加载机制注册了Tracy\Bridges\Nette\Application等桥接器，则无需手动调用 - 确认
Tracy\Debugger类已正确加载 —— Composer 自动加载失败时，class not found错误本身也不会显示（因 Tracy 还没启动），得靠error_log或 CLIphp -l检查语法 - 浏览器端不显示调试栏？检查响应头是否有
X-Tracy-Ajax: 1，没有说明 Tracy 未注入 HTML；常见原因是用了输出缓冲但没调用Debugger::dispatch()，或模板引擎提前 flush 了内容
PHP 和 Tracy 共同作用下的日志路径与权限问题
PHP 的 error_log 和 Tracy 的 Debugger::$logDirectory 默认都依赖写入权限，但路径解析逻辑不同：PHP 用绝对路径或相对于当前工作目录（getcwd()），Tracy 默认用 sys_get_temp_dir()，而实际项目中常显式指定为 __DIR__ . '/log' —— 这里容易出错。
实操建议：
- 用
var_dump(ini_get('error_log'))和var_dump(Tracy\Debugger::$logDirectory)实时确认路径，别只看配置文件注释 - Linux 下注意运行用户（如
www-data或nginx）对日志目录是否有写权限，chmod 755 log不够，得是775并确保组一致 - Tracy 日志默认按天轮转，但若
$logDirectory不可写，它不会报错，而是退化为内存日志（页面刷新即丢），这点非常隐蔽 - 开发机和测试服务器时间不同步会导致 Tracy 日志文件名混乱（如生成
2024-09-30.log但系统时间是 10 月），排查时注意时区设置：date_default_timezone_set('Asia/Shanghai')要早于Debugger::enable()
禁用 Tracy 时如何保留 PHP 错误提示
上线前关掉 Tracy 很自然，但直接注释 Debugger::enable() 后，如果也没开 display_errors，错误就彻底隐身了 —— 这不是“更安全”，是“更难排查”。
实操建议：
- 生产环境应保持
display_errors = Off，但必须开启log_errors = On，并确保error_log指向可监控的集中日志（如/var/log/php/error.log） - Tracy 提供
Debugger::disable()，但它只是停用 UI 和异常捕获，不影响 PHP 原生错误机制；若你用的是Tracy\Logger，记得同时切换日志通道 - 别依赖
if (getenv('APP_ENV') === 'dev')这类条件包裹Debugger::enable()，环境变量可能未被正确加载（尤其 FPM 配置未透传时），建议用明确的配置文件或常量判断 - 一个硬核但有效的兜底方案：在入口文件末尾加
register_shutdown_function(function () { if (error_get_last()) error_log(print_r(error_get_last(), true)); });，它不依赖 Tracy，也不受display_errors影响
最常被忽略的其实是错误上下文的完整性 —— PHP 报错时的 $_SERVER['REQUEST_URI']、Tracy 的蓝屏里堆栈里的 include 链、以及日志里缺失的 POST 数据。这些不是配对开关就能解决的，得在每个环节确认数据是否真被采集、是否被截断、是否被过滤。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
