Ocelot在.NET 6+中已基本弃用，官方推荐迁移到YARP；新建项目不应选用Ocelot，因其不支持原生minimal hosting、缺失gRPC透传、热重载能力弱且社区维护停滞。
Ocelot 在 .NET 6+ 中已基本弃用，新建项目请直接用 YARP；若必须维护旧 Ocelot 项目，核心问题是配置加载时机、中间件顺序和下游头透传逻辑，不是“怎么配”，而是“为什么配了没用”。
为什么 ocelot.json 配置总不生效
Ocelot 不是“读完 JSON 就跑”，它依赖 IOcelotConfigurationProvider 加载配置，而默认实现不监听文件变更、路径硬编码、且在 WebApplication.CreateBuilder 流程中极易被覆盖。
- 常见错误现象：
DownstreamPathTemplate写对了但返回 404；AuthenticationOptions配了但Authorization中间件完全没触发 - 根本原因：Ocelot 必须在
UseRouting()之后、UseEndpoints()之前调用UseOcelot()，且不能和MapControllers()混用 - 实操建议：改用内存配置（
AddSingleton<IOcelotConfigurationProvider, CustomJsonFileConfigProvider>()），或跳过——YARP 的AddReverseProxy()原生支持IConfiguration绑定和ChangeToken.OnChange热重载
.NET 6+ 中 JWT 验证为什么透传失败
Ocelot 本身不做鉴权，只做“转发器”。它把认证交给上游中间件，但需要严格对齐 key、顺序和头字段。
-
AddAuthentication().AddJwtBearer("Bearer", ...)必须在AddOcelot()之前注册，否则AuthenticationOptions.AuthenticationProviderKey找不到 provider -
ocelot.json中的"AuthenticationProviderKey": "Bearer"必须和AddJwtBearer()的 name 参数完全一致（区分大小写） - Ocelot 默认不透传
ClaimsPrincipal到下游，X-User-Id这类头需手动加进GlobalConfiguration或用自定义DelegatingHandler补充；更简单的方式是下游直接读HttpContext.User，前提是 Ocelot 没改写Authorizationheader
YARP 替代 Ocelot 的最小可运行配置
YARP 不需要独立配置文件，所有路由逻辑可写在 C# 里，也兼容 appsettings.json。关键是 RouteConfig 和 ClusterConfig 对齐，且必须注册反向代理服务。
- 必须注册：
builder.Services.AddReverseProxy().LoadFromConfig(builder.Configuration.GetSection("ReverseProxy")) - 注意点：YARP 默认不转发原始
Host头，如需保留，得显式配置ForwarderOptions并设PreserveHostHeader = true - 签名验证（如阿里云
X-Signature）必须自己写中间件——Ocelot/YARP 都不内置该能力；典型坑是签名中间件提前消费了Request.Body流，导致下游读不到 body
真正难的不是写路由规则，而是理解“谁在什么时候读取请求流、谁在什么时候改写 header、谁在什么时候释放 connection”。这些细节在 Ocelot 文档里藏得深，在 YARP 里则要靠读中间件源码才能确认。别迷信配置项，先抓包看实际发出的请求长什么样。
