Session在ASP.NET中默认启用但易误用，需注意null检查、序列化、超时配置、Abandon与Clear区别及负载均衡下的丢失问题。
Session 在 C# ASP.NET Web Forms 或传统 ASP.NET MVC 中不是“可选功能”，而是默认启用的会话状态机制；但它的行为、存储位置、生命周期和线程安全性都容易被误用，直接导致空引用异常、数据丢失或服务器资源耗尽。
Session["key"] 为什么经常报 NullReferenceException
根本原因不是 Session 本身为空，而是读取时没做 null 检查 + 类型转换失败。Session 返回的是 object，强制调用 .ToString() 或直接转型会崩在运行时。
- 错误写法：
string name = Session["UserName"].ToString();—— Session["UserName"] 是null时立刻抛异常 - 正确写法：先判空，再安全转换：
string name = Session["UserName"] as string;或string name = Session["UserName"]?.ToString();（C# 6+） - 对数值类型更危险：
int id = (int)Session["Id"];会因 null 或类型不匹配直接炸；应改用int.TryParse(Session["Id"]?.ToString(), out int id) - 自定义类必须可序列化：存入
MyUser前需加[Serializable]特性，否则在 InProc 模式下可能不报错，但换到 StateServer 或 SQLServer 模式就彻底失效
Session.Timeout 和 web.config 的 sessionState 节点怎么协同生效
Session.Timeout 设置的是分钟数，但它只在 sessionState mode="InProc"（默认）下起作用；一旦改成 StateServer 或 SQLServer，实际超时由对应服务的配置决定，Timeout 只是客户端 cookie 的过期提示。
-
web.config中必须显式配置：<sessionstate mode="InProc" timeout="30"></sessionstate>
否则即使代码里设了Session.Timeout = 30，也可能被 IIS 默认的 20 分钟覆盖 - mode="StateServer" 时，要确保
ASP.NET State ServiceWindows 服务已启动，且stateConnectionString地址正确（如tcpip=127.0.0.1:42424） - mode="SQLServer" 需提前运行
aspnet_regsql.exe -S server -U user -P pwd -ssadd -d database初始化库表，否则首次写 Session 就卡住 - 修改
timeout后必须重启应用池，IIS 不会热加载 sessionState 配置
Session.Abandon() 和 Session.Clear() / Session.Remove() 的区别
三者语义完全不同，混用会导致“以为登出成功，其实 Session 还活着”这类线上问题。
-
Session.Abandon()：标记当前会话为“废弃”，触发Session_End（仅 InProc 模式），下个请求开始才会真正销毁；它不会立即清空字典，只是设了个内部标志 -
Session.Clear()：清空所有键值对，但 Session ID 不变，会话依然活跃，后续请求还能继续用这个 Session -
Session.Remove("key")或Session["key"] = null：只删单个项；注意后者只是把值设为 null，key 仍存在，Session.Count不变 - 真正安全退出：先
Session.Clear()清数据，再Session.Abandon()废弃会话，最后重定向到登录页（防止后退刷新重放旧 Session）
为什么本地调试正常，上线后 Session 频繁丢失
90% 是负载均衡或部署模式导致的 Session ID 不一致，不是代码 bug。
- 多台服务器部署时，若没启用粘性会话（sticky session）或共享 Session 存储（StateServer/SQLServer），用户第二次请求落到另一台机器，
Session["xxx"]必然为 null - IIS 应用程序池“空闲超时”设得太短（如默认 20 分钟），池被回收后所有 InProc Session 全丢，且不触发
Session_End - 前端用了反向代理（如 Nginx），没透传
ASP.NET_SessionIdcookie，或设置了secure/httpOnly但 HTTPS 配置不全，导致浏览器不发 cookie - 检查响应头：用浏览器 DevTools 看
Set-Cookie是否带Path=/且 Domain 匹配；如果页面路径是/admin/xxx但 cookie path 是/manage，Session 就送不到服务器
Session 不是万能的用户状态容器，高频读写、大对象存储、跨域共享、无状态部署场景下，它反而成为性能瓶颈和故障源头。真要持久化用户上下文，优先考虑 JWT + Redis 缓存组合，而不是堆 Session。
