4. 日期格式解析失败：混合格式列清洗中断的定位与兼容处理

问题定位：混合日期格式导致解析中断

日期列中同时存在 2024-03-01、2024/03/02、03/03/2024、2024年3月4日 等写法时，若直接对整列调用单一格式解析器，解析器遇到第一个不匹配格式的记录就会抛出异常，导致后续记录全部未被处理。因此排障的第一步不是"换一个更聪明的解析器"，而是先定位中断点，确认中断前已处理多少行、中断行是什么格式、剩余行里还有哪些格式。

下面用一段可运行的 Python 代码复现该问题，并给出定位手段。示例数据为教学构造，用于演示混合格式的典型分布。

import pandas as pd

raw = pd.DataFrame({
    "order_id": [1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008],
    "order_date": [
        "2024-03-01", "2024/03/02", "03/03/2024", "2024年3月4日",
        "2024-03-05", "2024.03.06", "20240307", "2024-13-08",
    ],
})

# 单一格式解析：遇到不匹配即中断
def parse_strict(series, fmt="%Y-%m-%d"):
    out = []
    for idx, val in series.items():
        out.append(pd.to_datetime(val, format=fmt))  # 不匹配会抛 ValueError
    return pd.Series(out, index=series.index)

try:
    parse_strict(raw["order_date"])
except ValueError as e:
    print("解析中断：", e)

运行后会在第 2 行（2024/03/02）抛出 ValueError，说明严格格式解析在第一条异形记录处即失败。此时需要逐行探测每条记录能被哪些格式解析，从而得到"格式—记录"的对应关系，而不是盲目猜测。

格式识别与回退解析策略

核心思路是维护一个"候选格式列表"，对每条记录按顺序尝试，第一个成功的格式即为该记录的解析格式；全部失败则记为无法解析。这样既不会因单条异常中断整列，也能保留每条记录实际使用的格式，便于后续审计。

import pandas as pd

CANDIDATE_FORMATS = [
    "%Y-%m-%d",
    "%Y/%m/%d",
    "%m/%d/%Y",
    "%Y年%m月%d日",
    "%Y.%m.%d",
    "%Y%m%d",
]

def parse_with_fallback(value):
    """返回 (解析结果, 命中的格式)；全部失败返回 (pd.NaT, None)。"""
    if pd.isna(value):
        return pd.NaT, None
    text = str(value).strip()
    for fmt in CANDIDATE_FORMATS:
        try:
            return pd.to_datetime(text, format=fmt), fmt
        except (ValueError, TypeError):
            continue
    return pd.NaT, None

def clean_date_column(series):
    parsed, used_fmt = [], []
    for val in series:
        dt, fmt = parse_with_fallback(val)
        parsed.append(dt)
        used_fmt.append(fmt)
    result = pd.DataFrame({
        "order_date_raw": series.values,
        "order_date": parsed,
        "matched_format": used_fmt,
    })
    result["parse_ok"] = result["order_date"].notna()
    return result

cleaned = clean_date_column(raw["order_date"])
print(cleaned)
print("无法解析记录数：", (~cleaned["parse_ok"]).sum())
print("各格式命中数：\n", cleaned["matched_format"].value_counts(dropna=False))

预期输出中，order_id=1008 对应 2024-13-08，月份 13 超出合法范围，所有候选格式均失败，matched_format 为 None，parse_ok 为 False。其余 7 条分别命中各自格式。此时"无法解析记录数"为 1，与逐行探测结论一致。

失败记录的处理与验证

无法解析的记录不能直接丢弃，也不能静默填成当天日期。推荐做法是：保留原始字符串、标记失败原因、输出到独立清单供人工复核，并在清洗结果中把日期置为缺失（NaT），同时保证下游聚合使用统一口径。

failed = cleaned.loc[~cleaned["parse_ok"], ["order_date_raw"]].copy()
failed["reason"] = "所有候选格式均无法解析（疑似月份/日期越界或非法字符）"
print(failed)

# 验证：清洗后日期列应全部落在合理区间，且失败数与探测结果一致
assert cleaned["parse_ok"].sum() + len(failed) == len(cleaned)
valid = cleaned.loc[cleaned["parse_ok"], "order_date"]
assert valid.between("2024-01-01", "2024-12-31").all()
print("验证通过：可解析", len(valid), "条，失败", len(failed), "条")

验证要点有三：一是"成功数 + 失败数 = 总行数"，防止解析过程中丢行；二是成功解析的日期应落在业务合理区间内，用于发现"格式命中但语义错误"的隐性失败；三是失败清单必须可追溯到原始记录，便于业务方确认是数据录入错误还是格式遗漏。

可直接复用的检查清单