FastEndpoints项目中的路由参数与Newtonsoft.Json驼峰命名策略冲突解析

问题背景

在FastEndpoints项目中，当开发者从5.18版本升级到5.19及以上版本时，会遇到一个关于路由参数命名和模型绑定的兼容性问题。这个问题主要出现在同时使用Newtonsoft.Json的驼峰命名策略(CamelCaseNamingStrategy)和Endpoint描述中设置了clearDefaults: true参数的情况下。

问题现象

在特定配置下，当Endpoint的路由参数使用非驼峰命名(如{Id})而请求体使用驼峰命名时，Swagger文档生成会出现不一致的情况。具体表现为：

• 请求体参数能正确应用驼峰命名策略
• 但路由参数却保持原样，不进行转换
• 导致生成的API规范不一致，可能影响客户端调用

技术原理分析

这个问题的根源在于FastEndpoints 5.19+版本中NSwag升级到v14后，命名策略的实现方式发生了变化。当同时满足以下条件时会出现问题：

1. 路由模板中使用非驼峰命名的参数(如/api/users/{Id})
2. 在Endpoint描述中使用了clearDefaults: true参数
3. 项目中配置了使用Newtonsoft.Json的驼峰命名策略

在底层实现上，clearDefaults会清除默认的元数据，而当没有明确定义请求DTO类型时，Swagger操作处理器无法正确推断DTO属性，导致路由参数命名策略无法正确应用。

解决方案

方案一：关闭属性命名策略

可以通过以下配置恢复旧版行为：

builder.Services.SwaggerDocument(
   p =>
   {
       p.UsePropertyNamingPolicy = false;
   });

这种方法适合已有项目升级，可以避免修改大量已有的路由模板。

方案二：明确指定请求DTO类型

在Endpoint描述中明确指定请求DTO类型：

Description(
    x =>
    {
        x.Accepts<GetUserRequest>(); // 明确指定请求类型
    },
    clearDefaults: true);

这种方法能让Swagger处理器正确推断属性，解决命名策略不一致的问题。

方案三：避免使用clearDefaults

在大多数情况下，clearDefaults并不是必需的。使用标准的摘要描述通常就能满足需求，避免这个问题。

最佳实践建议

1. 新项目：建议启用命名策略(UsePropertyNamingPolicy = true)，并确保路由模板中的参数命名与配置的命名策略一致。

2. 升级项目：可以先关闭命名策略，逐步调整路由模板，或者采用方案二明确指定请求类型。

3. API设计：建议统一命名风格，避免混合使用不同命名规则，可以减少这类问题的发生。

4. Swagger文档：注意这只是Swagger UI相关的问题，实际的API路由和模型绑定在Swagger之外是正常工作的。

总结

FastEndpoints升级到5.19+版本后，命名策略的实现方式发生了变化，开发者需要注意路由参数命名与配置的命名策略的一致性。通过合理配置和遵循最佳实践，可以避免这类兼容性问题，确保API文档生成的正确性。

对于已经存在的项目，可以采用渐进式的调整策略；对于新项目，则建议从一开始就采用统一的命名规范，减少后续的兼容性问题。