web.xml 的 mime-mapping 在 tomcat 10+、jetty 11+ 等新容器中默认不生效，因 servlet 4.0+ 已弃用该配置，改由内置 mime 表驱动；spring boot 内嵌容器默认禁用 web.xml 解析，且 jakarta 命名空间下可能被忽略。
web.xml 里 mime-mapping 不生效？先看容器是否还认这个配置
Tomcat 10+、Jetty 11+、WildFly 27+ 等新版本默认已弃用 web.xml 中的 mime-mapping，改由 Servlet 规范 4.0+ 的内置 MIME 映射表驱动。你配了但浏览器仍返回 application/octet-stream，大概率不是写错了，而是容器压根不读这一段。
- Tomcat 9 及以下仍支持，但仅对未被内置映射覆盖的扩展名生效（比如
.xyz） - Spring Boot 内嵌 Tomcat 时，默认禁用
web.xml解析，除非显式启用ServletWebServerFactory.setRegisterJspServlet(true) - 若用
jakarta.servlet命名空间（非javax.servlet），mime-mapping标签在部分容器中会被忽略——XML Schema 不匹配
extension 写错大小写或带点？浏览器和服务器都可能拒认
extension 值必须严格匹配请求路径中的后缀，且**不带开头的点**。写成 .js 或 JS 都无效；有些容器（如旧版 WebLogic）对大小写敏感，jpg 和 JPG 被视为不同扩展名。
- 正确写法：
<extension>js</extension>，不是<extension>.js</extension></li> <li>常见翻车：前端请求 <code>/static/chart.min.mjs
，但只配了mjs，而某些容器要求完整匹配（min.mjs不算mjs） - 若需支持多级后缀（如
.tar.gz），标准mime-mapping无能为力，得靠 Filter 或 Servlet 动态设置response.setContentType()
content-type 值写错格式？空格、分号、charset 都可能触发 fallback
mime-type 的值必须是合法的 MIME 字符串，且不能含多余空格或非法字符。写成 text/css ; charset=utf-8 或 application/json;charset=UTF-8 都会导致解析失败，容器退回到默认类型。
- 合法值示例：
text/css、application/wasm、image/svg+xml - 非法值示例：
text/css;charset=utf-8（mime-type不接受参数，charset 应由响应头单独设） - 注意 XML 实体：若要写
application/xhtml+xml，直接写即可，不用转义或 <code>>
静态资源走不到 web.xml？检查路径是否被 Spring MVC 或其他 Servlet 拦截
即使 mime-mapping 配得完全正确，如果请求被 DispatcherServlet 拦截（如 <url-pattern>/</url-pattern>），而你又没配置 <resources></resources> 或 WebMvcConfigurer.addResourceHandlers()，那根本不会走到容器默认的静态资源处理链，mime-mapping 自然没机会生效。
- 验证方法：临时把
DispatcherServlet的url-pattern改成/api/*，再请求/static/test.js，看是否返回正确Content-Type - Spring Boot 用户更应优先用
spring.resources.chain.strategy.content.enabled=true+application.properties中的spring.web.resources.static-locations控制行为 - 纯 Servlet 容器（如 Tomcat standalone）下，确保文件放在
WEB-INF/classes同级的static/或根目录，而非WEB-INF/内部
真正麻烦的从来不是怎么配，而是你以为配完了，其实请求根本没走那条路——查日志里的 Request Processing Chain，比对着 web.xml 盯十分钟更有用。
