先用 TRY_CONVERT(date, 字段名) IS NULL 快速筛选转换失败的字符串型日期字段，再结合长度、空值、非法字符及年月日逻辑校验（如年份范围、月份1-12、闰年判断）排查脏数据，注意混杂格式需分类归一处理。
先用 TRY_CONVERT 快速筛出转换失败的行
直接执行 SELECT * FROM 表 WHERE TRY_CONVERT(date, 字段名) IS NULL，能立刻暴露所有无法转成日期的字符串。它不报错、不中断查询，返回 NULL 就代表转换失败——这是最轻量、最可靠的初筛方式。注意：字段必须是字符串类型（varchar/nvarchar），如果已经是 date 或 datetime 类型，TRY_CONVERT 永远不会返回 NULL，查不到任何结果。
检查常见脏数据模式：空值、长度异常、非法字符
转换失败往往不是格式“看起来像日期但不对”，而是根本不像日期。重点关注以下几类：
-
LEN(字段名) = 0或字段为NULL或纯空白（可用RTRIM(LTRIM(字段名)) = ''判断） - 长度明显不符：比如预期
YYYY-MM-DD（10位），却出现 8 位、12 位或 6 位（如'202507'） - 含非数字/非分隔符：中文字符（“年”“月”“日”）、全角符号（‘－’‘／’）、字母（
'2025-02-30abc'）、不可见控制字符
建议先按长度和是否为空过滤，再对剩余数据做深层校验，避免全表扫描性能损耗。
验证年月日逻辑有效性，不能只看字符串结构
字符串长得像日期，不代表是合法日期。比如 '2025-02-30'、'2025-13-01'、'1800-01-01' 都可能通过长度和分隔符检查，但实际无效。手动校验要点：
- 年份范围：通常限制在
SUBSTRING(字段名, 1, 4)BETWEEN '1900' AND '2100'（按业务调整） - 月份：用
SUBSTRING(字段名, 6, 2)判断是否在'01'到'12'之间（注意字段格式，YYYY/MM/DD和YYYY-MM-DD的起始位置不同） - 日期：需结合年份和月份判断天数上限（闰年、大小月），简单兜底可用
SUBSTRING(字段名, 9, 2)BETWEEN '01' AND '31'，但会漏掉'2025-02-30'这类错误
真正严谨的逻辑校验成本高，日常排查优先靠 TRY_CONVERT + 人工抽样确认。
别忽略 CONVERT 的 style 参数误用
显式调用 CONVERT(date, 字段名, style) 时，style 值必须与字符串格式严格匹配。常见踩坑点：
- 用
style = 120（对应yyyy-mm-dd hh:mi:ss）去转'2025/07/01'→ 报错 - 用
style = 103（dd/mm/yyyy）去转'2025-07-01'→ 可能误判为日/月/年，导致'2025-07-01'被当成 2025 年 1 月 7 日 - 没指定
style，依赖默认解析规则，受DATEFORMAT或登录语言影响，行为不稳定
安全做法：统一清洗为 YYYYMMDD 格式后，用 style = 112；或始终优先用 TRY_CONVERT，它内部自动适配多种标准格式，不用硬编码 style。
真正麻烦的不是单个错误格式，而是同一字段混杂多种格式（比如既有 '2025-07-01'，又有 '20250701'，还有 '01/07/2025'）。这种情况下，TRY_CONVERT 仍能工作，但后续清洗逻辑必须分支处理——先分类再归一，而不是指望一个 CONVERT 调用通吃。
