在ASP.NET开发中，Session对象承担着在服务器端为每个用户会话保存独立数据的职责。它可以记录用户编号、昵称、购物车内容等信息，这些数据只属于当前访问者，不会与其他用户混淆。由于数据存储在服务器端，Session比ViewState更适合在多个页面之间传递敏感信息，客户端无法直接查看或篡改核心数据。Session依赖Cookie或URL中的会话标识来区分不同访问者，即使页面跳转，服务器仍能识别同一用户。
Session的基本读写机制
在后台代码（例如aspx.cs文件中），可以直接使用Page对象的Session属性进行赋值和取值。Session本质上是一个键值集合，其中键通常使用字符串表示，值可以是任意object类型。写入数据时，只需为某个键赋值；读取数据时，再通过相同的键获取内容。
因为Session返回的是object类型，读取时通常需要进行类型转换。使用as运算符进行安全转换是常见做法，如果键不存在或类型不匹配，转换结果为null，不会抛出异常。这里需要特别注意判空，避免后续操作出现NullReferenceException。
// 写入Session
Session["UserName"] = "张三";
Session["UserId"] = 1001;
// 读取Session
string name = Session["UserName"] as string;
if (name != null)
{
// 输出欢迎信息
Response.Write("欢迎：" + name);
}
保存自定义对象与序列化
Session不仅可以保存字符串、整数等基本类型，也可以保存自定义类的实例。例如，可以将用户信息封装为一个UserInfo对象后放入Session，这样后续页面只需要一次读取就能获得完整信息，而不必分别读取多个基本类型键。
保存自定义对象时，建议为类标记可序列化特性。因为在InProc模式下，对象仍然以引用方式保存在服务器内存中，并不强制要求序列化；但如果网站部署为StateServer或SQLServer等进程外模式，Session中的数据需要跨进程传输或持久化，此时对象必须能够序列化，否则会出错。因此从一开始就让实体类支持序列化是更稳妥的做法。
读取对象时同样可以使用as运算符进行安全转换，转换失败会得到null，程序应优先判断对象是否存在，再进行后续业务处理。
[Serializable]
public class UserInfo
{
public int Id { get; set; }
public string Name { get; set; }
}
// 存入对象
UserInfo user = new UserInfo { Id = 1, Name = "李四" };
Session["CurrentUser"] = user;
// 取出对象
UserInfo u = Session["CurrentUser"] as UserInfo;
if (u != null)
{
Response.Write("用户：" + u.Name);
}
设置超时时间与存储模式
Session默认的超时时间通常为20分钟。也就是说，如果用户在20分钟内没有向服务器发送任何请求，该会话就会被判定为过期。这个默认值在一些场景下可能过短，例如用户填写长表单或阅读较长内容时，页面没有回发，超时后Session数据会丢失，用户可能被意外登出。
可以通过web.config文件中的配置节调整Session超时时间，同时也可以指定Session的存储模式。其中<sessionState>元素的timeout属性以分钟为单位，mode属性用于选择存储方式。常见的InProc模式将Session数据保存在当前应用程序进程内，读取速度最快，但应用程序重启会导致数据全部丢失。StateServer和SQLServer模式可以将数据保存在独立的进程或数据库中，更适合高可用性场景，但配置更复杂，且自定义对象必须可序列化。
<configuration>
<system.web>
<sessionState timeout="30" mode="InProc" />
</system.web>
</configuration>
清除与销毁Session数据
当用户退出登录或不再需要某些会话数据时，应该及时释放Session，避免长期占用服务器内存。ASP.NET提供了多个清除Session数据的方法，它们的影响范围并不相同。
Session.Remove方法用于删除指定的某个键及其对应的值；Session.Clear方法用于清空当前Session中的所有键值，但会话本身仍然存在；Session.Abandon方法则用于结束整个会话，服务器会清除与会话相关的所有数据，并触发会话结束事件。用户退出登录时，通常建议调用Session.Clear或Session.Abandon，并配合FormsAuthentication.SignOut等操作，确保登录状态被完整清除。
- Session.Remove("UserName") 删除单个键
- Session.Clear() 清空所有键值，但保留会话
- Session.Abandon() 结束当前会话并释放资源
常见注意点与简单页面示例
使用Session时，需要了解不同存储模式带来的影响。如果mode设置为InProc，网站重启、应用程序池回收或服务器故障都会导致Session数据全部丢失。对于需要长期保存的会话状态，可以考虑StateServer或SQLServer模式。然而进程外模式会增加网络开销，并要求存入的对象可序列化，因此需要根据实际业务权衡。
另一个容易忽略的问题是键名拼写错误。Session["key"]中的键是一个字符串，如果后续读取时写错了一个字母，比如大小写不一致，Session不会抛出异常，而是返回null。因此读取数据后必须进行判空，否则可能引发空引用异常。此外，Session中不应存放体积过大的对象，例如大型DataSet或文件字节数组，否则会迅速消耗服务器内存，影响整体性能。
Session是ASP.NET状态管理的重要工具，合理使用能够提升用户体验，但需要控制数据规模并注意生命周期。
下面通过一个完整的ASP.NET页面示例展示保存和读取Session的典型流程。页面中包含一个文本框用于输入内容，两个按钮分别负责保存和读取，还有一个标签用于显示提示信息。示例代码中的服务器端事件处理函数直接操作Session，实现数据在回发之间的保留。
该示例使用了ASP.NET服务器控件，事件触发时页面会回发到服务器端，此时Session能够保存从文本框读取的值。读取按钮再次从Session中取出同一个键的数据，并显示在标签上，以此验证会话数据是否在两次请求之间保持一致。
<%@ Page Language="C#" %>
<script runat="server">
protected void btnSave_Click(object sender, EventArgs e)
{
Session["test"] = txtValue.Text;
lblMsg.Text = "已保存";
}
protected void btnRead_Click(object sender, EventArgs e)
{
lblMsg.Text = "值为：" + (Session["test"] as string);
}
</script>
<form id="form1" runat="server">
<asp:TextBox ID="txtValue" runat="server" />
<asp:Button ID="btnSave" runat="server" Text="保存" OnClick="btnSave_Click" />
<asp:Button ID="btnRead" runat="server" Text="读取" OnClick="btnRead_Click" />
<asp:Label ID="lblMsg" runat="server" />
</form>
运行上述页面时，点击“保存”按钮会触发一次服务器回发，btnSave_Click 事件从文本框读取输入内容，并将其写入 Session["test"]。回发结束后，该值仍然保存在服务器端。再点击“读取”按钮时，第二次请求通过同一个会话标识找到之前的会话数据，并把结果显示在标签上。这说明 Session 不依赖页面表单字段的往返，适合保存不适合暴露给客户端的信息。
ASP.NET 会话状态默认采用 InProc 模式，即数据直接保存在当前应用程序进程的内存中。这种方式的访问速度较快，但应用重启、进程回收或负载均衡到不同服务器时，内存中的会话数据可能丢失。默认会话超时时间为 20 分钟，浏览器通过名为 ASP.NET_SessionId 的 Cookie 关联后续请求。若用户长时间没有操作，Session 会被自动清理。
需要留意，示例中为了突出 Session 读写流程，直接将读取到的字符串显示出来。实际项目中应使用 Server.HtmlEncode 或相应编码方式输出，避免用户输入被原样渲染到页面而产生脚本注入风险。
替换会话存储模式
如果应用部署在多台服务器上，需要让不同服务器共享 Session，可以将会话模式改为 StateServer 或 SQLServer。例如使用 StateServer 时，可在 web.config 中配置：
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
timeout="30"
cookieName="AppSessionId" />
</system.web>
</configuration>使用 StateServer 模式时，需要确保目标服务器上的 ASP.NET 状态服务已经启动。使用 SQLServer 模式时，则需要预先创建会话数据库，并把连接字符串指向对应的 SQL Server 实例。无论选择哪种进程外模式，存入 Session 的对象都应尽量可序列化，否则在序列化或反序列化时会失败。
实际使用建议
Session 适合保存用户登录标识、购物车编号、流程中的临时选择等较小的用户级数据。全局共享数据应使用 Application 或分布式缓存；需要在客户端长期保存的非敏感数据可以交给 Cookie；单个页面或控件之间的少量状态则更适合 ViewState。把不同生命周期、不同信任边界的数据放在合适的位置，是 ASP.NET 状态管理的基本思路。
小结
HTTP 本身没有记忆，Web 应用必须借助客户端或服务器端机制维持状态。Session 作为服务器端方案，提供了跨请求保留用户数据的便利，但也会占用服务器资源，并要求应用架构考虑超时、序列化和多服务器部署。理解 Session 的读写过程、默认配置和适用边界，有助于在实际开发中更稳定地管理用户状态，从而构建更可靠的 ASP.NET 应用。