日志文件实际路径需运行php bin/console debug:container --parameter=kernel.logs_dir确认，若返回null则Monolog未加载；dev.log中通过时间戳、路由名、用户标识交叉定位请求；POST数据和请求头需手动注入$request记录，禁用生产环境；PHP Notice是否记录取决于error_reporting和monolog.php通道配置。
日志文件在哪？先确认 kernel.logs_dir 实际路径
别猜 var/log，Symfony 的日志目录可能被重定义。运行 php bin/console debug:container --parameter=kernel.logs_dir，输出结果才是真实路径。如果返回 null，说明 Monolog 服务根本没加载成功，后续所有日志操作都无效。
常见干扰项：
-
.env.local里误写LOGS_DIR=—— Symfony 不认这个变量，它只认kernel.logs_dir参数或容器配置 - 自定义
Kernel类中覆盖了getLogDir()但返回空字符串或不存在的路径 - 多环境部署时，
APP_ENV=staging却没配对应日志通道，导致日志写进 dev.log 或直接丢弃
dev.log 里怎么快速定位某次请求？看这三列字段
Symfony 默认日志格式含时间戳、通道名（如 request、doctrine）、优先级（DEBUG/INFO），但关键线索藏在消息体里：
- 每条
request.INFO日志开头都有类似[2026-08-13T21:22:45.123456+00:00] request.INFO: Matched route "app_user_profile"—— 这是路由匹配结果，能反推访问路径 - 紧随其后的
security.DEBUG行会带user="xxx"或user="anon."，区分是否登录态 - 若启用
debug模式且没禁用 profiler，request.INFO行末尾会出现profile="xxx"，这个 hash 值可直接拼到/_profiler/xxx查完整请求上下文
别依赖 grep 路径字符串：比如搜 /api/users 可能漏掉带 query 参数的请求。更稳的方式是先用 tail -f var/log/dev.log 刷新页面，看哪几行是连续出现的，它们属于同一次请求生命周期。
为什么 dev.log 里看不到 POST 数据或请求头？
Symfony 默认不记录原始请求体和 headers，这是出于安全与性能考虑。想看到这些，必须手动加日志点：
- 在控制器里注入
$request，用$logger->debug('Request headers', ['headers' => $request->headers->all()]) - 对 POST 数据，用
$request->request->all()（表单）或json_decode($request->getContent(), true)（JSON）再传入日志上下文 - 注意不要在生产环境开启——
$request->getContent()可能读取大文件导致内存暴涨，且敏感字段（密码、token）会明文落盘
更轻量的办法：用 dump($request) 配合 WebProfiler，它只存在内存里，不会写日志文件，适合临时验证。
日志里出现大量 PHP Notice 却没报错？检查 error_reporting 是否被覆盖
Symfony 日志中的 PHP Notice 来自 PHP 自身错误处理器，不是 Monolog 记的。如果发现这类日志频繁但没触发异常，大概率是：
-
php.ini中error_reporting设为E_ALL，但项目里某处执行了error_reporting(E_ALL & ~E_NOTICE) - 某些第三方 bundle（如 old Doctrine DBAL 版本）在初始化时静默压制了 notice 级别错误
-
monolog配置里把php通道的 level 设成了warning，导致 notice 被过滤掉，只在php://stderr输出
验证方式：在控制器里写 trigger_error('test notice', E_USER_NOTICE)，看它是否出现在 dev.log。不出现，就说明 PHP 错误未被 Monolog 捕获，得查 monolog.handler.php 配置或 registerErrorHandler 调用链。
