ISDATE()不可靠，因它仅判断字符串能否被SQL Server内部解析为日期时间类型，而非语义合法；应优先用TRY_CAST(@input AS DATE) IS NOT NULL，该方式能同时校验格式可解析与日历合法性，且行为稳定不依赖语言设置。
SQL Server 中没有通用的 ISDATE() 安全替代方案，直接用 ISDATE() 判断日期有效性极不可靠，应优先改用 TRY_CAST() 或 TRY_CONVERT()。
为什么 ISDATE() 会误判
ISDATE() 的设计目标是“能否被 SQL Server 内部解析为日期时间类型”，而非“是否符合用户预期的合法日期格式”。它对很多明显非法输入返回 1：
-
ISDATE('2023-02-30')→ 1（二月三十日被接受，后续CAST会失败） -
ISDATE('31/13/2023')→ 1（月份 13 被忽略或绕过校验） -
ISDATE('2023-00-01')→ 1（月份为 0，部分版本仍返回真） - 依赖当前
DATEFORMAT和语言设置，结果不稳定
TRY_CAST() 是更安全的替代方案
TRY_CAST() 在转换失败时返回 NULL，成功则返回目标类型值——这意味着它同时完成「格式可解析」+「语义合法」双重校验：
-
TRY_CAST('2023-02-30' AS DATE)→NULL（二月三十日不合法） -
TRY_CAST('31/13/2023' AS DATE)→NULL（月份超出范围） -
TRY_CAST('2023-12-25' AS DATE)→2023-12-25（合法） - 不随会话语言或
DATEFORMAT变化，行为确定
判断是否为有效日期，只需写：TRY_CAST(@input AS DATE) IS NOT NULL。
注意 TRY_CAST() 的隐式截断和精度问题
TRY_CAST() 对字符串长度、格式宽松度有隐含规则，需结合使用场景验证：
-
TRY_CAST('2023' AS DATE)→NULL（纯年份不接受） -
TRY_CAST('2023-01' AS DATE)→NULL（年月格式不接受，需完整 Y-M-D） -
TRY_CAST('2023-01-01 12:34:56.789' AS DATE)→2023-01-01（时间部分被丢弃，但转换成功） - 若需严格匹配某种格式（如只接受
YYYY-MM-DD），得额外加LEN()和LIKE检查，TRY_CAST()本身不负责格式约束
兼容旧版本 SQL Server（2012 以下）怎么办
SQL Server 2012 之前没有 TRY_CAST()，只能退回到 CASE WHEN ... ELSE + ISDATE() + TRY...CATCH 包裹 CAST，但代价高、不可内联、无法用于计算列或索引表达式。强烈建议：
- 升级到 SQL Server 2012 或更高版本
- 若无法升级，至少封装成标量函数并缓存结果，避免在大表查询中反复调用
- 不要在 WHERE 条件中直接嵌套
ISDATE()做过滤——它可能让优化器放弃索引
真正棘手的点不在语法，而在你是否意识到：日期有效性 ≠ 字符串能被解析。哪怕一个看似简单的 ISDATE() 调用，也可能在生产环境悄悄放过非法数据，直到下游报表或导出时报错。
