symfony profiler默认仅在dev环境启用，需app_env=dev且app_debug=true，通过web debug toolbar或/_profiler/{token}访问；生产环境禁用以防性能损耗和敏感信息泄露。
直接用 Symfony2 自带的 Web Profiler（_profiler）就能看所有路径访问数据，不需要额外开发查询页面——但前提是环境配对、路由可访问、且日志通道没被阉割。
确认 Web Profiler 是否启用且可访问
Profiler 默认只在 dev 环境生效，且要求 APP_DEBUG=1。访问任意页面后，在右下角看到“Web Debug Toolbar”小图标，点开 → “Profiler” → 就能进全量请求列表页（/_profiler?limit=10）。如果点不开或 404，检查以下三点：
-
config/packages/dev/web_profiler.yaml文件存在且未被注释或删除 -
APP_ENV=dev和APP_DEBUG=1真正生效（运行php bin/console about查 Environment 和 Debug 值） - 路由未被安全策略拦截：确保
security.yaml中 profiler 路由放行，例如：pattern: ^/_profiler在access_control里设为IS_AUTHENTICATED_ANONYMOUSLY
查路径访问数据：关键字段和筛选逻辑
进入 /_profiler 后，默认按时间倒序列出最近 10 次请求。每条记录含 Method、Path、Status、Time、Memory。想快速定位某类路径，别手动翻页——用顶部搜索框输入：
- 路径前缀：
^/api/（匹配所有 API 请求） - HTTP 方法：
method:POST - 状态码：
status:500或status:~4（匹配所有 4xx） - 组合条件：
path:^/admin/ method:GET status:200
注意：path: 后面不加引号，不写完整 URL，只写 path 部分（如 /user/profile），且支持 ^ 开头匹配前缀。
导出或持久化访问数据？别依赖 Profiler
Profiler 的数据默认存在 var/cache/dev/profiler/ 下的文件中，生命周期短（默认保留 1 天，受 framework.profiler.lifetime 控制），且不支持跨服务器聚合。真要长期分析路径访问，必须换方案：
- 用 Monolog 写结构化访问日志：在
config/packages/dev/monolog.yaml里加一个handlers，type 设为stream，path 指向%kernel.logs_dir%/access.log，再通过processors注入请求路径、方法、响应码 - 把访问日志接入 ELK 或 Grafana Loki：每行 JSON 格式，字段含
path、method、status、duration_ms，方便做 Top N 路径、慢请求告警 - 禁用 Profiler 的自动清理：设
framework.profiler.only_exceptions: false和framework.profiler.lifetime: 604800（7 天），但仅限本地调试，上线环境严禁开启
为什么不能在 prod 环境开 Profiler 查路径？
因为 Profiler 是调试工具，不是监控组件。它在每次请求末尾收集大量内存对象（如服务容器快照、SQL 查询堆栈、模板渲染树），prod 下开启会导致：
- 单次请求内存暴涨 2–5MB，高并发时直接 OOM
- 所有 SQL 查询被强制记录（即使你没开
doctrine.dbal.logging），拖慢 DBAL 层 - 缓存键污染：Profiler 数据混入 APCu/Redis 缓存池，影响业务缓存命中率
线上路径统计必须走轻量日志 + 外部分析，Profiler 只用于 dev 下定位单次请求瓶颈。
