TRY_CAST不会报错而CAST会中断查询，因为TRY_CAST是容错型函数，转换失败时明确返回NULL而非抛出错误；CAST则严格遵循类型契约，输入不合法即终止执行。
TRY_CAST 为什么不会报错，而 CAST 会直接中断查询？
因为 TRY_CAST 是 SQL Server 的“容错型转换函数”——它把类型转换失败当作一种可预期的业务状态（返回 NULL），而不是运行时错误。CAST 则严格遵循类型契约：只要输入不符合目标类型的解析规则，就立刻抛出 Conversion failed when converting the varchar value 'abc' to data type int. 这类错误，整个语句终止执行。
关键区别在于语义定位：TRY_CAST 不是“尽力而为”，而是“明确声明：我接受失败，并用 NULL 表达失败”。它不依赖会话设置、不触发错误栈、不进入 CATCH 块，纯粹做一次原子判断。
字符串转数字时，哪些看似合法的值会让 TRY_CAST 返回 NULL？
别被空格或纯数字迷惑——真正踩坑的是那些“肉眼像数字，但 SQL Server 解析器不认”的情况。比如：
-
TRY_CAST('123.45' AS INT)→NULL（小数点导致整型转换失败） -
TRY_CAST(' 42 ' AS INT)→42（自动 trim 空格，OK） -
TRY_CAST('42'+CHAR(9) AS INT)→NULL（制表符CHAR(9)不会被 trim，必须显式REPLACE(col, CHAR(9), '')） -
TRY_CAST('1,000' AS INT)→NULL（逗号不是数字字符，需先REPLACE(col, ',', '')） -
TRY_CAST('' AS INT)→NULL（空字符串也不行）
日期字符串用 TRY_CAST 还是 TRY_CONVERT？选错会静默出错
用 TRY_CAST('01-02-2024' AS DATETIME) 非常危险：结果取决于当前会话的 DATEFORMAT 和语言设置，可能今天是 1月2日，明天变成 2月1日，且不报错。
必须用 TRY_CONVERT 加样式码锁定行为：
-
TRY_CONVERT(DATETIME, '01-02-2024', 101)→ 强制美式（mm/dd/yyyy），固定为2024-01-02 -
TRY_CONVERT(DATETIME, '01-02-2024', 103)→ 强制英式（dd/mm/yyyy），固定为2024-02-01 - 样式码错配（如用 101 解析 '2024-02-01'）→ 直接返回
NULL，不猜测、不妥协
记住：日期/时间 + 格式控制 = TRY_CONVERT；其他通用转换（int、decimal、varchar）= 优先 TRY_CAST。
在 WHERE 条件里用 TRY_CAST 会拖慢查询，很多人没意识到
TRY_CAST 是标量函数，SQL Server 无法对其应用索引。如果写成 WHERE TRY_CAST(order_no AS INT) > 1000，哪怕 order_no 字段上有索引，也会强制全表扫描。
更稳妥的做法：
- 字段本就是
VARCHAR但业务上应存数字？建一个持久化计算列：ALTER TABLE orders ADD order_no_int AS TRY_CAST(order_no AS INT) PERSISTED，再对这个列建索引 - 或者先用正则/模式匹配预筛：
WHERE order_no NOT LIKE '%[^0-9]%' AND LEN(order_no) BETWEEN 1 AND 6，再套TRY_CAST - 避免在 JOIN 条件或聚合字段中反复调用，尤其在大表上
真正麻烦的从来不是转换本身，而是转换后怎么让数据库还能高效找到数据。
