SQL Server 不支持将变量直接用于 IN 子句，因 @var 仅被视为单个值而非列表；推荐使用 STRING_SPLIT(@ids, ',') 拆分字符串并显式转换类型，安全高效且无需动态 SQL。
为什么不能直接用变量拼接 IN 列表
因为 SQL Server（以及大多数数据库）在解析阶段就固定了语句结构，IN (@var) 中的 @var 只能代表单个值，不是值列表。传入 '1,2,3' 会被当做一个字符串字面量，而不是三个独立整数——结果永远不匹配。
SQL Server 推荐做法：用 STRING_SPLIT 拆分字符串参数
SQL Server 2016+ 原生支持 STRING_SPLIT，它能把逗号分隔的字符串转成行集，可直接用于 IN 子查询或 JOIN。这是最安全、无需动态 SQL 的方式。
实操建议：
- 输入参数声明为
@ids NVARCHAR(MAX)，调用时传'1,2,5,10' - 在 WHERE 条件中写成：
id IN (SELECT value FROM STRING_SPLIT(@ids, ',')) - 注意
STRING_SPLIT返回的value是NVARCHAR，若字段是INT，需显式转换：CAST(value AS INT) - 如果传空字符串或
NULL，STRING_SPLIT返回空结果集，整个IN条件判为 false，符合预期
兼容旧版本 SQL Server：用临时表 + 字符串拆分函数
SQL Server 2016 之前没有内置拆分函数，常见替代是自定义表值函数（如 dbo.SplitString），或先插入临时表再 JOIN。
实操建议：
- 避免用
EXEC(@sql)拼接完整 SQL——易受注入、执行计划缓存失效、调试困难 - 若必须用动态 SQL，至少用
sp_executesql并参数化其他条件，仅把IN部分作为字符串拼入 - 拆分函数返回结果必须有明确列名（如
item），否则IN (SELECT item FROM ...)会报错 - 测试边界：传入
'1,,3'（含空项）、' 1 , 2 '（带空格）时，函数是否清洗数据
PostgreSQL 或 MySQL 怎么办
各数据库处理逻辑不同，不能套用 SQL Server 方案：
- PostgreSQL 支持
IN (VARIADIC ARRAY[...])，但存储过程里更常用ANY(STRING_TO_ARRAY(...)) - MySQL 8.0+ 可用
JSON_CONTAINS配合 JSON 数组，或用FIND_IN_SET(id, @ids)（性能差，无法走索引） - MySQL 5.7 及更早版本几乎只能靠动态 SQL +
CONCAT拼接，务必对输入做白名单校验（如只允许数字和逗号）
跨数据库迁移时，IN 动态参数是最容易出兼容性问题的地方，别假设某个函数在所有版本都存在。
