应在 kernel.request 监听器中用 getPathInfo() 判断路径前缀（如 '/static/'、'/favicon.ico'）并提前 return，因该事件在路由匹配前触发，必须在监听器内防御性过滤，不可依赖路由配置排除。
怎么让 kernel.request 监听器跳过 static/、favicon.ico 等静态资源
监听 kernel.request 时，默认会捕获所有请求，包括 /static/css/app.css、/favicon.ico、/robots.txt 这类无需业务逻辑干预的静态路径。不做过滤，轻则浪费日志/监控配额，重则触发租户识别逻辑报错（比如从空 host 提取 tenant_id）。
最直接的办法是在监听器方法开头加路径判断：
public function onKernelRequest(RequestEvent $event): void
{
$request = $event->getRequest();
$path = $request->getPathInfo();
<pre class='brush:php;toolbar:false;'>if (str_starts_with($path, '/static/') || $path === '/favicon.ico' || $path === '/robots.txt') {
return;
}
// 后续业务逻辑...}
-
getPathInfo()比getRequestUri()更可靠——它不含 query string，也不受反向代理 rewrite 影响 - 别用
getRealMethod()或getMethod()做判断：GET/HEAD 都可能访问动态路由，而 OPTIONS 也可能打到 API 上 - 如果项目用 Nginx 直接托管
public/下的文件，这些请求根本不会进 PHP，也就不会触发监听器——但开发环境（symfony server）或某些 Apache 配置下仍会进来，必须防御性判断
为什么不能只靠路由配置 exclude 静态路径
Symfony 路由系统本身不提供“全局排除路径”的机制。你不能在 config/routes.yaml 里写一条规则说“所有以 /static/ 开头的请求都不走任何 controller”。即使你手动配了 fallback 路由，kernel.request 事件仍会在路由匹配前就已触发。
换句话说：kernel.request 是内核入口，路由匹配是后续步骤。过滤必须在监听器里做，而不是指望路由层帮你跳过。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 试图用
_controller: FrameworkBundle:Template:template处理静态 HTML？它仍是动态响应，kernel.request照样触发 - 用
assets:install生成的链接指向/build/app.css？只要没被 Web 服务器拦截，就会进监听器 - 某些前端构建工具（如 Vite）把资源放在
/@vite或/assets/下，这些路径名需一并加入过滤列表
如何安全地识别“真正静态”的请求
光看路径前缀不够严谨。有些场景下，同一路径可能是静态资源，也可能是动态接口（比如 /api/v1/status 和 /static/status.html 冲突）。更稳妥的方式是结合 MIME 类型预期 + 请求头特征：
if ($request->headers->has('X-Requested-With') && $request->headers->get('X-Requested-With') === 'XMLHttpRequest') {
// AJAX 请求，大概率是动态 API，不跳过
return;
}
<p>$mimeType = $request->getMimeType($request->getRequestFormat());
if (in_array($mimeType, ['text/css', 'image/png', 'application/javascript'], true)) {
return;
}-
getMimeType()依赖getRequestFormat()，而后者基于 path extension 或_formatquery 参数推断，对无后缀路径（如/api/users）无效 -
Accept请求头不可靠：浏览器发 CSS 请求时也带text/css,*/*，但 API 客户端可能也这么写 - 生产环境建议配合 Web 服务器配置：Nginx 的
location ~* \.(?:css|js|png|jpg|gif)$直接返回文件，彻底避免进 PHP
监听器里调用 $event->setResponse() 后还能否被其他监听器处理
不能。$event->setResponse() 会标记事件为“已处理”，后续所有 kernel.request 监听器都会被跳过。这对静态资源很实用——比如你想提前返回 404 或 302，就不该再让租户解析、语言设置等监听器执行。
但要注意副作用：
- 如果你在监听器里设置了 response，Symfony 就不会再执行路由匹配、控制器调用、模板渲染等后续流程
- 这意味着
kernel.controller、kernel.response等后续事件也不会触发——日志中间件、性能计时器若依赖这些事件，就会漏掉这部分请求 - 返回 404 时，别忘了设状态码：
$response->setStatusCode(404)，否则默认是 200
复杂点在于：你得决定哪些静态请求值得记录（比如 CDN 回源失败的 /static/xxx.js），哪些纯粹丢弃。路径过滤只是起点，真正的边界往往藏在部署拓扑和监控目标里。
