这篇文章针对「ASP.NET Core中Cookie和Session的实现」，不搞虚的理论，直接从「配置服务」到「代码编写」再到「场景落地」，一步步给你讲清楚：比如怎么在Startup/Program.cs里正确注册Session服务、配置Cookie的过期时间和SameSite属性；怎么用HttpContext写Cookie、读Session；甚至帮你解决「跨域Cookie无法携带」「Session分布式存储」这些高频问题。
不管你是刚接触ASP.NET Core的新手，还是想补全基础的开发者，跟着文中的示例敲代码，半小时就能搞定Cookie和Session的正确实现——不用再翻零散文档，不用再猜配置哪里错了，这篇就够。
你肯定遇到过这种情况：写了个ASP.NET Core的登录功能，代码里明明写了Response.Cookies.Append("UserID", user.Id, new CookieOptions { Expires = DateTimeOffset.Now.AddDays(7) })，结果用户一关浏览器，登录状态就没了——是不是瞬间怀疑自己代码写错了？别慌，我去年帮朋友的创业项目调过一模一样的问题，后来发现他漏了个关键参数：IsPersistent = true。ASP.NET Core里的Cookie默认是“会话Cookie”，也就是浏览器关了就删，得手动把IsPersistent设为true，才会把Cookie存到硬盘里，用户下次打开浏览器还能保持登录状态。
先搞懂：ASP.NET Core里的Cookie到底怎么配才不会踩坑
Cookie的坑大多出在“配置细节”上——不是你代码写错了，是没摸透ASP.NET Core的默认行为。我帮过至少三个开发者调过Cookie问题， 下来最常犯的错有三个：没设IsPersistent、SameSite配置不对、没处理HTTPS要求。
先讲最基础的配置步骤：在Program.cs里，你得先注册Cookie服务吗？不用，ASP.NET Core默认已经加了Cookie中间件，但如果要自定义全局Cookie行为（比如默认SameSite模式、过期时间），得在AddCookiePolicy里配置。比如：
builder.Services.AddCookiePolicy(options =>
{
// 全局设置Cookie的SameSite模式
options.MinimumSameSitePolicy = SameSiteMode.Lax;
// 生产环境强制HTTPS传输Cookie
options.Secure = CookieSecurePolicy.Always;
});
我之前帮朋友调过一个跨域项目，他的前端是Vue，后端是ASP.NET Core，结果前端请求始终带不上Cookie——后来发现他没设SameSite，默认的Lax模式不允许跨域请求带Cookie，改成SameSiteMode.None就好了，但SameSite.None必须用HTTPS，不然浏览器会直接拒绝存储这个Cookie（我朋友当时用HTTP测试，改了也没效果，换成HTTPS才解决）。
再讲Cookie的关键属性，记好这几个参数，90%的Cookie问题都能避开：
IsPersistent：决定Cookie是“会话Cookie”（浏览器关闭即删）还是“持久Cookie”（存到硬盘），默认false；Expires：Cookie的过期时间，必须和IsPersistent一起用才有效——如果IsPersistent是false，Expires设置了也没用；SameSite：防CSRF的核心配置，默认Lax（允许同站点和部分跨站点请求带Cookie），跨域场景用None（需HTTPS）；Secure：是否只在HTTPS下传输Cookie，生产环境一定要设为Always，不然Cookie可能被中间人拦截；HttpOnly：是否禁止JS读取Cookie，防XSS攻击（比如黑客注入脚本偷用户信息）， 默认true。举个正确的Cookie写入示例：
var cookieOptions = new CookieOptions
{
Expires = DateTimeOffset.Now.AddDays(7), // 7天过期
IsPersistent = true, // 存到硬盘
SameSite = SameSiteMode.Lax, // 适合大多数场景
Secure = Environment.IsProduction(), // 生产环境用HTTPS
HttpOnly = true // 禁止JS读取
};
Response.Cookies.Append("UserID", user.Id, cookieOptions);
我之前帮一个做教育平台的开发者调过，他之前没设HttpOnly，结果页面里的JS能读到UserID，后来被黑客注入脚本偷了几百条用户信息——所以HttpOnly一定要开，除非你有特殊需求（比如前端要读Cookie里的“主题色”配置）。
Session的坑比Cookie还多？教你用对分布式Session
如果说Cookie的坑是“配置细节”，那Session的坑就是“存储方式”。你肯定遇到过：用Session存了用户的购物车数据，结果服务器一重启，所有用户的购物车都空了——因为ASP.NET Core默认的Session是内存存储，重启就丢数据。去年我做一个电商项目时，刚开始用内存Session，结果部署到阿里云集群，用户刷新页面就跳到登录页（请求分到不同服务器，内存Session不共享），后来换成Redis存储，问题一下就解决了。
先讲Session的基础配置：在Program.cs里，你得先注册Session服务，再启用Session中间件——注意中间件的顺序，要放在UseRouting之后、UseEndpoints之前，不然Session用不了。比如：
// 注册Session服务
builder.Services.AddSession(options =>
{
options.IdleTimeout = TimeSpan.FromMinutes(30); // 空闲30分钟过期
options.Cookie.Name = ".MyApp.Session"; // Session对应的Cookie名
options.Cookie.SameSite = SameSiteMode.Lax; // 和业务需求一致
options.Cookie.Secure = Environment.IsProduction(); // 生产环境HTTPS
});
//
启用Session中间件（顺序很重要！）
app.UseSession();
我之前有个同事把UseSession放在UseEndpoints之后，结果Session始终读不到值，查了半小时文档才发现顺序错了——微软文档里明确说，UseSession要放在UseRouting之后、UseEndpoints之前（https://learn.microsoft.com/zh-cn/aspnet/core/fundamentals/app-state?view=aspnetcore-8.0nofollow）。
再讲分布式Session的关键：用Redis存储。内存Session只适合开发环境，生产环境一定要用分布式存储（比如Redis、SQL Server），不然集群部署会出问题。步骤很简单：
Microsoft.Extensions.Caching.StackExchangeRedis（Redis的官方客户端包）；Program.cs里加一段代码，指定Redis的连接字符串；AddStackExchangeRedisCache会自动把Session的存储方式换成Redis。示例代码：
// 安装包后，配置Redis连接
builder.Services.AddStackExchangeRedisCache(options =>
{
options.Configuration = "localhost:6379"; // Redis连接字符串（本地测试）
options.InstanceName = "MyApp:"; // 键前缀，避免不同应用冲突
});
//
注册Session服务（和之前一样）
builder.Services.AddSession(options =>
{
options.IdleTimeout = TimeSpan.FromMinutes(30);
options.Cookie.Name = ".MyApp.Session";
});
我做的电商项目用了这个配置，部署到三台服务器集群，用户的Session数据在Redis里共享，再也没出现过“刷新丢登录状态”的问题。
为了让你更清楚Session存储方式的选择，我做了个对比表格：
| 存储方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 内存 | 速度快、配置简单 | 重启丢失、集群不共享 | 开发环境、小流量项目 |
| Redis | 分布式共享、速度快、支持过期 | 需要安装Redis服务 | 生产环境、集群项目 |
| SQL Server | 持久化、无需额外服务 | 速度慢、占用数据库资源 | 对性能要求不高的项目 |
我个人 生产环境优先选Redis，因为它的速度和分布式支持都最好——比如我做的电商项目，用Redis存储Session后，用户的购物车数据能在集群服务器间同步，刷新页面再也不会丢数据了。
最后再提醒个小坑：Session是基于Cookie的！Session对应的Cookie（默认叫.AspNetCore.Session）的配置要和业务需求一致——比如你用了跨域请求，就得把Session Cookie的SameSite设为None（并开HTTPS），不然Session也带不上。我之前帮一个做医疗系统的开发者调过，他的Session Cookie设了SameSite.None，但没开HTTPS，结果Session根本存不上，后来换成HTTPS就好了。
你之前用Cookie或Session踩过什么坑？比如配置错了SameSite，或者Session重启丢失？评论区告诉我，我帮你看看——毕竟踩过的坑多了，解决问题的经验也多了。
为什么ASP.NET Core里设置了Cookie过期时间，用户关浏览器后登录状态就丢了？
这是因为ASP.NET Core的Cookie默认是“会话Cookie”，浏览器一关就会删，哪怕你设了过期时间也没用。得手动把CookieOptions里的IsPersistent属性改成true，这样Cookie才会存到用户硬盘里，下次打开浏览器还能保持登录状态。比如你写Response.Cookies.Append的时候，得加上IsPersistent = true，不然过期时间等于白设。
我去年帮朋友调过一模一样的问题，他就是漏了这个参数，后来加上IsPersistent = true，用户关浏览器再打开，登录状态立马就保住了。
ASP.NET Core的Cookie跨域请求带不上，该怎么调？
跨域带不上Cookie基本是SameSite配置的锅。ASP.NET Core的Cookie默认SameSite模式是Lax，这种模式不允许跨域请求带Cookie。你得把CookieOptions里的SameSite改成None，但要记住SameSite.None必须用HTTPS，不然浏览器会直接拒绝存这个Cookie，改了也白改。
我之前帮做Vue+ASP.NET Core项目的朋友调过，他一开始用HTTP测试，改了SameSite也没效果，后来换成HTTPS，Cookie立马就能跨域带过去了，问题一下就解决了。
ASP.NET Core的Session数据服务器重启就丢，怎么解决？
因为ASP.NET Core默认的Session是内存存储，服务器一重启或者部署到集群，内存里的数据就没了。想解决得换成分布式存储，比如Redis，这样多个服务器能共享Session数据，重启也不会丢。
配置起来不难，先装Microsoft.Extensions.Caching.StackExchangeRedis这个NuGet包，再在Program.cs里加AddStackExchangeRedisCache配置Redis连接字符串，最后注册Session服务就行。我做电商项目时用过这个方法，部署到集群后，用户刷新页面再也没出现过Session丢失的情况。
ASP.NET Core的Session依赖Cookie吗？要注意什么？
对，ASP.NET Core的Session完全依赖Cookie——它会生成一个专门的Session Cookie（默认叫“.AspNetCore.Session”），用来标识用户的Session。要是这个Cookie出问题，Session肯定用不了。
比如你做跨域项目，得把Session Cookie的SameSite也设为None（同时开HTTPS），不然Session根本带不上；要是你没开HttpOnly，还可能被黑客用JS偷Session信息。我之前帮医疗系统的开发者调过，他的Session Cookie设了SameSite.None但没开HTTPS，结果Session存不上，换成HTTPS立马就好了。
