try_convert能避免日期转换报错是因为转换失败时返回null而非抛出错误，与convert直接中断执行不同；它适用于脏数据清洗和容错etl，需配合isnull或case兜底，并推荐显式指定样式码（如120）确保解析一致性。
TRY_CONVERT 为什么能避免日期转换报错？
因为 TRY_CONVERT 在转换失败时返回 NULL，而不是直接抛出错误——这和 CONVERT 的行为截然不同。CONVERT 遇到非法日期（比如 '2023-02-30' 或 'abc'）会中断执行并报错 Conversion failed when converting date and/or time from character string.，而 TRY_CONVERT 安静地返回 NULL，让后续逻辑可以继续处理。
它适合用在清洗脏数据、兼容多来源输入、或构建容错 ETL 流程中。
怎么写一个安全的日期解析查询？
核心是把原始字符串字段传给 TRY_CONVERT(DATE, ...)，再配合 ISNULL 或 CASE 做兜底。例如：
SELECT
raw_date,
TRY_CONVERT(DATE, raw_date) AS parsed_date,
ISNULL(TRY_CONVERT(DATE, raw_date), '1900-01-01') AS fallback_date
FROM (VALUES ('2023-10-15'), ('2023-02-30'), ('invalid'), (NULL)) t(raw_date);
注意几点：
-
TRY_CONVERT不接受任意格式：它依赖 SQL Server 的默认语言设置和隐式格式推断，对'15/10/2023'（DD/MM/YYYY）可能失败，除非会话DATEFORMAT设为dmy - 显式指定样式码更可靠，比如
TRY_CONVERT(DATE, '15/10/2023', 103)（103 = DD/MM/YYYY） - 输入为
NULL时，TRY_CONVERT也返回NULL，不是错误
常见失败场景和对应检查项
以下输入会让 TRY_CONVERT(DATE, ...) 返回 NULL，但容易被误认为“没生效”：
- 字符串含不可见字符（如
CHAR(13)、CHAR(10)）→ 先用RTRIM(LTRIM(...)) - 年份超范围（
'0001-01-01'到'9999-12-31'之外）→'10000-01-01'就不行 - 月份或日超出合法值（
'2023-13-01'、'2023-02-30'）→ 这类必须靠TRY_CONVERT捕获，ISDATE()已被标记为过时且行为不一致 - 使用了非标准分隔符（如
'2023.10.15'或'2023\10\15'）→TRY_CONVERT默认不识别，需先用REPLACE标准化
和 ISDATE()、CONVERT 的关键区别在哪？
ISDATE() 只返回布尔值，且对某些边缘输入（如 '2023-02-30'）可能返回 1（真），但后续 CONVERT 仍报错；TRY_CONVERT 是原子操作：一次调用完成判断+转换，结果可直接参与计算或过滤。
性能上，TRY_CONVERT 略慢于 CONVERT（因多了错误路径处理），但远好于先 ISDATE() 再 CONVERT 的两步写法——后者要扫描两次字段，还可能因并发修改导致判断与转换不一致。
真正容易被忽略的是：SQL Server 版本必须 ≥ 2012 才支持 TRY_CONVERT；如果环境是 2008 R2 或更早，只能用 TRY...CATCH 包裹 CONVERT，代价高得多。
