清洗过程必须实时嵌套校验，不可跳过校验直接清洗后入库；每步清洗操作均需对应校验断言，如去重前检查重复量级、关键字段需唯一性+非空双校验，类型判断应使用 pd.api.types.is_String_dtype() 等健壮方法。
数据清洗该不该在入库前做校验
不该跳过校验直接清洗后入库。清洗和校验不是先后关系，而是嵌套动作：清洗过程本身必须实时触发校验逻辑，否则fillna()填了None进数值列、astype('int')强转含空字符串的列，都会在后续环节暴雷。
常见错误现象：ValueError: cannot convert Float NaN to Integer 或入库时数据库报 IntegrityError: NOT NULL constraint failed——这说明校验被推迟到了太晚的位置。
- 清洗每一步都要有对应校验断言，比如调用
drop_duplicates()前先用duplicated().sum()看重复量级 - 对关键字段（如用户ID、订单号）做唯一性+非空双校验，不能只依赖
df.dropna(subset=['user_id'])就认为安全 - 用
pd.api.types.is_string_dtype()替代str in str(type(x))判断类型，后者在 Nullable string 类型（stringdtype）下会误判
用 pandas 还是 polars 做清洗校验
小到中等规模（pandas 更稳；纯大批量 ETL 流水线、且校验规则简单固定（如字段长度、正则匹配、枚举值检查），polars 启动快、内存低、链式操作不易出错。
性能影响明显：同样做一列手机号格式校验，polars 用 .str.contains(r'^1[3-9]d{9}$') 比 pandas 的 .str.match() 快 3–5 倍，但 polars 不支持 inplace=True 风格修改，所有操作返回新对象，容易误写成 df = df.with_columns(...); df = df.filter(...) 导致中间 DataFrame 残留内存。
立即学习“Python免费学习笔记（深入）”；
-
pandas适合边查边改：比如发现某列缺失率超 60%，立刻用df[col].value_counts(dropna=False)探查分布再决定 drop 还是 impute -
polars适合声明式校验：用.with_columns(pl.col('phone').str.contains(...).alias('phone_valid'))一次性加标记列，再统一filter() - 别混用：
polars.DataFrame.to_pandas()转换开销大，校验阶段就定好引擎，中途不切换
空值、NaN、None、pd.NA 怎么统一处理
它们不是一回事，强行用 df.fillna(0) 会把本该报错的语义错误掩盖掉。比如 pd.NA 出现在整数列，说明该列已启用 nullable integer（Int64 dtype），此时填 0 是业务逻辑篡改；而 np.nan 在 object 列里可能是字符串“nan”，不是真缺失。
正确做法是分层处理：先用 df.isna() 找出所有缺失标识位，再按 dtype 分流处理：
- 数值列（
float64,Int64）：用df.select(pl.col(pl.NUMERIC_DTYPES).is_null())（polars）或df.select_dtypes(include='number').isna()（pandas）单独捞 - 字符串列（
string或object）：先.str.strip().replace('', pd.NA)清理空白，再isna()，避免把空格当有效值 - 时间列（
datetime64[ns]）：pd.isna()可识别NaT，但df['dt'].dt.year遇NaT会直接报AttributeError，必须前置过滤
校验失败时该抛异常还是打日志再跳过
取决于下游是否能容忍脏数据。ETL 写入数仓宽表可打日志并加 _err_reason 标记列；但写入交易核心库（如订单主表）必须抛 ValidationError 中断流程，靠重试或人工介入修复。
容易踩的坑是用 try/except Exception 吞掉所有异常——这样连 MemoryError 都被当成数据问题处理，掩盖真实瓶颈。
- 定义明确的校验异常类，如
class SchemaMismatchError(ValueError): pass，便于上层区分捕获 - 日志里至少记录：出问题的
column、样本值（df[col].head(3).to_list()）、校验规则（如“应为 ISO8601 时间格式”） - 禁止在
apply()或map()里做校验并返回None：这会让整列 dtype 退化为object，后续数值计算全失效
校验逻辑越靠近原始数据源越可靠，比如在读 CSV 时用 pd.read_csv(..., dtype_backend='pyarrow') 提前暴露类型冲突，比清洗完再检查 df.dtypes 有用得多。但 pyarrow backend 对中文路径支持不稳定，这个点常被忽略。