pd.dataframe.dtypes 不够用，因其仅反映底层存储类型，无法识别 object 列混杂类型、int64 列含 nan（实为 int64）、时间列为字符串等业务语义问题；pandera 通过显式 schema 编码非空、范围、正则、唯一性等约束，并依赖 nullable 和 coerce 精准控制类型转换与空值逻辑。
为什么直接用 pd.DataFrame.dtypes 不够用？
因为类型检查只是校验的起点。比如 object 列可能是字符串、空值、甚至混入数字或字典；int64 列可能含 NaN（而 pandas 允许 int 列含 NaN，但底层其实是 Int64 nullable 类型）；时间列可能是字符串格式的“2023-01-01”而非 datetime64。Pandera 的价值在于把「业务约束」显式编码成 schema：非空、范围、正则匹配、唯一性、跨列关系等。
定义 schema 时必须显式声明 nullable 和 coerce
这是最常踩的坑——不设 nullable=False，Pandera 默认允许 NaN；不设 coerce=True，它不会尝试把字符串“123”转成整数，直接报错。实际中多数原始数据带缺失或类型混乱，建议默认打开 coerce，再用 nullable 控制语义约束：
-
pa.Column(pa.Int, nullable=False, coerce=True)→ 强制转 int，且不允许最终为 NaN -
pa.Column(pa.String, nullable=True, coerce=False)→ 不自动转类型，但允许空值 - 对日期列，用
pa.Column(pa.DateTime, coerce=True)比手动pd.to_datetime()更一致，失败会统一抛SchemaError
用 schema.validate() 而不是 schema(df) 做调试
schema(df) 是简写，但出错时只返回一个模糊的 SchemaError；而 schema.validate(df, lazy=True) 会收集所有错误，包括每列的缺失值数量、类型不匹配样本、正则不通过的具体字符串。调试阶段务必加 lazy=True：
try:
validated_df = schema.validate(df, lazy=True)
except pa.errors.SchemaErrors as exc:
print(exc.failure_cases) # 显示每一处违规的行号、列名、原因
注意：lazy=False（默认）遇到第一个错误就停，适合生产环境快速失败；lazy=True 适合开发期定位全量问题。
校验后 DataFrame 的 dtype 可能和原始不同
Pandera 在 coerce=True 下会调用 pandas 类型转换逻辑，结果 dtype 可能变化：比如原 object 列经 coerce=True + pa.Int 后变成 Int64（nullable int），而非 int64。这会影响后续计算（如 .sum() 对 Int64 列默认跳过 NaN，而 int64 含 NaN 会报错）。如果下游强依赖原始 dtype，得在 schema 里关掉 coerce，改用 pa.Check 手动验证后再 cast。
真正难的不是写 schema，而是决定哪些约束该由 Pandera 检查（如“手机号必须是 11 位数字”），哪些该交给业务逻辑处理（如“订单金额不能超过用户信用额度”）——后者涉及外部状态，Pandera 做不了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
