try_convert能避免日期转换中断，因为它在失败时返回null而非报错；安全用法包括try_convert(date, col)、加样式参数、配合isnull设默认值、where中过滤非null值。
TRY_CONVERT 为什么能避免日期转换中断
因为 TRY_CONVERT 在转换失败时返回 NULL，而不是抛出错误；而 CONVERT 或 CAST 遇到非法日期（比如 '2023-02-30' 或 'abc'）会直接中止查询执行。这是它和传统转换函数最根本的区别——控制权在你手上，不是在 SQL Server 的错误机制里。
怎么写一个安全的日期转换表达式
把可能出问题的字符串列传给 TRY_CONVERT，并指定目标类型为 DATE、DATETIME 或 DATETIME2。常见用法如下：
- 基础写法：
TRY_CONVERT(DATE, your_column) - 带样式参数（处理不同格式字符串）：
TRY_CONVERT(DATE, your_column, 120)（对应 'yyyy-mm-dd hh:mi:ss'） - 配合
ISNULL或COALESCE提供默认值：ISNULL(TRY_CONVERT(DATE, your_column), '1900-01-01') - 在
WHERE中过滤有效日期：WHERE TRY_CONVERT(DATE, your_column) IS NOT NULL
注意：样式参数只对 CHAR/VARCHAR 输入生效；如果输入是 INT 或 NULL，样式会被忽略。
哪些场景下 TRY_CONVERT 仍会“静默失败”
它不报错，但不代表结果符合预期。容易被忽略的坑有：
- 输入是空字符串
''→ 返回NULL（不是 '1900-01-01'） - 输入含多余空格或不可见字符（如制表符）→ 转换失败，返回
NULL，需先TRIM() - 输入是合法数字（如
20230101）→TRY_CONVERT(DATE, '20230101')成功，但TRY_CONVERT(DATE, 20230101)失败（整数不支持隐式样式解析） - 使用
DATETIME类型时，秒以下精度会被截断，且范围限于 1753–9999 年；推荐优先用DATETIME2(3)
和 ISDATE() 搭配使用的实际意义不大
ISDATE() 判断的是“能否被解释为日期”，但它和 CONVERT 的规则不完全一致，尤其对模糊格式（如 '01/02/03'）或带时区偏移的字符串，返回结果可能误导。更可靠的做法是直接用 TRY_CONVERT 并检查是否为 NULL：
SELECT
input_str,
TRY_CONVERT(DATE, TRIM(input_str)) AS safe_date
FROM (VALUES ('2023-02-30'), (' 2023-01-01 '), ('')) t(input_str);
真正要警惕的，是把 TRY_CONVERT 当作万能清洗函数——它不修正数据，只帮你跳过错误。原始脏数据还在那儿，只是没炸开而已。
