web.xml中session-timeout单位是分钟，设30表示30分钟；常见错误是误以为单位为秒，或被代码中setMaxInactiveInterval（单位秒）覆盖，Spring Boot中则由server.servlet.session.timeout控制且单位为秒。
web.xml 中 session-timeout 的单位是分钟，不是秒
很多人在改 session-timeout 时发现设成 30 没效果，或者超时快得离谱，根源就是误以为单位是秒。它只接受整数，单位固定为**分钟**，且最小有效值是 1（即 60 秒），设成 0 或负数会被容器当作“永不过期”处理（但不推荐依赖此行为）。
常见错误现象：
- 设
<session-timeout>1800</session-timeout>，以为是 30 分钟，实际是 1800 分钟（30 小时） - 设
<session-timeout>30</session-timeout>却发现 30 秒就失效——其实是代码里调用了session.setMaxInactiveInterval(30)，覆盖了 web.xml 配置
Tomcat 下 session-timeout 生效的前提条件
这个配置只对通过 Servlet 容器创建的 HTTP Session 起作用，且必须满足以下条件：
- 应用部署在支持 Servlet 规范的容器中（如 Tomcat、Jetty），且未被程序主动干预
-
web.xml的根元素声明了至少 Servlet 3.0+ 的 schema（否则部分旧版本可能忽略该配置） - 没有在代码中调用
session.setMaxInactiveInterval(...)—— 这个 API 优先级更高，会直接覆盖 web.xml 设置 - 没有在
context.xml或 Tomcat 全局conf/web.xml中设置更宽泛的默认值，导致应用级配置被继承覆盖
和 setMaxInactiveInterval() 的关系与冲突点
Java Servlet API 提供的 session.setMaxInactiveInterval(int seconds) 是运行时控制手段，单位是**秒**，和 web.xml 的分钟单位完全相反，这是最容易混淆的地方。
使用场景差异：
- 全局、静态策略（如所有用户默认 20 分钟无操作过期）→ 用
web.xml的session-timeout - 动态策略（如 VIP 用户延长到 60 分钟、登录后重置倒计时）→ 必须用
session.setMaxInactiveInterval(3600) - 两者共存时，后者生效，且影响的是当前 session 实例，不会改变其他 session 或配置文件语义
性能提示：频繁调用 setMaxInactiveInterval() 不会影响性能，但每次调用都会重置该 session 的最后访问时间戳。
Spring Boot 项目里还管 web.xml 吗？
基本不管。Spring Boot 默认不启用 web.xml，Session 超时由 server.servlet.session.timeout 控制，单位是**秒**——注意，这里又变回秒了。
如果你在 Spring Boot 中手动启用了传统部署方式（比如继承 SpringBootServletInitializer 并打 war 包），那么：
- Tomcat 启动时仍会读取
web.xml，但 Spring Boot 的配置项（如server.servlet.session.timeout=1200）会优先生效 -
web.xml中的session-timeout只有在没有任何 Spring Boot 相关 session 配置时才兜底生效 - 推荐统一使用
application.properties管理，避免双配置源引发的预期外行为
真正容易被忽略的是：不同环境（dev/test/prod）下，server.servlet.session.timeout 值是否一致；以及反向代理（如 Nginx）是否设置了 proxy_read_timeout，它可能比应用层 session 更早切断连接。
