Azure Functions Cosmos DB绑定路由参数传ORDER BY报错

Azure Functions Cosmos DB 输入绑定的{参数名}占位符，仅支持替换SQL语句中的常量值，不支持替换SQL语法关键字、标识符（包括排序方向ASC/DESC、字段名、集合名、子句关键字等）。
你测试的两个正常场景完全符合这个规则：

• 移除ORDER BY子句后，所有占位符替换的都是WHERE条件里的匹配值、CONTAINS函数的搜索文本，属于常量范畴，绑定可以正常处理
• 硬编码ASC/DESC后，SQL语法结构固定，剩余占位符还是替换常量，因此可以正常执行

当你用{Order}占位排序方向时，绑定底层会将该位置标记为参数传入，最终生成的SQL在排序关键字位置出现参数标记，Cosmos DB SQL引擎无法解析，直接抛出SC1001语法错误。

方案1：使用Cosmos DB SDK动态构造查询（生产环境推荐） #

放弃在绑定特性中写死SQL的方式，直接通过绑定注入的CosmosClient实例在函数代码中构造查询。注意必须对排序方向参数做白名单校验，避免SQL注入风险。
示例代码：

[FunctionName("FilterEvents")]
public static async Task<IActionResult> FilterEvents(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "events/{PartitionKey}/{Order}/{SearchTerm}")] HttpRequest req,
    [CosmosDB(
            databaseName: Constants.DatabaseName,
            collectionName: Constants.ContainerName,
            ConnectionStringSetting = "CosmosDBConnectionString"
        )] CosmosClient cosmosClient,
    string PartitionKey,
    string Order,
    string SearchTerm,
    ILogger log)
{
    // 白名单校验排序参数，非法值直接返回错误
    if (!Order.Equals("ASC", StringComparison.OrdinalIgnoreCase) 
        && !Order.Equals("DESC", StringComparison.OrdinalIgnoreCase))
    {
        return new BadRequestObjectResult("排序方向仅支持传入ASC或DESC");
    }

    var container = cosmosClient.GetContainer(Constants.DatabaseName, Constants.ContainerName);
    // 排序方向经过白名单校验可安全拼接，查询参数全部走参数化传值
    var queryDefinition = new QueryDefinition(
            $"SELECT * FROM c WHERE c.email = @partitionKey AND CONTAINS(c.title, @searchTerm) ORDER BY c.participantsCount {Order}")
        .WithParameter("@partitionKey", PartitionKey)
        .WithParameter("@searchTerm", SearchTerm);

    var result = new List<Event>();
    using (var feedIterator = container.GetItemQueryIterator<Event>(
               queryDefinition, 
               requestOptions: new QueryRequestOptions { PartitionKey = new PartitionKey(PartitionKey) }))
    {
        while (feedIterator.HasMoreResults)
        {
            var response = await feedIterator.ReadNextAsync();
            result.AddRange(response.Resource);
        }
    }

    return new OkObjectResult(result);
}

这个方案没有额外的RU消耗，参数校验到位也没有安全风险，是生产环境的首选实现。

方案2：双绑定分支（仅适合低流量测试场景） #

如果不想直接操作SDK，可以写两个固定SQL的Cosmos DB绑定，分别对应ASC和DESC排序，函数内根据传入的Order参数选择对应结果：

[FunctionName("FilterEvents")]
public static IActionResult FilterEvents(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "events/{PartitionKey}/{Order}/{SearchTerm}")] HttpRequest req,
    [CosmosDB(
            databaseName: Constants.DatabaseName,
            collectionName: Constants.ContainerName,
            ConnectionStringSetting = "CosmosDBConnectionString",
            SqlQuery = "SELECT * FROM c WHERE c.email = {PartitionKey} AND CONTAINS(c.title, {SearchTerm}) ORDER BY c.participantsCount ASC"
        )] IEnumerable<Event> ascSortedEvents,
    [CosmosDB(
            databaseName: Constants.DatabaseName,
            collectionName: Constants.ContainerName,
            ConnectionStringSetting = "CosmosDBConnectionString",
            SqlQuery = "SELECT * FROM c WHERE c.email = {PartitionKey} AND CONTAINS(c.title, {SearchTerm}) ORDER BY c.participantsCount DESC"
        )] IEnumerable<Event> descSortedEvents,
    string PartitionKey,
    string Order,
    string SearchTerm,
    ILogger log)
{
    var events = Order.Equals("ASC", StringComparison.OrdinalIgnoreCase) ? ascSortedEvents : descSortedEvents;
    return new OkObjectResult(events);
}

这个方案的缺点很明显：无论传入什么排序方向，函数执行时两个绑定的SQL都会被执行，会消耗双倍的RU，不适合生产高流量场景。

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