try_convert返回null而非报错，核心作用是静默失败防中断；对'2023-02-30'等非法日期按日历规则校验后返回null，不修复数据，仅保障查询继续执行。

TRY_CONVERT 直接返回 NULL 而不是报错，这是它唯一且核心的作用——它不修复数据，只防止查询中断。

为什么 TRY_CONVERT('2023-02-30' AS DATE) 返回 NULL 而不是报错

因为 TRY_CONVERT 的设计目标就是“静默失败”：只要输入无法被 SQL Server 认为是合法的日期（比如月份超出 1–12、日数超出该月实际天数、格式根本无法解析），它就返回 NULL，而不是抛出 Conversion failed when converting date and/or time from character string.。这和 CONVERT 的行为截然相反——后者遇到任何非法输入都会立刻终止执行。

注意：TRY_CONVERT(date, '2023-00-01', 120) 和 TRY_CONVERT(date, '2023-13-01', 120) 同样返回 NULL，这不是 bug，是它在按日历规则做真实校验；但 TRY_CONVERT(date, '2023-02-29', 120) 在非闰年也返回 NULL，这点必须心里有数。

WHERE 中用 TRY_CONVERT(date, col, 120) IS NOT NULL 是最常见也最安全的写法

清洗脏日期字段时，别写 WHERE TRY_CONVERT(date, col, 120) > '2020-01-01'——这会让索引失效，且语义模糊（NULL > ... 永远为 false，但你真正想筛的是“能转且合法且满足条件”的行）。

• 先用 IS NOT NULL 确保转换成功，再加其他条件：WHERE TRY_CONVERT(date, col, 120) IS NOT NULL AND TRY_CONVERT(date, col, 120) > '2020-01-01'
• 更高效的做法是前置粗筛：WHERE col LIKE '[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]'（配合长度和字符范围约束），再套 TRY_CONVERT(... IS NOT NULL)
• 如果字段长期存日期，别每次都调函数——建计算列 AS TRY_CONVERT(date, col, 120) 并加上索引，才是生产环境该走的路

补默认值或标记错误时，类型必须对齐

ISNULL(TRY_CONVERT(date, col, 120), '1900-01-01') 会报错，因为 ISNULL 要求两个参数类型一致，而字符串字面量和 date 不兼容。

• 用 COALESCE(TRY_CONVERT(date, col, 120), '1900-01-01') —— COALESCE 会推导公共类型，SQL Server 把 '1900-01-01' 自动升格为 date
• 想保留原字符串并加转换结果：SELECT col, TRY_CONVERT(date, col, 120) AS parsed_date FROM t，parsed_date 列天然可空
• 想分类标记：CASE WHEN TRY_CONVERT(date, col, 120) IS NULL THEN 'invalid_format_or_logic' ELSE 'valid' END

别指望 TRY_CONVERT 替你清洗数据，它只判断“能不能转”

它不会帮你去掉前后空格、替换 CHAR(9) 制表符、删掉 $ 或 kg 单位、处理 1,000 里的逗号。这些都得在调 TRY_CONVERT 前手动处理：

• 去空格：TRY_CONVERT(date, TRIM(col), 120)
• 去不可见字符：TRY_CONVERT(date, REPLACE(REPLACE(col, CHAR(9), ''), CHAR(13), ''), 120)
• 但别过度清洗——比如把 '25/03/2024' 强行替换成 '2024-03-25'，不如直接用 TRY_CONVERT(date, col, 103) 并接受语言设置影响，或统一要求源数据走 ISO 格式

真正容易被忽略的是：TRY_CONVERT 成功返回的 date 值，后续参与计算或比较时仍可能因 NULL 传播导致逻辑偏差——比如 SUM() 自动跳过 NULL，但 AVG() 也是，而 + 运算中任一操作数为 NULL 就全变成 NULL。这点比“不报错”本身更需要警惕。