必须作为的直接子元素，且仅能出现一次；其中单位为分钟，正整数表示分钟数，0或负数表示永不过期；其配置为全局默认值，可被httpsession.setmaxinactiveinterval()（单位秒）单会话覆盖。
web.xml 里 <session-config></session-config> 的正确位置和嵌套关系
必须放在 <web-app></web-app> 根标签内部，且不能嵌套在 <servlet></servlet> 或 <Filter></filter> 里。常见错误是把它写在了 <welcome-file-list></welcome-file-list> 后面却忘了闭合，或者误塞进某个 servlet 块中，导致部署时报 ParseError 或静默失效。
-
<session-config></session-config>是<web-app></web-app>的直接子元素，建议紧贴在<display-name></display-name>或<description></description>之后 - 一个 web.xml 只能有一个
<session-config></session-config> - 如果用了 spring Boot 内嵌容器（如 tomcat），
web.xml可能根本不生效——此时应改用 java 配置或application.properties
<session-timeout></session-timeout> 的单位是分钟，不是秒也不是毫秒
这是最常踩的坑：写成 <session-timeout>1800</session-timeout> 本意是 30 分钟，结果变成 1800 分钟（30 小时），用户以为配置失败，其实是配太长了。
- 值必须是正整数，例如
30表示 30 分钟后 session 过期 - 值为
0或负数（如-1）表示“永不过期”，但实际取决于容器实现；Tomcat 会视作0并禁用超时检查 - 该设置影响所有 session，无法按路径或用户角色差异化
和代码中 httpsession.setMaxInactiveInterval() 的优先级关系
XML 配置是全局默认值，而代码调用 setMaxInactiveInterval() 是针对单个 session 实例的覆盖行为——后者优先级更高，且单位是秒。
- XML 设为
30（即 30 分钟），但某次登录后执行了session.setMaxInactiveInterval(60)，那这个 session 60 秒后就过期 - 反向不成立：代码设了 60 秒，重启后新 session 仍按 XML 的 30 分钟走
- 注意：Filter 或 Listener 中修改该值，需确保在 session 创建后、首次使用前完成，否则可能被容器忽略
不同 Servlet 容器对 <session-config></session-config> 的兼容性差异
Tomcat、jetty、WildFly 都支持，但部分老版本（如 Tomcat 6）不支持 <cookie-secure></cookie-secure> 或 <http-only></http-only> 子项；spring boot 2.5+ 默认不加载 web.xml，除非显式启用传统部署模式。
立即学习“Java免费学习笔记（深入）”；
- 若用
<cookie-secure>true</cookie-secure>，但应用跑在 HTTP（非 HTTPS）下，chrome 会直接丢弃 cookie，表现为“登了就掉” -
<http-only>true</http-only>能防 xss 读取 session ID，但某些旧 js 框架（如早期 jquery Cookie 插件）可能因此报错 - WebLogic 对
<session-timeout></session-timeout>解析更严格：不允许空格、注释混在标签内
实际生效要靠容器重启或重新部署，改完 web.xml 不重启等于没改。还有人把时间写成字符串比如 "30"，XML Schema 会校验失败，Tomcat 启动日志里藏一句 Invalid content was found starting with element 'session-timeout' —— 很难注意到。