httpclient 默认自动处理301/302重定向（最多5次），返回最终响应；若下载内容异常，需检查requesturi是否变更、statuscode是否为200，并注意关闭自动重定向时需手动处理location头及上下文传递。
HttpClient 默认会自动处理 301/302 重定向
只要没显式禁用，HttpClient 在发起请求时默认跟随重定向（最多 5 次），你拿到的 HttpResponseMessage 是最终响应，不是跳转中间页。这是 .NET Core 2.1+ 和 .NET 5+ 的行为，和旧版 WebClient 或手动发 HTTP 请求不同。
常见错误现象：你发现下载文件内容是 HTML（比如登录页、404 页面），而不是预期的 PDF/ZIP —— 很可能是因为重定向到了一个需要鉴权或已失效的地址，而你没检查 ResponseMessage.RequestMessage.RequestUri 是否和原始 URL 一致。
- 用
response.RequestMessage.RequestUri查看实际到达的地址 - 用
response.StatusCode确认是不是OK（200），别只看没抛异常就以为成功 - 如果服务端返回 302 但 Location 是相对路径，
HttpClient能正确拼接，无需手动处理
需要手动控制重定向时：设置 AllowAutoRedirect = false
有些场景必须自己接管跳转逻辑：比如要记录每次跳转的 URL、要对特定跳转做鉴权头注入、或要防止跳到不可信域名。这时得关掉自动跳转，自己解析 Location 头再发新请求。
注意：关闭后，遇到 301/302 你会直接收到该状态码响应，Content 通常为空，必须读 Headers.Location 才能得到目标地址。
- 创建
HttpClientHandler实例，设AllowAutoRedirect = false - 用这个 handler 构造
HttpClient，否则默认 handler 仍会跳转 -
Location可能是绝对 URL，也可能是相对路径；用new Uri(response.RequestMessage.RequestUri, locationHeader)安全解析 - 手动跳转时记得复用 cookie、认证头等上下文，
HttpClient不会帮你带过去
下载大文件时重定向带来的流中断风险
自动重定向对小响应没问题，但如果你用 response.Content.ReadAsStreamAsync() 下载大文件，而中间某次跳转失败（如 302 后目标服务器拒绝连接），整个流就断了，且不会抛出明显异常 —— 你可能只拿到截断的文件。
根本原因：重定向是 HttpClient 底层透明处理的，上层流不感知跳转过程。一旦某次跳转失败，它可能静默返回空流或部分流。
- 务必校验最终响应的
Content-Length（如果服务端返回了）是否与文件大小预期一致 - 下载完成后用
stream.Length检查实际字节数，不要只依赖“没异常” - 对关键下载，建议加一层校验：比如服务端提供
ETag或Content-MD5，下载完比对哈希 - 避免在重定向链中跨协议跳转（如 http → https），某些 handler 配置下会静默失败
HttpClient 实例复用与重定向配置的耦合问题
AllowAutoRedirect 是 HttpClientHandler 的属性，不是 HttpClient 的。很多人改了 HttpClient 实例的配置却无效，是因为复用了全局 handler 或用了静态单例。
典型坑：你在某个方法里 new 了一个 HttpClientHandler 关掉重定向，但项目其他地方用的是另一个共享的 HttpClient，结果行为不一致，调试时一头雾水。
- 每个有特殊重定向需求的下载逻辑，应配专属的
HttpClient+HttpClientHandler - 不要对已创建的
HttpClient尝试修改 handler 属性（它只读） - .NET 6+ 推荐用
IHttpClientFactory注册不同命名的 client，比如"download-with-redirect"和"download-no-redirect" - handler 设置
UseCookies = true时，重定向间 cookie 会自动携带；但若设为false，每次跳转都丢失上下文
