优先用JSON（SQL Server 2016+），因其轻量、可读、原生支持OPENJSON/ISJSON等函数；XML适用于需Schema验证的旧系统。二者均须严格校验格式、防空处理，并避免裸用JSON_VALUE于WHERE子句导致全表扫描。
XML 和 JSON 是 SQL Server 存储过程中绕过“参数个数限制”的主流方案，但二者行为差异大、容易踩坑。直接结论：优先用 JSON（SQL Server 2016+），除非你必须兼容旧版本或已有 XML 生态；别裸传多个标量参数，也别在存储过程里硬写一堆 @p1、@p2……
为什么不能直接传多个值给单个参数
SQL Server 不允许一个标量参数（如 @ids VARCHAR(100)）安全承载多个逻辑值。常见错误包括：
- 用逗号拼接字符串（
'1,2,3'）再STRING_SPLIT—— 无法保证顺序、无类型、不支持嵌套结构 - 把数组塞进
VARCHAR再手动SUBSTRING解析 —— 中文、特殊字符、空格极易错位 - 误用
TEXT或XML类型传JSON字符串 ——JSON_VALUE直接返回NULL，且不报错
用 JSON 传参：必须声明为 NVARCHAR(MAX)，且先校验
JSON 是轻量、可读、现代首选，但前提是类型和校验到位：
- 参数必须声明为
@payload NVARCHAR(MAX)——VARCHAR会截断中文/emoji；NVARCHAR(4000)可能不够长（比如含 Base64 图片字段） - 开头必须加
IF ISJSON(@payload) = 0 BEGIN RAISERROR('Invalid JSON', 16, 1) RETURN END——JSON_VALUE遇非法 JSON 静默返回NULL，不是函数失效，是输入错了 - 提取标量值用
JSON_VALUE，但路径必须精确：'$.order_id'✅，'$.items'（是个数组）❌ → 返回NULL，应改用JSON_QUERY - 中文键名必须转义：
'$.["收货地址"]'✅，'$.收货地址'❌ - 提取多个字段时，用
OPENJSON+WITH比连写 5 个JSON_VALUE更快、更稳、更易维护
示例片段：
DECLARE @payload NVARCHAR(MAX) = N'{"order_id":"ORD-001","status":"SHIPPED","items":[{"sku":"A1","qty":2},{"sku":"B2","qty":1}]}';
<p>IF ISJSON(@payload) = 0 THROW 50001, 'Invalid JSON payload', 1;</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill8483" title="dmap-jsapi-skill"><img
src="https://img.php.cn/upload/skill/000/000/081/179206214475645.jpg" alt="dmap-jsapi-skill" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill8483" title="dmap-jsapi-skill">dmap-jsapi-skill</a>
<p>DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。</p>
</div>
<a href="/xiazai/skill8483" title="dmap-jsapi-skill" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><p>SELECT
JSON_VALUE(@payload, '$.order_id') AS order_id,
JSON_VALUE(@payload, '$.status') AS status;</p><p>SELECT sku, qty
FROM OPENJSON(@payload, '$.items')
WITH (sku CHAR(10), qty INT);用 XML 传参：注意命名空间和节点路径写法
XML 更重、语法更严格，适合强结构化、需 Schema 验证的场景（如金融报文），但开发成本高：
- 节点路径区分大小写：
/root/Order✅，/Root/order❌ - 属性值提取要加
@前缀：T.c.value('(@ID)[1]', 'CHAR(16)')；元素值不用：T.c.value('(Status)[1]', 'CHAR(2)') - 若 XML 含命名空间（如
xmlns="http://example.com/ns"），必须用WITH XMLNAMESPACES声明，否则.nodes()返回空 -
.value()的 XQuery 路径中，text()不是必须的，但加了更安全（防空白文本节点干扰） - 避免反复调用
.nodes()—— 提前存入临时表（如#orders），后续 JOIN 或索引优化才有意义
示例片段：
DECLARE @xml XML = '<root><Order ID="ORD-001"><Status>SHIPPED</Status></Order></root>';
<p>SELECT
T.c.value('(@ID)[1]', 'CHAR(16)') AS order_id,
T.c.value('(Status/text())[1]', 'CHAR(8)') AS status
FROM @xml.nodes('/root/Order') AS T(c);别忽略的细节：性能、调试与权限
真实生产环境里，最容易被跳过的其实是执行计划和权限配置：
-
JSON_VALUE在WHERE子句中裸用（如WHERE JSON_VALUE(payload, '$.status') = 'SHIPPED'）会导致全表扫描 —— 没索引时性能断崖式下跌 - 若高频查询某 JSON 字段，建计算列 + 持久化索引：
ALTER TABLE orders ADD status AS JSON_VALUE(payload, '$.status') PERSISTED，再在该列上建索引 -
OPENXML（老式 XML 解析）需要sp_xml_preparedocument/sp_xml_removedocument配对调用，漏掉后者会内存泄漏 - 应用层传参时，确保 JSON 字符串已 UTF-8 编码并正确转义 —— 特别是前端用
JSON.stringify后直接拼进 SQL，可能引入控制字符
复杂点不在语法，而在校验链是否闭环、解析结果是否可预测、查询路径是否可索引。传进去容易，稳稳取出来并查得快，才是关键。
