调试模式必须在Kernel构造时通过APP_DEBUG=true环境变量启用，kernel.debug参数决定DebugBundle加载、错误处理器注册等全部调试能力，后续配置无效。
调试模式必须在 Kernel 构造时就启用，靠改配置或运行时开关基本无效。
kernel.debug 参数决定一切
Symfony 的调试能力不是“插件式开启”，而是由 kernel.debug 这个容器参数在 AppKernel（或 Kernel）实例化阶段就锁死的。它直接影响 DebugBundle 是否加载、错误处理器是否注册、WebProfiler 是否注入——后续任何配置覆盖都晚了。
- 正确做法：在
public/index.php（或旧版web/app_dev.php）中确保传入debug => true：new Kernel($_SERVER['APP_ENV'], $_SERVER['APP_DEBUG'] === 'true')
，且环境变量APP_DEBUG=true已设置 - 常见错误：只在
config/packages/dev/debug.yaml里写debug: true——这没用，该文件加载太晚，DebugBundle 早已跳过初始化逻辑 - 验证方式：dump(
$container->getParameter('kernel.debug')) 在任意服务中执行，必须返回true才算真正生效
WebProfiler 工具栏不显示？先查三件事
工具栏（WDT）是调试模式的最直观反馈，但它依赖三个硬性条件同时满足，缺一不可：
-
kernel.debug为true（如上所述） - 当前请求走的是 dev 环境路由（即 URL 匹配
dev前缀或通过APP_ENV=dev启动） - 响应头中包含
X-Debug-Token，且 HTML 响应末尾成功注入了toolbar.js脚本 —— 如果用了 Twig 缓存、CDN、或输出被 ob_* 函数截断，脚本就丢了
典型现象：dump() 输出出现在页面顶部但工具栏空白 → 很可能是模板未渲染到底部，或 base.html.twig 漏了 {{ render_profiler() }}（新版 Symfony 默认已内置，但自定义布局可能删掉了）。
dump() 不显示在工具栏？检查 VarDumper 配置
dump() 是 DebugBundle 提供的快捷函数，但它的输出目标不是页面 HTML，而是 WebProfiler 的 “Dump” 标签页 —— 前提是 symfony/var-dumper 组件正常工作且未被禁用。
- 确保已安装：
composer require --dev symfony/var-dumper - 检查
config/packages/dev/web_profiler.yaml中是否保留了：web_profiler: toolbar: true intercept_redirects: false - 如果在 CLI 环境（如命令行）调用
dump()，它会直接输出到终端，而非 WDT —— 这是设计行为，不是 bug - 敏感数据过滤：默认
VarDumper会隐藏$_ENV、$_SERVER等全局变量中的敏感键，若发现某些变量“突然消失”，不是没 dump，而是被ServerDumpDataCollector主动脱敏了
别在生产环境偷偷开 debug=true
很多人想“只开 dump() 或只开 profiler”，但 kernel.debug=true 会强制启用全套调试链路：错误转异常、全量日志、服务定义暴露、模板编译跳过缓存……这些在生产环境等于主动打开攻击面。
- 错误示例：用
profiler.matcher配置仅对 admin 用户启用 profiler —— 它仍要求kernel.debug=true，所以整个应用已处于调试态 - 替代方案：如真需生产环境诊断，用
monolog+log_level: debug控制日志粒度，或临时启用server:dump命令（php bin/console server:dump），它不依赖 WDT 也不影响运行时状态 - 一个容易忽略的点：
APP_DEBUG=1和APP_DEBUG=true在某些 shell 环境下解析结果不同，推荐统一用字符串"true"避免布尔转换歧义
真正麻烦的从来不是怎么开，而是开了之后哪些组件会连锁响应、哪些缓存自动失效、哪些安全策略悄然绕过——这些隐性代价，往往要等压测或上线后才浮现。
