应过滤静态资源路径（如/favicon.ico、/css/）和子请求，仅记录白名单业务路由，统一模板化带参路径，并将高频访问统计改用redis或前端埋点实现。
重复访问路径怎么被日志误判为“多次请求”
不是用户真点了十次，而是前端资源（JS/CSS/图片）或浏览器预加载触发了额外请求，被 monolog 或 Profiler 一并计入。尤其在开发环境开启 debug 模式时，app_dev.php 自身的重定向、Twig 模板中 asset() 生成的绝对 URL、甚至浏览器自动发起的 favicon.ico 请求，都会出现在日志里，干扰对真实业务路径的统计。
- 检查日志中是否大量出现
/favicon.ico、/bundles/、/css/等静态资源路径——这些应过滤，不参与“业务路径重复访问”分析 - 确认是否启用了
profiler的 full-page profiling：它会为每个子请求（如嵌入的 controller action）单独记录一次，造成路径重复假象 - 用
$_SERVER['REQUEST_METHOD'] === 'GET'+strpos($_SERVER['REQUEST_URI'], '.') === false粗筛非资源请求，但更稳妥的是在日志通道里加路由匹配规则
如何让日志只记录有意义的业务路径
靠改 monolog.yaml 的 channels 和 handlers 不够，得在写日志前做语义过滤。核心是把“路径去重”逻辑前置到记录动作发生前，而不是事后从日志文件里 grep。
- 在自定义日志处理器（如继承
Monolog\Handler\AbstractProcessingHandler）中，用$record['context']['route'] ?? null提取当前路由名，再查白名单数组（如['app_homepage', 'app_product_list', 'app_checkout_submit']），不在其中的直接return不写入 - 避免在控制器里手动
$logger->info('访问 /product')——这样路径是硬编码字符串，无法关联路由参数；改用$logger->info('访问产品列表页', ['route' => $request->attributes->get('_route')]) - 对含参数的路径（如
/product/{id}），统一记录为模板形式：/product/{id}而非/product/123，否则/product/123和/product/456会被当成两个路径
接口请求逻辑优化：别让一个 API 调用触发 N 次日志写入
常见错误是把日志埋点放在 Repository 查询循环里，或者在 Form 处理中对每个字段校验都 $logger->debug()。结果一个 POST /api/order 请求，在日志里留下 20+ 行，根本看不出主干流程。
- 日志粒度要和调用栈层级对齐：控制器层记“收到订单创建请求”，Service 层记“库存校验通过”，Repository 层只在异常时记“DB 查询超时”，正常路径不记
- 禁用 Doctrine 的
sql_logger在生产环境输出完整 SQL——它每条查询都打一行，且参数被转义后难以识别业务含义；改用doctrine.dbal.logging: false关闭，仅靠 Profiler 抓慢查询 - 如果必须记录接口耗时，用
stopwatch组件：在 Controller 开头$stopwatch->start('api_order_create')，结尾$event->setResponse($response->withHeader('X-Response-Time', $stopwatch->stop('api_order_create')->getDuration()))，把时间指标带出，而非塞进日志行
重复路径统计真正该看什么数据源
日志文件本身不适合做高频路径聚合分析。它顺序写入、无索引、文本解析慢。当你要回答“首页昨天被访问多少次、哪些时段集中”时，var/log/dev.log 是最差选择。
- 把关键路径访问事件推到 Redis：用
$redis->incr("path:homepage:date:" . date('Y-m-d'))，原子计数，支持按天/小时聚合，且不阻塞主流程 - 前端埋点 + 后端接收接口（如
POST /log/path）比服务端日志更准——它能排除爬虫、预加载、缓存命中等干扰，且可携带设备类型、用户登录态等上下文 - 若坚持用日志，导出后用
awk '{print $9}' access.log | sort | uniq -c | sort -nr | head -20（注意：这是 Apache/Nginx 访问日志，不是 Symfony 日志）——Symfony 自己的日志没标准格式，硬解析极易出错
