根本原因是运行时数据类型与操作预期严重错配，如object型数值列（含'1'、'2'等字符串）调用.sum()时抛typeerror；源头常在读取阶段未处理空格、单位、千分位等干扰，导致dtype未显式指定或预清洗，后续数值操作连锁失效。
Python数据分析管道因类型不一致崩溃，根本原因不是数据“看起来像数字”，而是运行时实际类型与操作预期严重错配——比如 pd.Series 某列表面全是数字字符串 '1'、'2'，但 dtype 是 object，后续调用 .sum() 或参与 numpy 计算时直接抛 TypeError，且错误堆栈常指向下游函数，掩盖了源头问题。
读取阶段就暴露隐式字符串型数值
CSV/Excel 文件中空格、单位符号（如 "12.5 kg"）、千分位逗号（"1,234"）会让 pandas.read_csv() 默认将整列识别为 object。不主动干预，后续所有数值操作都可能突然中断。
- 强制指定
dtype：对已知应为数值的列，显式传入{'price': 'float64', 'qty': 'int64'}，触发早期类型校验 - 启用
converters预处理：对含干扰字符的列，用 lambda 清洗后再转类型，例如converters={'weight': lambda x: float(x.replace('kg', '').strip())} - 避免依赖
infer_objects()：它只做浅层推断，无法修复混合类型列，且不改变原始 dtype
缺失值填充后 dtype 退化为 object
fillna() 对含 NaN 的数值列操作后，若填充值类型与原列不严格一致（如用字符串 'missing' 填充 float64 列），整列 dtype 会无声降级为 object，后续 .mean() 等方法失效。
- 数值列只用标量填充：
df['col'].fillna(0)或df['col'].fillna(df['col'].median())，保持 dtype 不变 - 必须填非数值时，先转换列类型：
df['col'] = df['col'].astype('string')再填'unknown'，明确接受字符串语义 - 检查 dtype 变化：在关键步骤后加
assert df['col'].dtype != 'object'，让问题在开发期暴露
concat / merge 后列类型自动合并导致意外 object
多个 DataFrame 合并时，若同名列在不同表中分别是 int64 和 float64，pd.concat() 会升格为 float64；但若一列为 int64、另一列为含字符串的 object，结果必为 object——此时数值计算彻底失效。
- 合并前统一类型：
df1['id'] = df1['id'].astype('Int64')（可空整型），df2['id'] = df2['id'].astype('Int64')，再 concat - 禁用自动类型推断：
pd.concat([df1, df2], ignore_index=True, join='inner', copy=False)，配合后续显式.astype() - 合并后立即验证：
for col in common_cols: assert pd.api.types.is_numeric_dtype(df[col]), f"{col} became object after merge"
最易被忽略的是：类型问题往往在数据源变更后才爆发——比如上游系统某天开始往原纯数字字段写入 'N/A'，而你的管道没做 schema 断言。预防的关键不是“修错”，是在每个 IO 边界点做 dtype 快照 + 断言，把类型契约当成接口协议来守。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
