$request->getUri() 获取完整请求URI（含scheme、host、path、query），配合 $request->getMethod() 记录HTTP方法，是定位POST提交来源最直接方式；应在kernel.request事件或控制器开头记录，而非仅校验失败后，同时用 $request->request->all() 保留原始表单数据并过滤敏感字段。
$request->getUri() 或 $request->getRequestUri() 是定位 POST 提交路径最直接的方式，日志里不打这个，就等于没留线索。
怎么在日志里记录表单提交的原始路径和方法
很多人只记 $request->getPathInfo()，结果所有 POST 都变成 /submit，根本分不清是哪个页面提交的。真正有用的路径是带 query string 的完整 URI，比如 /product/123/edit?ref=dashboard。
- 用
$request->getUri()获取完整请求地址（含 scheme、host、path、query） - 搭配
$request->getMethod()明确是 POST 还是 PUT - 别依赖
$request->attributes->get('_route')——路由匹配可能失败或被覆盖，此时为空 - 在控制器开头或事件监听器（如
kernel.request）中写入日志，避免验证失败后流程中断导致漏记
为什么表单校验失败时看不到提交来源
常见错误是只在 $form->isValid() === false 时记录错误，但这时 $request 已经走完绑定逻辑，$_POST 数据被清理或转换，原始字段名和值可能失真。比如嵌套字段 user[profile][email] 经过表单映射后变成 profile.email，日志对不上前端。
- 校验前就记录
$request->request->all()（注意不是$_POST，它可能被修改过） - 对敏感字段（如密码、token）做白名单过滤，避免日志泄露：
array_diff_key($data, ['password' => '', 'csrf_token' => '']) - 用
json_encode($data, JSON_UNESCAPED_UNICODE)保证中文不乱码，且结构清晰可读
POST 请求没进控制器？先查是否卡在 CSRF 或内容类型校验
很多“表单没提交”实际是请求压根没到你的 action，死在中间件或表单组件内部。典型表现：日志里完全没对应记录，或只看到 400/415 错误。
- 检查响应头
Content-Type: application/x-www-form-urlencoded是否缺失或错写成text/plain - CSRF 失败不会进控制器，而是由
FormListener直接返回 400，日志里会输出"The CSRF token is invalid." - 若用 AJAX 提交 JSON，
$form->handleRequest($request)不生效——它只处理application/x-www-form-urlencoded和multipart/form-data，必须改用$form->submit($data) - 开启 Symfony 的 debug 日志级别（
monolog.level: debug），看request.INFO和security.DEBUG通道有没有拦截记录
真正难排查的从来不是验证逻辑本身，而是你根本不知道请求到底走到哪一步了。路径、方法、原始数据、中间件拦截点——这四样不同时出现在日志里，就等于盲人摸象。
