url-pattern只支持精确匹配、路径前缀匹配、扩展名匹配三种格式，不支持正则和双星号；filter-mapping顺序按web.xml中声明先后执行；/*拦截所有请求，/仅兜底未匹配请求；filter必须先定义后映射，名称严格区分大小写。
filter-mapping 中 url-pattern 写法决定拦截范围
写错 url-pattern 是最常见问题，它不支持正则，只认三种格式：精确匹配、路径前缀匹配、扩展名匹配。写成 /api/* 和 /api/** 看似差不多，但后者根本无效——Servlet 规范根本不识别双星号。
-
/user：只拦GET /user，不拦/user/或/user/info -
/user/*：拦/user、/user/、/user/info、/user/abc/def，但不拦/users -
*.do：只拦以.do结尾的请求，如/login.do，注意前面不能加路径
多个 filter-mapping 共存时顺序由 web.xml 中声明顺序决定
Filter 链执行顺序不是按 URL 匹配程度，也不是按字母序，就是 XML 里 filter-mapping 出现的先后顺序。比如你先声明了全局 /* 的日志 Filter，再声明 /admin/* 的权限 Filter，那所有请求都会先过日志 Filter，再进权限 Filter（如果匹配）。
- 同一个
filter可以有多个filter-mapping，各自独立生效 - 不同
filter的映射若重叠（比如都配了/api/*），谁在前谁先执行 - 别指望容器自动合并或去重——它就按 XML 行序排链
/* 和 / 区别很大，选错会导致静态资源被意外拦截
/* 是“容器级”通配，会拦所有请求，包括 /css/app.css、/images/logo.png；而 / 是“默认 servlet 映射”，只拦那些没被其他 servlet 明确处理的请求。多数项目用 /* 做统一入口（如 Spring MVC 的 DispatcherServlet），但随之而来的问题是：Filter 也会对静态资源生效。
- 如果用了
/*，又没在 Filter 里手动放行.js/.css等路径，浏览器可能拿不到样式或脚本 -
/不会触发 Filter（除非你显式配置了对应 mapping），更适合做兜底，但无法覆盖/api/*这类子路径 - Spring Boot 默认不用 web.xml，但老项目迁移时容易把
/*当万能解，结果发现图片打不开才回头查
web.xml 中 filter-mapping 必须紧接在 filter 定义之后才有效
XML 解析是线性的，filter-mapping 必须引用一个已声明的 filter-name，且该 filter 标签必须出现在它之前。常见错误是把所有 filter 放底部，上面一堆 filter-mapping，结果部署时报错：java.lang.IllegalArgumentException: Filter not found。
- 检查顺序：先
<filter><filter-name>AuthFilter</filter-name>...</filter>，再<filter-mapping><filter-name>AuthFilter</filter-name>...</filter-mapping> - 名字要完全一致，大小写敏感，多一个空格都不行
- IDE 可能不报错，但 Tomcat 启动时会直接拒绝部署，日志里就一句找不到 Filter
事情说清了就结束。真正麻烦的是混合使用注解配置和 web.xml——两者共存时规则叠加逻辑模糊，出问题很难定位。
