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/<em></em>（前缀匹配）、.do（扩展名匹配）、/login（精确匹配），但不支持/*和/混用导致意外拦截静态资源 - Servlet 的
url-pattern同样支持这三种，但容器按“精确 > 前缀 > 扩展名”排序匹配；而 Filter 是按filter-mapping在 web.xml 中的出现顺序执行，跟 pattern 类型无关 - 常见坑：
<filter-mapping><url-pattern>/</url-pattern></filter-mapping>会拦截所有请求（包括 /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()。
立即学习“Java免费学习笔记（深入）”；
- Tomcat 默认 30 分钟，设
<session-timeout>60</session-timeout>表示 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” 就知道哪步没走对。
