TRY_CONVERT比CONVERT更适合处理脏日期数据，因其解析失败时返回NULL而非报错中断；需显式指定style参数避免语言环境歧义，并可用COALESCE组合多格式尝试解析。
TRY_CONVERT 为什么比 CONVERT 更适合处理脏日期数据
当你面对用户输入、第三方接口或历史遗留数据时，日期字符串格式往往五花八门：可能是 '2023-13-01'、'02/30/2024'、'20231301'，甚至空格、中文年月日混杂。用 CONVERT 直接强转，SQL Server 会立刻抛出 Conversion failed when converting date and/or time from character string. 错误，整个查询中断。而 TRY_CONVERT 的设计目标就是“不崩溃”，它在无法解析时安静返回 NULL，把判断权交还给你。
哪些场景必须用 TRY_CONVERT 而不是 ISDATE + CONVERT 组合
ISDATE 看似能预检，但它有严重误导性：它对 '31/02/2023'、'2023-00-00' 甚至 'abc' 都可能返回 1（尤其在某些语言设置下），导致后续 CONVERT 还是报错。而 TRY_CONVERT 是真正按目标类型语义做解析的兜底方案。
- 你不能信任上游数据格式，且不允许查询失败
- 需要批量清洗表中
varchar类型的“疑似日期”列 - WHERE 条件里要过滤掉非法日期，但又不想用子查询嵌套
ISDATE - 配合
CASE WHEN做多路格式尝试（比如先试 120，再试 103，最后试 112）
常见错误写法与安全替代方案
直接写 TRY_CONVERT(date, MyDateCol) 看似省事，但隐含风险：它依赖当前会话的默认语言和日期格式规则。例如在英国语言环境下，'01/02/2023' 被解释为 1 Feb；在美国环境下则变成 2 Jan。显式指定 style 参数才能锁定行为。
- ❌ 错误：不指定 style，让 SQL Server 自行猜测
TRY_CONVERT(date, '01/02/2023') - ✅ 安全：明确告诉它这是 ISO 格式
TRY_CONVERT(date, '01/02/2023', 120)→ 失败（因不符合yyyy-mm-dd） - ✅ 安全：匹配实际输入格式
TRY_CONVERT(date, '01/02/2023', 101)→ 成功（美式）TRY_CONVERT(date, '01/02/2023', 103)→ 成功（英式） - ⚠️ 注意：
style参数只在expression是字符串时生效；若传入的是datetime类型值，style会被忽略
多格式兼容的实战写法（避免硬编码单一 style）
真实业务中，一个字段可能混着多种合法格式。与其写一堆 OR 条件，不如用嵌套 COALESCE + 多次 TRY_CONVERT 实现“尝试优先级”：
SELECT
COALESCE(
TRY_CONVERT(date, DateString, 120), -- 先试 ISO '2023-01-02'
TRY_CONVERT(date, DateString, 103), -- 再试 '02/01/2023'
TRY_CONVERT(date, DateString, 112), -- 再试 '20230102'
TRY_CONVERT(date, DateString, 101) -- 最后试 '01/02/2023'
) AS ParsedDate
FROM RawData;这个写法不会报错，且按顺序取第一个成功转换的结果。但要注意性能：每多一次 TRY_CONVERT 就多一次解析开销，千万级数据慎用；更优解是在 ETL 入库阶段就标准化格式，而非每次查询都现场解析。
最常被忽略的一点：即使用了 TRY_CONVERT，如果目标类型是 datetime2(0) 或 smalldatetime，而输入字符串带毫秒或超出精度范围，它仍可能返回 NULL —— 因为这属于语义不兼容，不是格式问题。这时候你需要先截断或归一化字符串，再转换。
