参数化查询中能否使用GeoJson对象作为Azure Cosmos DB查询参数？

参数化查询失败的核心原因是传入参数的类型错误：
ST_WITHIN 空间计算函数要求第二个参数为GeoJSON结构的空间对象，而非字符串类型。
你直接拼接SQL时，GeoJSON字符串被直接嵌入查询语句，Cosmos DB 解析SQL时会把这段内容识别为Polygon类型的结构化对象，空间查询可以正常执行。
但使用参数化查询时，你传入的bounds_str是原始字符串类型，Cosmos DB的参数化机制会保留参数的原始类型，相当于给ST_WITHIN传入了一个字符串字面量，类型不匹配导致空间计算无法正常执行，自然匹配不到任何文档。你可以从两次查询的RU消耗差异验证这一点：无参数查询走空间索引逻辑消耗6.73RU，错误的参数化查询因为没有执行空间匹配逻辑，仅消耗3.1RU就直接返回了0结果。

你只需要将GeoJSON字符串反序列化为结构化的空间对象后再作为参数传入即可，示例代码如下：

using Microsoft.Azure.Cosmos.Spatial;
using Newtonsoft.Json;

// 原有边界字符串
var bounds_str = "{'type':'Polygon','coordinates':[[[-113.247049,53.657421],[-113.733431,53.657421],[-113.733431,53.393183],[-113.247049,53.393183],[-113.247049,53.657421]]]}";

// 第一步：将GeoJSON字符串反序列化为Cosmos识别的Polygon空间对象
var boundsPolygon = JsonConvert.DeserializeObject<Polygon>(bounds_str);

// 第二步：参数化传入结构化空间对象
var sql_query_text = "SELECT * FROM testcontainer t WHERE ST_WITHIN( t.geopoint, @bounds )";
var query_def = new Microsoft.Azure.Cosmos.QueryDefinition(sql_query_text);
query_def.WithParameter("@bounds", boundsPolygon);

如果你不想额外引用Microsoft.Azure.Cosmos.Spatial的类型依赖，也可以将GeoJSON字符串反序列化为JObject（Newtonsoft.Json）或JsonElement（System.Text.Json）类型的结构化JSON对象，只要不是原始字符串，都可以被ST_WITHIN函数正确识别。

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