HttpClient 默认不自动处理 Cookie，必须手动配置启用 CookieContainer 的 HttpClientHandler 并复用实例；Web API 中读写 Cookie 需分别使用 Request.Cookies.TryGetValue() 和 Response.Cookies.Append()/Delete()；CookieContainer 严格遵循 RFC 6265 的 Domain/Path 匹配规则且与浏览器 Cookie 完全隔离。
HttpClient 默认不自动处理 Cookie，必须手动配置 HttpClientHandler
很多人以为 HttpClient 像浏览器一样默认记住 Cookie，结果发现每次请求都“没登录”——根本原因是它默认用的是无状态的 HttpClientHandler，不带 CookieContainer。不配这个，Set-Cookie 直接被丢弃，后续请求也不会带上。
实操建议：
- 创建
HttpClient时，必须传入自定义的HttpClientHandler，并初始化其CookieContainer属性 - 同一个
HttpClientHandler实例要复用，否则新实例的CookieContainer是空的 - 不要在每次请求都 new 一个
HttpClientHandler，否则 Cookie 不会累积
var handler = new HttpClientHandler
{
CookieContainer = new CookieContainer()
};
var client = new HttpClient(handler); // ✅ 复用 handler
Web API（ASP.NET Core）里读写 Cookie 要区分 Request.Cookies 和 Response.Cookies
在 Controller 或 Minimal API 中，HttpContext.Request.Cookies 是只读的字典，不能直接赋值；而写 Cookie 必须走 Response.Cookies.Append() 或 .Delete()，不是往字典里塞键值对。
常见错误现象：
-
Request.Cookies["token"] = "abc"→ 编译报错：无法给索引器赋值 -
Response.Cookies["x"] = "y"→ 编译失败，Response.Cookies没有索引器设值语法 - 用
Response.Headers.Add("Set-Cookie", "...")手动拼字符串 → 容易漏转义、没 HttpOnly/Secure 标志、不兼容 RFC 6265
正确做法：
- 读：直接用
Request.Cookies.TryGetValue("name", out var value) - 写：用
Response.Cookies.Append("name", "value", new CookieOptions { HttpOnly = true, Secure = true, SameSite = SameSiteMode.Strict }) - 删除：用
Response.Cookies.Delete("name")，不是设为空字符串或过期时间
CookieContainer 不支持跨域自动携带，Domain 和 Path 匹配规则很严格
CookieContainer 内部按 RFC 6265 做 Domain/Path 匹配，不是“包含就行”。比如服务端返回 Set-Cookie: sid=abc; Domain=api.example.com，但你用 https://example.com 请求，这个 Cookie 就不会被自动带上——因为 example.com 不符合 api.example.com 的子域规则（反过来才成立）。
容易踩的坑：
- 本地开发用
localhost，但服务端 Cookie 设了Domain=dev.example.com→ 匹配失败，Cookie 被丢弃 -
Path=/admin的 Cookie，发请求到/api/users就不会带 - 没设
Domain时，CookieContainer会严格按请求 Host 匹配，大小写敏感、端口也参与判断（localhost:5001≠localhost:5002）
调试建议：用 handler.CookieContainer.GetCookies(uri) 手动查当前 URI 下有哪些 Cookie，比猜更可靠。
HttpClient 的 Cookie 和浏览器不互通，测试时别混用
你用 HttpClient 登录拿到的 Cookie，和浏览器 DevTools 里看到的不是一回事。它们完全隔离：浏览器的 Cookie 存在系统级存储，CookieContainer 是内存对象；即使域名路径全一致，也不会共享。
这意味着：
- 不能靠浏览器登录后，再用
HttpClient直接发请求“蹭”登录态 - 自动化测试中，如果想模拟用户行为，必须让
HttpClient完整走一遍登录流程（POST 表单 → 解析Set-Cookie→ 后续请求自动携带） - 抓包看到浏览器带了 5 个 Cookie，不代表你的
HttpClient也会带全——得看CookieContainer里实际存了几个、匹配不匹配
最常被忽略的一点：HTTPS 站点返回的 Secure Cookie，在 HttpClient 发 HTTP 请求时会被静默过滤掉，连 GetCookies() 都查不到——协议不匹配，容器直接无视。
