在 Symfony 2 中让监听器只在 prod 环境统计路由访问，最可靠方式是在服务注册时通过 condition 表达式过滤：“service('kernel').getEnvironment() == 'prod'”，确保非生产环境不加载监听器，避免运行时判断带来的性能损耗和误统计风险。
如何在 Symfony 2 中让监听器只在 prod 环境统计路由访问
直接结论：用 $kernel->getEnvironment() 判断环境，再结合事件订阅器的条件注册或内部逻辑跳过，是最轻量、最可控的方式。硬编码 if ('prod' !== $this->environment) 在监听器里反而容易漏掉 CLI 请求或测试场景的干扰。
监听器注册时就过滤掉非生产环境
别等事件触发了再判断——那样每次请求都多一次环境检查，还可能意外记录 dev 下的调试请求。推荐在服务定义里用参数控制是否启用该监听器：
- 在
services.yml（或services.php）中，把监听器声明为条件服务：app.route_stats_listener: class: App\EventListener\RouteStatsListener tags: - { name: kernel.event_listener, event: kernel.request, method: onKernelRequest } arguments: ['%kernel.environment%'] public: false # 只在 prod 下加载 condition: "service('kernel').getEnvironment() == 'prod'" - 如果用的是 Symfony 2.8+，
condition支持表达式；低于此版本可改用参数占位符 + 容器扩展类动态注册 - 这样 dev/test 环境压根不实例化监听器，无性能损耗，也杜绝配置错误导致的误统计
监听器内部做环境判断的常见错误
很多人写成：if ('prod' !== $this->environment) { return; }，看似没问题，但实际踩坑点不少：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
$this->environment若从构造注入而来，必须确保它来自%kernel.environment%参数，而不是硬编码字符串或从$_SERVER读取——后者在 CLI 或某些部署方式下可能不准 - 没考虑子请求（sub-request）：比如嵌入的
render()调用也会触发kernel.request，但这类请求不该计入主路由访问统计。应加if (!$event->isMasterRequest()) { return; } - 忽略异常流程：当控制器抛出异常未被捕获，
kernel.terminate可能仍执行，但此时路由统计若已写入数据库或 Redis，就会产生脏数据。建议把统计逻辑放在kernel.response阶段，并检查$event->getResponse()->getStatusCode() === 200
统计数据写入时的环境隔离问题
即使监听器只在 prod 运行，写入目标（如 Redis key、数据库表、日志文件路径）若没做环境前缀，开发人员查日志或运维清缓存时极易混淆：
- Redis key 示例：
route:stats:prod:homepage，别用route:stats:homepage——否则本地跑一次cache:clear就可能清掉线上数据 - 数据库表名或字段值中显式带上环境标识，比如插入时写
environment = 'prod'，避免后续分析时无法区分数据来源 - 日志通道（channel）也建议分离：用
monolog.channel: route_stats并单独配 handler，防止和app主通道日志混在一起，影响tail -f实时排查
真正麻烦的不是“怎么只在 prod 运行”，而是“怎么确保 prod 的行为不会被其他环境残留配置、共享存储或开发者本地操作意外污染”。环境判断只是第一道门，后续每层（注册、触发、写入）都要有明确的隔离意识。
