load-on-startup值决定Servlet初始化时机:非负数启动时加载,数值越小越先初始化;负数或不写则首次请求加载;相同值顺序不保证。

web.xml 中 load-on-startup 的值到底填几?
这个数字不是随便写的,它控制 Servlet 初始化顺序。值为 0 或正整数时,容器启动时加载;负数或不写,则首次请求才加载。多个 Servlet 都设了正数,数值越小越先初始化——但注意:相同数值的 Servlet 加载顺序不保证。
- 如果依赖其他 Servlet(比如过滤器要等某个工具类 Servlet 先就位),必须明确设更小的
load-on-startup值 - Spring 的
ContextLoaderServlet旧版习惯设1,而自定义 Servlet 设2,但现在基本被ContextLoaderListener取代,后者不走此机制 - 值设太大(如
100)没意义,反而可能掩盖依赖混乱问题
filter-mapping 和 servlet-mapping 的 url-pattern 写法差异
url-pattern 看似一样,但 filter 和 servlet 对通配符的解释逻辑不同,尤其在路径匹配优先级上容易出错。
- Filter 的
url-pattern支持三种写法:/api/(前缀匹配)、.do(扩展名匹配)、/login(精确匹配),但不支持/*和/混用导致意外拦截静态资源 - Servlet 的
url-pattern同样支持这三种,但容器按“精确 > 前缀 > 扩展名”排序匹配;而 Filter 是按filter-mapping在 web.xml 中的出现顺序执行,跟 pattern 类型无关 - 常见坑:
会拦截所有请求(包括 /favicon.ico、/css/app.css),不是只拦根路径/
web.xml 里配置 Spring ContextLoaderListener 还需要配 context-param 吗?
必须配,而且 context-param 的名字和值不能错。否则 ContextLoaderListener 启动时找不到配置文件,抛 FileNotFoundException 或静默失败。
- 关键参数是
contextConfigLocation,不是configLocation或context-location - 值默认是
/WEB-INF/applicationContext.xml,如果放别处(比如classpath:spring-root.xml),就得显式写:<context-param><param-name>contextConfigLocation</param-name><param-value>classpath:spring-root.xml</param-value></context-param>
- 多个配置文件用逗号分隔:
classpath:spring-db.xml, classpath:spring-service.xml,注意空格会被当成路径一部分,导致加载失败
web.xml 中的 session-config timeout 单位是分钟,但实际生效受多层影响
session-timeout 设的是分钟,但真正 session 失效时间还取决于容器实现、是否启用持久化、有没有调用 session.invalidate()。
- Tomcat 默认 30 分钟,设
表示 60 分钟无操作后过期60 - 注意:这个 timeout 是从最后访问时间开始算,不是创建时间;每次请求(哪怕只是 GET /favicon.ico)都会刷新
- 容器可能有最小限制(如 WebLogic 强制不低于 5 分钟),且若代码中调用
session.setMaxInactiveInterval(60)(单位秒),会覆盖 web.xml 设置 - 开发时容易忽略:本地调试改了
session-timeout,但浏览器已有旧 session cookie,得清 cookie 或开隐身窗口验证
web.xml 的配置项看似静态,但每个 tag 都卡在容器启动流程的关键节点上;改一行,可能让 Filter 漏掉请求,也可能让 Spring 上下文根本没加载——盯住日志里那几行 “Initializing Spring root WebApplicationContext” 和 “Starting Servlet engine” 就知道哪步没走对。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











