会话状态是ASP.NET Core中用于在HTTP无状态协议下保持用户数据的机制，通过会话ID（通常存储在Cookie中）关联用户多次请求。它需手动配置，首先在Program.cs中注册服务：添加IDistributedCache实现（如AddDistributedMemoryCache用于单机，AddStackExchangeRedisCache用于分布式），再调用AddSession设置超时、Cookie安全选项等，并使用app.UseSession()启用中间件。使用时通过HttpContext.Session读写数据，支持字符串、整数及序列化后的复杂对象（如JSON），建议仅存储轻量、临时、非敏感信息（如用户偏好、购物车ID）。与旧版ASP.NET Framework默认启用不同，ASP.NET Core要求显式配置，体现其模块化和高性能设计哲学，鼓励开发者根据场景选择合适存储方案：内存缓存适合开发或单机环境；Redis适合高并发、多服务器部署；SQL Server适合对持久性要求高的场景。安全性方面需防范会话劫持，措施包括启用HTTPS、设置HttpOnly和Secure Cookie、避免存储敏感信息，并合理配置超时策略。总之，会话状态应作为轻量“便签纸”，兼顾性能、可扩展与安全。
ASP.NET Core中的会话状态，说白了，就是一种在用户多次请求之间保持数据的方式。你想想，HTTP协议本身是无状态的，每次请求都是独立的，互不相干。但我们做应用，总需要记住用户是谁，他上次做了什么，购物车里有什么东西。这时候，会话状态就像一个短暂的“记忆”，让服务器能识别并关联同一个用户的不同请求。它通常通过一个会话ID（存储在客户端的Cookie中）来标识，服务器端则根据这个ID存储和检索对应的数据。在我看来，它就是为了解决HTTP无状态性带来的用户体验割裂感。
在ASP.NET Core中管理会话状态，其实主要分两步：配置和使用。这不像早期的ASP.NET Framework那样默认就给你开箱即用，ASP.NET Core更强调模块化和选择性，所以你需要明确地启用它。
第一步：配置会话服务
首先，你得在应用的
Program.cs
Startup.cs
// Program.cs (ASP.NET Core 6.0+)
var builder = WebApplication.CreateBuilder(args);
// 添加会话服务
builder.Services.AddDistributedMemoryCache(); // 必须先添加一个IDistributedCache实现
builder.Services.AddSession(options =>
{
options.IdleTimeout = TimeSpan.FromMinutes(30); // 设置会话超时时间
options.Cookie.HttpOnly = true; // 确保会话Cookie只能通过HTTP访问，防止XSS攻击
options.Cookie.IsEssential = true; // 标记此Cookie为应用运行所必需
options.Cookie.Name = ".MyApp.Session"; // 自定义会话Cookie名称，增加安全性
});
var app = builder.Build();
// 使用会话中间件
app.UseSession();
// ... 其他中间件和路由配置
app.MapGet("/", async context =>
{
// ...
});
app.Run();这里有几个点需要注意：
AddDistributedMemoryCache()
IDistributedCache
AddSession()
IdleTimeout
Cookie.HttpOnly
Cookie.IsEssential
Cookie.Name
第二步：在代码中使用会话
一旦配置完成，你就可以在控制器、Razor Pages或者最小API的请求处理逻辑中通过
HttpContext.Session
会话数据通常以键值对的形式存储，但它只接受
byte[]
// 在控制器或最小API中
app.MapGet("/set-session", async context =>
{
context.Session.SetString("UserName", "张三");
context.Session.SetInt32("UserId", 123);
await context.Session.CommitAsync(); // 显式保存会话，尤其是在异步操作中
await context.Response.WriteAsync("会话数据已设置。");
});
app.MapGet("/get-session", async context =>
{
var userName = context.Session.GetString("UserName");
var userId = context.Session.GetInt32("UserId");
if (!string.IsNullOrEmpty(userName))
{
await context.Response.WriteAsync($"用户名: {userName}, 用户ID: {userId}");
}
else
{
await context.Response.WriteAsync("会话中没有找到数据。");
}
});
app.MapGet("/clear-session", async context =>
{
context.Session.Clear(); // 清除当前会话中的所有数据
await context.Response.WriteAsync("会话数据已清除。");
});如果你需要存储更复杂的对象，比如一个自定义的用户信息类，你就需要自己进行JSON序列化和反序列化。
public class UserInfo
{
public int Id { get; set; }
public string Name { get; set; }
public List<string> Roles { get; set; }
}
// 存储复杂对象
app.MapGet("/set-complex-session", async context =>
{
var user = new UserInfo { Id = 456, Name = "李四", Roles = new List<string> { "Admin", "Editor" } };
context.Session.SetString("CurrentUser", System.Text.Json.JsonSerializer.Serialize(user));
await context.Response.WriteAsync("复杂对象已存储。");
});
// 获取复杂对象
app.MapGet("/get-complex-session", async context =>
{
var userJson = context.Session.GetString("CurrentUser");
if (!string.IsNullOrEmpty(userJson))
{
var user = System.Text.Json.JsonSerializer.Deserialize<UserInfo>(userJson);
await context.Response.WriteAsync($"当前用户: {user.Name}, 角色: {string.Join(", ", user.Roles)}");
}
else
{
await context.Response.WriteAsync("会话中没有复杂对象。");
}
});记住，
HttpContext.Session
CommitAsync()
这确实是很多从ASP.NET Framework转过来的开发者会遇到的一个“坑”或者说疑惑点。我个人觉得，这体现了ASP.NET Core在设计哲学上的一个巨大转变，也是它更现代、更灵活的原因。
在ASP.NET Framework时代，会话状态（尤其是InProc模式）是默认开启的，而且用起来感觉很“透明”，你不需要做太多配置就能直接用。这在单体应用、单服务器部署的场景下确实很方便。但问题是，这种紧耦合、默认开启的模式，在分布式、微服务、云原生这些现代应用架构中，就显得非常笨重和低效了。
ASP.NET Core从一开始就拥抱了模块化和依赖注入。它的设计理念是“你只为你需要的功能付费”，换句话说，如果你不需要会话状态，那它就不会给你加载相关的代码和资源，这有助于保持应用的轻量和高性能。
再者，ASP.NET Core强烈推荐构建无状态的服务。为什么呢？因为无状态服务更容易扩展。你可以随意增加或减少服务器实例，而不需要担心会话数据在不同服务器之间同步的问题。如果你的应用必须依赖会话状态，ASP.NET Core也鼓励你使用分布式会话存储（如Redis、SQL Server），这样即使服务器实例挂掉或者需要扩容，用户的会话也能保持连续性。而ASP.NET Framework默认的InProc模式，一旦服务器重启或扩容，会话数据就全丢了，这在生产环境中简直是灾难。
所以，ASP.NET Core选择将会话状态作为一个可选的、需要显式配置的功能，其实是为了引导开发者思考：我真的需要会话吗？如果需要，我应该如何以最健壮、最可扩展的方式来实现它？这是从“便利性优先”到“可扩展性、性能和灵活性优先”的转变。在我看来，这种“麻烦”是值得的，它强迫我们去构建更好的应用。
这是一个非常实际的问题，存储什么、不存储什么，直接关系到应用的性能、可扩展性和安全性。我的经验是，会话状态最适合存储那些小巧、瞬时、与特定用户请求流程紧密相关且不敏感的数据。
具体来说，你可以考虑存储：
那么，什么不应该存储呢？
总而言之，将会话视为一个轻量级的、临时性的“便签纸”，而不是一个持久化的数据库。保持会话数据尽可能小、尽可能少，是提升应用性能和可维护性的关键。
选择正确的会话存储提供程序，是构建可扩展和健壮的ASP.NET Core应用的关键决策之一。这真的不是拍脑袋就能定的，需要结合你的应用规模、部署环境、性能要求和预算来综合考虑。
1. In-Memory Cache (内存缓存)
AddDistributedMemoryCache()
2. Redis Cache (Redis缓存)
优点：
缺点：
配置示例：
// Program.cs
builder.Services.AddStackExchangeRedisCache(options =>
{
options.Configuration = "your_redis_connection_string,password=your_password"; // Redis连接字符串
options.InstanceName = "MyAppSession_"; // 实例名称前缀，避免与其他应用冲突
});
// 然后照常使用 builder.Services.AddSession(...)适用场景：
3. SQL Server Cache (SQL Server缓存)
优点：
缺点：
配置示例： 首先，你需要安装
Microsoft.Extensions.Caching.SqlServer
dotnet sql-cache create "your_connection_string" "SessionData"
// Program.cs
builder.Services.AddDistributedSqlServerCache(options =>
{
options.ConnectionString = "your_sql_server_connection_string"; // SQL Server连接字符串
options.SchemaName = "dbo"; // 数据库Schema
options.TableName = "SessionData"; // 会话表名称
options.CacheEntryOptions = new Microsoft.Extensions.Caching.Distributed.DistributedCacheEntryOptions
{
SlidingExpiration = TimeSpan.FromMinutes(30) // 滑动过期时间
};
});
// 然后照常使用 builder.Services.AddSession(...)适用场景：
在我看来，如果你是小型应用或者刚刚起步，In-Memory是OK的。但一旦你考虑扩展到多服务器，或者用户量上来，Redis几乎是首选，它在性能和可扩展性之间找到了一个很好的平衡点。SQL Server则是一个备选项，主要是在对持久性有特殊要求，或者团队对SQL Server非常熟悉的情况下才会考虑。选择没有绝对的对错，只有最适合你当前需求的。
在讨论会话状态的便利性时，我们绝不能忽视其安全性。毕竟，会话承载着用户与应用交互的关键信息，一旦被滥用或泄露，可能导致严重的安全问题。我个人认为，以下几点是你在使用ASP.NET Core会话状态时必须深入思考和采取措施的：
会话劫持 (Session Hijacking) 会话劫持是最大的威胁之一。攻击者通过某种方式窃取了用户的会话ID（通常是存储在Cookie中的），然后利用这个ID冒充用户进行操作。
options.Cookie.HttpOnly
true
options.Cookie.SecurePolicy
CookieSecurePolicy.Always
跨站请求伪造 (CSRF) 保护 虽然CSRF主要针对的是请求，而不是直接的会话数据，但CSRF攻击往往利用了用户已有的会话。
@Html.AntiForgeryToken()
[ValidateAntiForgeryToken]
敏感数据存储 前面提到过，不要将会话当作一个安全的敏感数据存储库。
会话超时管理 不合理的会话超时设置，既可能影响用户体验，也可能带来安全风险。
IdleTimeout
IdleTimeout
IdleTimeout
分布式缓存的安全 如果你使用了Redis或SQL Server作为会话存储，那么这些存储本身的安全也至关重要。
在我看来，会话状态是把双刃剑，它带来了便利，但也带来了潜在的风险。作为开发者，我们有责任去理解这些风险，并采取一切必要的措施去规避它们，确保用户的会话数据安全无虞。
以上就是ASP.NET Core中的会话状态是什么？如何管理？的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
643
收藏
