Symfony 2 的静态文件 404 不进入异常流程，根本原因是请求在到达内核前已被 Web 服务器拦截并响应；仅当路由显式代理静态资源或所有请求强制转发至内核时，才可能捕获相关 404。
Symfony 2 默认对静态文件（如 /css/app.css、/js/main.js）采用“先匹配静态资源，再交由内核处理”的策略。当请求的静态文件真实不存在时，Symfony 不会抛出异常，而是直接返回 HTTP 404 响应（通常由 Web 服务器如 Apache/Nginx 处理），因此无法被 kernel.exception 监听器或控制器层的 try/catch 捕获。
为什么静态文件 404 不进 Symfony 异常流程
根本原因在于：静态文件请求在到达 Symfony 内核前，已被 Web 服务器拦截并响应。即使你禁用了 Web 服务器的静态文件服务，Symfony 2 的默认逻辑也不会为缺失的静态资源抛出 PHP 异常 —— 它只在路由匹配失败且无静态资源可服务时，才进入内核并可能触发 NotFoundHttpException（但该异常仅针对路由路径，不覆盖 public/ 下的物理文件路径）。
真正能捕获的“静态相关 404”场景
只有以下两类请求可被 Symfony 2 的异常机制捕获：
-
路由定义的静态资源路径但无对应文件：例如你用
Route显式声明了@Route("/assets/{file}", name="asset_proxy")，并在控制器中尝试读取public/assets/{file}，此时file_exists()为 false，你可以主动 throwNotFoundHttpException -
Web 服务器未托管静态目录，所有请求都转发给
app_dev.php或app.php：这时缺失的/images/logo.png请求会进入 Symfony 内核，若无匹配路由，默认返回 404 页面（Whitelabel），但依然不抛异常；需手动在AppKernel::registerBundles()后或前端控制器中判断$_SERVER['REQUEST_URI']是否指向public/下路径，并检查文件是否存在，否则 throw
推荐做法：不依赖异常捕获，改用前置校验 + 统一响应
与其试图捕获静态文件 404 异常，不如在服务层或控制器中做显式判断：
- 对所有通过 Symfony 路由暴露的资源路径（如
/download/{filename}），在 action 中先调用is_file($path)和is_readable($path) - 若文件不存在，手动抛出
Symfony\Component\HttpKernel\Exception\NotFoundHttpException，它会被kernel.exception正常监听 - 若使用 Twig 输出静态链接，配合 Assetic 或自定义 Twig 函数预校验文件存在性（开发环境可用，生产慎用）
- 在 Web 服务器层配置 fallback（如 Nginx 的
try_files $uri @symfony），确保缺失静态文件仍走 Symfony，再由上述逻辑兜底
补充：日志记录缺失静态文件请求
若目标是监控哪些静态文件被频繁 404，建议不走 PHP 层，而直接分析 Web 服务器 access log：
- Apache：
grep '" 404 "' /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -20 - Nginx：
grep '" 404 "' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -20 - 这类统计比在 PHP 中捕获更准确、低开销，也避免干扰正常异常处理链路
