优先用 TRY_CAST；仅需控制日期/数字格式时才用 TRY_CONVERT。二者均安全返回 NULL，但 TRY_CAST 语义纯粹、标准兼容，TRY_CONVERT 支持样式参数但仅限特定类型。
TRY_CAST 和 TRY_CONVERT 用哪个更稳妥？
SQL Server 2012+ 开始支持 TRY_CAST 和 TRY_CONVERT，两者都能在转换失败时返回 NULL 而非报错。但行为不完全一致：TRY_CAST 是标准 SQL 兼容写法，语义更纯粹（只做类型转换）；TRY_CONVERT 支持额外的样式参数（比如日期格式），但仅限于特定类型（如 datetime、money）。如果你只是想安全转 int、decimal 或 varchar，优先用 TRY_CAST；需要控制日期/数字格式（例如把 '2024-01-01' 按 103 样式解析），才考虑 TRY_CONVERT。
常见错误场景：字符串转数字或日期时直接用 CAST/CONVERT 报错
典型问题：从日志表或用户输入字段（如 varchar 类型的 user_input）中提取数值，但数据混有空格、单位、乱码甚至空字符串。此时用 CAST(user_input AS int) 会直接触发 Conversion failed when converting the varchar value 'abc' to data type int. 错误，整个查询中断。
改用 TRY_CAST 后，失败项自动转为 NULL，可配合 ISNULL 或 COALESCE 处理：
SELECT user_input, TRY_CAST(user_input AS int) AS safe_int, ISNULL(TRY_CAST(user_input AS int), 0) AS fallback_zero FROM raw_data;
注意：TRY_CAST(' 123 ' AS int) 可成功（SQL Server 自动 trim 空格），但 TRY_CAST('123abc' AS int) 或 TRY_CAST('' AS int) 均返回 NULL。
日期字符串转换失败的隐藏坑：格式不匹配 ≠ 一定报错，但 TRY_* 更可靠
SQL Server 对 CONVERT(datetime, '2024/13/01') 这类明显非法日期，仍可能抛错；但对模糊格式（如 '01-02-2024'）可能因语言设置不同解析成 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 - 样式码不匹配时直接返回
NULL，不会静默错配
而 TRY_CAST('01-02-2024' AS datetime) 不接受样式参数，完全依赖当前会话的 DATEFORMAT 和语言设置，生产环境务必避免。
性能和 NULL 处理的连带影响
TRY_CAST 和 TRY_CONVERT 是标量函数，无法走索引（即使原列有索引），在大表上慎用于 WHERE 条件。例如：WHERE TRY_CAST(code AS int) > 100 会导致全表扫描。
另外，返回 NULL 后若参与计算或比较，需主动处理，否则结果可能意外为 NULL：
-
ISNULL(TRY_CAST(val AS decimal(10,2)), 0.0) + 100—— 安全 -
TRY_CAST(val AS decimal(10,2)) + 100—— 若原值非法，整列结果全为NULL -
WHERE TRY_CAST(val AS int) = 5—— 会过滤掉所有转换失败的行，但不会报错
真正容易被忽略的是：某些 ETL 工具或 ORM 会把数据库返回的 NULL 当作缺失值跳过校验，导致下游逻辑误判“数据正常”，其实只是转换失败被静默吞掉了。
