含多源绑定的DTO在Swagger中生成错误URL的问题及合理性咨询

我尝试创建包含多源绑定属性的RequestDto类：

public class RequestDto
{
    [FromHeader]
    public string correlationId;

    [FromRoute]
    public string Id { get; set; }

    [FromQuery]
    public string Status { get; set; }
}

并将其作为HttpGet接口的参数使用：

[HttpGet("{id}/enrollments")]
public async Task<IActionResult> GetEnrollments(RequestDto request){...}

测试时发现，Swagger生成的curl请求如下：

curl -X 'GET' \
  'http://localhost:8080/{id}/entrollments?Status=Enrolled' \
-H 'accept: text/plain'
-H 'x-correlation-id: 12343'

该请求返回错误，Id字段被填充为字面量"{id}"；但使用Postman、Insomnia或手动替换{id}为实际值的curl请求可正常返回结果。现咨询：

1. 为何Swagger会生成错误的URL？
2. 是否不推荐在同一个DTO中使用多种不同的绑定特性？
3. 包含多源绑定的DTO是否存在行为不一致的情况？

1. Swagger生成错误URL的原因 #

Swagger（OpenAPI）工具在解析包含多源绑定的DTO时，对路由参数的识别存在局限性。当路由参数{id}被封装在DTO内部而非作为独立的接口参数时，Swagger无法正确将其识别为需要替换的路由变量，而是直接将占位符字符串{id}写入生成的URL中。

ASP.NET Core本身可以正确处理这种DTO内的路由绑定，但Swagger的文档生成逻辑默认更适配独立参数的场景，对DTO内的路由参数解析支持不足，导致生成的curl请求保留了占位符。

2. 是否推荐在同一个DTO中使用多种绑定特性 #

没有明确的不推荐，这种做法在实际项目中是可行的，尤其适合参数较多、需要按来源归类的场景，能提升代码的整洁性。但需要注意几个问题：

• 要确保团队成员理解这种绑定方式，避免维护混乱
• 像Swagger这类工具可能存在兼容性问题，需要额外配置来修正文档生成的错误
• 对于简单接口，直接使用独立参数可能更直观，减少工具适配成本

3. 多源绑定DTO是否存在行为不一致 #

ASP.NET Core的模型绑定系统本身对多源绑定的处理是一致且可靠的，只要绑定特性标注正确，无论是通过DTO还是独立参数，模型绑定的逻辑都是相同的。

出现行为差异通常不是框架本身的问题，而是外部工具（如Swagger）的解析问题，或者是开发者对绑定特性的误用（比如路由参数名称大小写不匹配、特性标注错误）。只要确保DTO的属性名称与路由、查询、头参数的名称匹配（注意ASP.NET Core的参数名称映射规则，比如correlationId会自动映射为x-correlation-id），框架的绑定行为是稳定的。

内容的提问来源于stack exchange，提问作者Rio