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，每次跳转都丢失上下文 事情说清了就结束。重定向看着简单，真到下载文件这一步，URL 变了、流断了、长度不对、权限丢了——问题往往藏在自动行为和你假设的一致性之间。
