最稳妥方式是在 kernel.request 事件中调用 $request->getPathInfo() 获取路径，避免使用 getUri() 等含查询参数或前缀的方法，并需在 kernel.terminate 中异步落库、按路由归一化路径以保障统计准确性和性能。
如何在 Symfony2 请求事件中获取当前访问路径
请求事件（如 kernel.request）触发时，$request 对象尚未完全绑定到控制器上下文，直接调用 $request->getPathInfo() 是最稳妥的方式。别用 $request->getUri() 或 $request->getRequestUri()，它们可能包含查询参数或非标准化前缀（比如反向代理加的路径前缀），干扰统计口径。
实操建议：
- 监听
kernel.request事件，优先使用RequestEvent（Symfony 4.4+）或GetResponseEvent（Symfony 2.x），避免在onKernelFinishRequest中取路径——此时响应已生成，但路径可能已被路由重写或跳转覆盖 - 若需排除静态资源（如
/css/app.css），应在获取getPathInfo()后手动过滤，例如：if (preg_match('/\.(?:js|css|png|jpg|gif|woff2?)$/i', $path)) { return; } - Symfony 2.8+ 中，
$event->getRequest()->getBasePath()可能为空，不要依赖它拼接完整路径；getPathInfo()已是相对于应用根的规范路径
自定义统计类必须实现的生命周期钩子
统计逻辑不能只靠单例或全局变量累加，必须绑定到请求-响应周期。Symfony 2 的事件驱动模型要求你在事件处理器里完成采集、聚合、落库三步，且不能阻塞主流程。
关键点：
- 统计类本身应无状态，所有数据通过
$event或服务容器注入的存储器（如stats_collector）传递；避免在类属性里存$count这种跨请求变量 - 不要在事件监听器里直接写文件或发 HTTP 请求——IO 操作必须异步或延迟到
kernel.terminate，否则拖慢响应 - 若用 Doctrine，别在
kernel.request中执行 DQL 查询；可先缓存路径、IP、时间戳到内存数组，再在kernel.terminate中批量插入
路径归一化：为什么 /user/123 和 /user/456 应算作同一接口
原始路径带 ID 或 UUID 会导致统计维度爆炸。不归一化，你看到的是几百个独立路径，而不是一个 /user/{id} 接口的调用量。
推荐做法：
- 利用 Symfony 的路由匹配结果：在
kernel.controller事件中获取$event->getRoute()（Symfony 2.8+）或从$event->getRequest()->attributes->get('_route')提取路由名，再查$router->getRouteCollection()->get($routeName)得到原始路径模板 - 若无法获取路由（如未匹配路由的 404 请求），退而求其次用正则粗略归一化：
preg_replace('/\/\d+/', '/{id}', $path)，但需注意避免误伤如/v2/api中的数字 - 别对查询参数做归一化（如
?page=1和?page=2视为同一路径），除非业务明确要求按分页维度统计
性能与并发：高频请求下统计丢失的真实原因
本地开发时一切正常，上线后发现统计数只有实际请求的 1/10 —— 大概率不是代码问题，而是 kernel.terminate 在 CLI 环境或某些 FastCGI 配置下根本不会触发。
排查方向：
- 确认 Web 服务器配置：Nginx + PHP-FPM 必须启用
fastcgi_finish_request，Apache mod_php 则天然支持kernel.terminate - 避免在统计类中使用
file_put_contents(..., FILE_APPEND)：高并发下会因文件锁丢数据；改用 Redis 的INCR或管道批量写入 - Symfony 2.3–2.7 版本存在
kernel.terminate不触发的已知 Bug（#11942），升级到 2.8 或打补丁
真正难处理的不是怎么写，是路径归一化规则要和路由定义严格对齐，还有 kernel.terminate 在不同部署环境的行为差异——这两处不验证，统计就只是看起来在跑。
