web.xml 中 error-page 不生效的主因是位置错误：必须作为 web-app 直接子元素且置于所有 servlet 和 servlet-mapping 之后；location 路径须以 / 开头、为上下文根下相对路径；捕获 500 异常需同时配置 error-code 和 exception-type（如 java.lang.RuntimeException）；Spring Boot 项目默认忽略 web.xml，应改用 @ControllerAdvice 或 ErrorController。
web.xml 里 error-page 不生效？先看位置和顺序
必须放在 web.xml 的 web-app 根元素内，且要**在所有 servlet 和 servlet-mapping 之后**。放错位置（比如插在 servlet 中间）会导致整个 error-page 被容器忽略，连带其他配置也可能失效。
常见错误现象：404 还是显示 Tomcat 默认页，500 报白板错误，但日志里没报 XML 解析异常——大概率是位置错了。
-
error-page必须是web-app的直接子元素，不能嵌套在servlet或filter里 - 多个
error-page可共存，但error-code和exception-type不能重复，否则后定义的会覆盖前一个 - Tomcat 9+ 对 XML 顺序更严格，老项目迁移时容易在这里翻车
404 页面配了却进不去？检查路径是否为容器内相对路径
location 值不是文件系统路径，也不是 URL 路径，而是**Web 应用上下文根（context root）下的相对路径**，且必须以 / 开头，指向 WebContent 或 src/main/webapp 下的资源。
例如应用部署为 /myapp，想用 /errors/404.html，那 location 就写 /errors/404.html，而不是 ./errors/404.html 或 /myapp/errors/404.html。
立即学习“Java免费学习笔记（深入）”；
- 路径不以
/开头 → 容器直接忽略该error-page，无提示 - 路径指向 JSP 时，确保该 JSP 没有抛出异常（比如 EL 表达式访问 null 对象），否则可能二次触发
500而非显示你配的页面 - 静态 HTML 最稳妥；若用 JSP，避免依赖未初始化的
request属性或 session 数据
500 错误页面捕获不到 RuntimeException？别漏掉 exception-type
仅靠 error-code 配置 500，只能捕获 HTTP 状态码为 500 的响应，**不会拦截未处理的 Java 异常**。要真正兜住 NullPointerException、IllegalArgumentException 这类，必须额外配 exception-type。
常见误区：以为配了 error-code 为 500 就万事大吉，结果空指针还是打白板。
- 推荐同时配置：
error-code捕获显式调用response.sendError(500)的场景；exception-type捕获未 catch 的运行时异常 -
exception-type值填完整类名，如java.lang.RuntimeException，不能写RuntimeException - 若想统一兜底所有异常，可写
java.lang.Throwable，但注意：部分容器对Throwable支持不一致，Tomcat 支持，Jetty 需确认版本
Spring Boot 项目里还写 web.xml？很可能根本没走它
Spring Boot 默认内嵌 Tomcat 并使用 Servlet 3.0+ 编程式配置，web.xml **完全被忽略**。此时配 error-page 是无效的。
真实生效的方式是：用 ErrorController 实现类，或配置 server.error.path + 静态资源 / 错误视图。
- 判断依据：启动日志里没有
Parsing web.xml相关输出，或者打断点发现web.xml根本没被加载 - Spring Boot 2.3+ 推荐用
@ControllerAdvice+@ExceptionHandler处理全局异常，比 XML 更灵活 - 如果硬要保留
web.xml（比如 WAR 部署到外部 Tomcat），需确认spring-boot-starter-tomcat是provided作用域，且打包方式为war
error-page 的匹配是静态的，不支持通配符或条件逻辑；一旦配置错误，失败表现非常安静——既不报错也不生效，这点最容易被忽略。 
