又是这个报错。相信很多做数据分析的同学都撞见过明明只是想把一列浮点数字转成整数结果astype(int)一执行pandas 直接甩出一句IntCastingNaNError: Cannot convert non-finite values (NA or inf) to integer。遇到这个报错的第一反应往往是“我的数据哪脏了”但真正的问题是整数类型和 NaN、inf 之间的关系远比你想象的更严格。这个报错本质上是 pandas 在保护你——它拒绝把一个没法用整数表示的值硬塞进整数类型里。我最早在 pandas 0.24 上跑旧代码时这个操作还只是给个 FutureWarning升级到 pandas 1.0 之后直接变成硬报错当时确实让不少线上管道直接崩了。这篇文章我会从根因、触发场景、五种解法到生产环境工程化习惯把这条报错彻底拆干净。不管你是刚接触 pandas 的新手还是被线上任务搞到头大的老手都有可以直接抄作业的代码。1. 报错现场与根因拆解为什么int装不下NaN和inf1.1 三步复现IntCastingNaNError的典型代码这个报错最经典的触发方式就是把含“洞”的浮点列直接转整数。写个最小复现import pandas as pd import numpy as np df pd.DataFrame({ price: [19.9, 20.0, float(nan), 21.5] }) df[price].astype(int)在 pandas 1.0 及以上的版本里最后一行会直接抛出IntCastingNaNError: Cannot convert non-finite values (NA or inf) to integer注意这里的报错信息把两类值并列在了一一起NA和inf。也就是说不仅仅是空值哪怕是float(inf)或float(-inf)这种无穷大值同样会被拦截。你可以在同一列里混入几个无穷大试试df2 pd.DataFrame({v: [1.0, np.inf, -np.inf, 2.0]}) df2[v].astype(int)结果一模一样照样炸。理解了这一点排查方向就不是“某一列有 NaN”而是“这一列里有没有任何非有限值”。1.2 整数类型为什么天生拒绝“缺失值”和“无穷大”这里要稍微讲点底层原理理解之后你会觉得这个报错其实特别合理。整数类型在计算机里是固定位数的比如int64就是 64 个比特位每个位模式都对应一个整数。它没有为“缺失”“无穷大”这样的状态预留任何位模式。而 NaN 和 inf 都是浮点数规范IEEE 754里的特殊值用某几组特定位表示只有浮点类型能承载它们。打个比方int 就像一列编好号的储物柜每个柜子必须放进一个具体物品你不能在一个柜子里贴个“这里什么也没有”inf 相当于一个柜门永远关不上、无限大的空间同样没法放进去。所以 pandas 不是不让你转而是它真的不知道该怎么把一个“不存在”或“无限大”的东西映射成一个整数。如果你非要用旧版行为在 pandas 0.24 以前astype(int)遇到 NaN 时可能会得到非常离谱的未定义值旧版本里甚至会出现负数、随机大数这种静默错误比报错更危险。所以从 pandas 1.0 开始社区索性把这个默认行为改成显式报错逼你先处理非有限值——长期来看这是帮你不是坑你。2. 先别急着修定位NA与inf是被谁带进来的2.1 文件导入时漏网的缺失值绝大多数时候NaN 不是你手动制造的而是数据文件本身就有“洞”。最常见的是read_csv时遇到空字段、NA、null、N/A这类标记pandas 会默认把它们解析成NaN。df pd.read_csv(sales.csv) print(df.dtypes)你看到price列是float64很可能就是因为里面有缺失值。如果原来文件里的价格都是整数格式pandas 碰到缺失值后只能把整列抬升成浮点类型这本身就是一条线索。此时先别急着转换先看缺失到底有多严重df[price].isna().sum() df[price].isna().mean()缺失占比超过 50% 的列后续转换策略和缺失占比不到 1% 的列完全不是一个处理思路。2.2 merge、groupby、算术运算中“凭空出现”的inf第二种坑更隐蔽——原始数据里根本没有 NaN是你在处理过程中制造出来的。举几个常遇到的场景用df1.merge(df2, onid, howleft)时右表没有对应键结果列就变成 NaN。计算转化率、点击率这类比率时分母为 0click / view直接得到inf。对数据做np.log(0)、np.sqrt(-1)前者产生-inf后者产生 NaN。groupby 聚合后某些分组没有数据聚合列也可能是 NaN。我踩过印象最深的一次是两张表按用户 ID 左连接因为 ID 在右表里重复了多次产生了多对多膨胀空值区域一下子多出一大片。当时我没查 merge 后的行数直接去转 int被IntCastingNaNError卡住后才发现源头的 join 逻辑就有问题。2.3 三行代码快速定位异常行不管数据是怎么脏的修复前先准确查出异常行我通常用下面这三行num_col pd.to_numeric(df[target], errorscoerce) bad_mask num_col.isna() | num_col.isin([np.inf, -np.inf]) df.loc[bad_mask]如果列里本身是数字类型直接bad_mask df[target].isna() | df[target].isin([np.inf, -np.inf]) df.loc[bad_mask]然后把bad_mask导出到 CSV 或直接打印前几十行肉眼看看到底是文件里的空值、除零产生的 inf还是某些异常文本变成的 NaN。这个定位过程一定要做因为不同的产生路径对应完全不同的修复方案直接在数据末尾 fillna 只是治标。我用一个速查表总结异常值来源与特点排查时照着看异常来源典型值出现场景特征文件导入NaNCSV/Excel 空单元格、NA 标记集中在导入列数量与原始文件一致join / mergeNaN左连接或右连接无匹配新增列出现整块缺失除法、对数inf / -infa / b时 b0、log(0)数值明显异常分布可能有规律字符串转换NaNto_numeric(errorscoerce)原本看起来像数字的列部分行无法解析3. 五套方案实操选型从fillna到可空Int643.1 方案Afillna填充后转int适合缺失占比低最直觉的解决方案是把缺失值填成一个具体的整数再执行转换。df[price] df[price].fillna(0).astype(int)这段代码能跑通但隐藏风险非常大——如果业务上“0”和“缺失”含义不同比如价格缺失不等于免费你用 0 一填充后续所有按价格聚合的统计都会被带偏。所以填什么值必须由业务语义决定不能图省事统一填 0。常见填法参考计数字段填 0 往往合理比如“购买次数”缺失可以理解为 0 次。ID、业务编码填 0 或 -1 都行只要确保和真实 ID 不冲突。连续型特征填中位数或均值适合后续喂给机器学习模型。时间序列字段用methodffill前向填充保留趋势信息。一个我常用的组合是先替换 inf 再 fillnadf[price] ( df[price] .replace([np.inf, -np.inf], np.nan) .fillna(0) .astype(int) )这样一次性把非有限值和缺失值统一处理掉不会遗漏 inf。3.2 方案Bdropna直接删行简单但有代价如果缺失值占比很低比如不到 1%而且你并不需要保留那些行直接删掉是最干净的办法。df df.dropna(subset[price]).copy() df[price] df[price].astype(int)需要注意的是dropna之后一定要reset_index(dropTrue)否则行索引还带着原来的数值。另外如果这一列是下游表的主键或者关联键删行可能导致其他表的数据对不上这个方案就行不通。我一般只在两种场景下用 dropna一是临时探索数据追求快速二是缺失行数极少并且确认这些行对最终统计没有任何影响。3.3 方案Castype(Int64)保留NApandas的“可空整数”如果你既想要整数类型又舍不得丢缺失值pandas 很早就提供了可空整数类型Int64。注意这里是大写的I和 numpy 的int64小写不是同一个东西。df[price] df[price].astype(Int64) print(df[price].dtype) # Int64转换后原本的np.nan会变成pd.NA列类型是Int64你在数据里仍然能看到缺失值但类型已经是整数语义了。后续做sum()、mean()、value_counts()等操作时pandas 会默认跳过pd.NA不会像普通的float64那样把缺失值带进计算。如果你的数据是从各种来源拼接起来的可以先让 pandas 自动推断可空类型再根据需要微调df df.convert_dtypes() print(df.dtypes)convert_dtypes()会把合适的浮点列自动转成Int64把字符串列推断为string类型很多IntCastingNaNError问题在源头就被消除了。我个人在 pandas 1.x 时代就养成了 pipeline 开头先跑一次convert_dtypes()的习惯。3.4 方案D先清理inf再走方案A/B很多情况下数据的 NaN 其实并不多问题恰恰出在inf上。特别是统计完比率之后分母为零的行会顶着一个巨大的无穷大这时候直接fillna是不生效的因为inf不是空值。s pd.Series([1.0, np.inf, 2.0, np.nan]) s.fillna(0).astype(int) # IntCastingNaNErrorinf 还在正确姿势是先把 inf 替换成 NaN或直接替换成具体值clean_s s.replace([np.inf, -np.inf], np.nan) clean_s.fillna(0).astype(int)还有一种更省事的方式是按“有穷数”来筛选mask np.isfinite(s) s.loc[mask].astype(int)np.isfinite会同时筛掉 NaN 和 inf语义非常清晰。我习惯在排查阶段用这个函数因为它能一步定位出“所有非有限值”不用分别判断 isna 和 isinf。3.5 方案Eround/ceil/floor后转int浮点精度陷阱如果列里的数据本身都是整数只是因为浮点运算带上了小数点比如 49.99999999、3.00000001你可能会想先 round 再转。这个思路没错但有几个细节容易翻车。s pd.Series([49.999999, 3.0000001, 5.5]) s.round().astype(int)round()返回的还是浮点类型但只要结果都是有限值astype(int)就不会报错。这里要注意的是 Python 的银行家舍入round(5.5)结果是 6round(4.5)结果是 4和很多人以为的“四舍五入”不太一样。如果你需要严格四舍五入用import numpy as np s2 np.floor(s 0.5).astype(int)另外如果列里存在 NaN 或 infround()并不会把它们去掉所以方案 E 通常要配合方案 A/B/C 一起使用。3.6 一张表搞定方案对比与选型五种方案放到一起对比选型的时候直接看业务需求方案保留缺失值适用场景主要风险fillna astype(int)否缺失有明确业务含义能填具体值填错值会污染统计结果dropna astype(int)否缺失占比低删行不影响整体影响行数主键关联场景慎用astype(Int64)是不想丢缺失又要整数语义老版本pandas不支持清理inf后fillna/dropna视后续处理数据里有除零、对数产生的inf掩盖源头问题round/ceil后astype(int)否浮点精度噪声需要取整舍入规则与预期不一致方案没有绝对的优劣关键看你的下游是统计报表还是机器学习模型。如果是统计报表缺失值往往需要保留并在报表里体现优先用Int64如果是建模特征则需要填充或删除避免模型输入里有空值。4. 边界情况与坑位合集字符串、时间戳、超大值4.1 字符串列里的3.0和1,000astype(int)救不了还有一个常见的误解是只要是看起来像数字的列就能直接astype(int)。但字符串列里的3.0、1,000、12a直接转 int 会得到 ValueError而不是IntCastingNaNError。s pd.Series([3.0, 1,000, 12a]) s.astype(int) # ValueError: invalid literal for int() with base 10: 3.0正确做法是先用pd.to_numeric统一清洗num pd.to_numeric(s.str.replace(,, ), errorscoerce) print(num) # 0 3.0 # 1 1000.0 # 2 NaN得到的结果里可能又出现 NaN接下来再去走方案 A/B/C。这类问题最让人头疼的地方就是同一个字段在不同批次的数据里格式不一致比如这个月导出是1000下个月就变成1,000了。所以清理时一定要把replace(,, )这类操作写进 pipeline而不是只修一次。4.2 时间戳转int时NaT的污染处理日期列时NaT是“Not a Time”的缺失标记。如果你想把日期列转成整数时间戳比如从 1970 年开始的纳秒数格式类似ts pd.to_datetime(pd.Series([2023-06-01, None])) ts.astype(int64) # 可能得到异常极值或直接报错这里有个很麻烦的点NaT在底层是用int64的最小值-9223372036854775808来存储的你转成整数后如果没检查就会有一个巨大负数潜伏在数据里。后续做时间差计算、排序、画图都会被这个极值污染。我的处理习惯是先把时空值剔掉再转时间戳ts ts.dropna() timestamps ts.astype(int64) // 10**9 # 转成秒级时间戳如果一定要保留缺失行就把时间戳列和缺失标记列分开存比如加入一列is_missing不要把NaT硬塞进整数列。4.3 浮点49.999999round也可能骗你浮点数转整数时截断行为是很多人踩坑的重灾区。astype(int)对 3.99 的处理是直接截断成 3不是四舍五入成 4。而由于浮点表示误差你可能看到一个数“应该是 50”但实际上底层是 49.999999999。x 50.0 y 0.1 * 500 # 理论是50.0实际可能是50.0但也可能是49.999...如果你用int(x)去转很可能得到 49。所以需要取整的列我一般先用round()或np.rint()明确舍入意图再转整数df[count] df[count].round().astype(int)注意astype(int)本身不会帮你舍入它永远只做截断。这个细节在金融场景里尤其致命一分钱误差可能造成后续对账不平。4.4 int64溢出边界别把时间戳塞进32位最后一个边界问题是数值范围。np.int32能表示的范围是 -2147483648 到 2147483647如果你把时间戳纳秒级塞进去直接溢出即使没有 NaN 和 inf也可能得到完全错误的值。pandas 默认给astype(int)用的是平台相关的int64大多数场景够用但如果你显式指定np.int32就要多留个心眼。一个真实案例把毫秒级时间戳转np.int32结果出现了负数因为超出了表示范围。后来统一改成np.int64才正常。排查这类问题转完后看基本统计量是个好习惯df[ts].astype(int64).describe()如果 min 或 max 出现明显不符合业务常识的极值先怀疑溢出或 NaT 残留。5. 生产环境数据管道的工程化解法5.1 给每一列定“类型契约”让错误早点暴露临时脚本里报错修一下就行。但在生产管道里我建议不要等到astype(int)这一步才炸而是从入口就建立“类型契约”明确每一列的预期 dtype、是否允许缺失、取值边界在数据加载后立刻校验。最轻量的做法是自定义一个断言函数def assert_schema(df, col, allow_nanFalse, allow_infFalse): values df[col] if not allow_nan: assert not values.isna().any(), f{col} contains NaN if not allow_inf: assert np.isfinite(values.dropna()).all(), f{col} contains inf管道开头跑一遍断言哪个上游表出了问题立刻就能定位到具体列而不是等下游转 int 时才收到IntCastingNaNError。这比事后排查节省大量时间。想在更大规模的项目里做这件事pandera 这类库会更正式但小团队从函数断言开始就够了。5.2 内置一个safe_int_cast兜底函数我自己的项目里长期维护着一个万能转换函数虽然看起来简单但用它能统一处理绝大多数转 int 的异常情况代码里到处抄来抄去反而容易出错import pandas as pd import numpy as np def safe_int_cast(series: pd.Series, fill_valueNone) - pd.Series: # 第一步强制转数值非数值变成NaN numeric pd.to_numeric(series, errorscoerce) # 第二步统一把inf替换为NaN因为inf无法转整数 numeric numeric.replace([np.inf, -np.inf], np.nan) if fill_value is not None: # 有具体填充值时转成普通int64 return numeric.fillna(fill_value).astype(int64) # 不填充时保留缺失语义使用可空Int64 return numeric.astype(Int64)调用方式很灵活df[price] safe_int_cast(df[price], fill_value0) df[user_id] safe_int_cast(df[user_id]) # 保留NA转Int64这个函数融合了方案 A/C/D覆盖了字符串、NaN、inf 三类常见问题。需要注意如果series原本就是 datetime64 类型pd.to_numeric可能会报错所以日期列请单独处理。5.3 新旧pandas版本兼容的几个注意点最后聊一下版本兼容。我在生产环境见过不少老项目跑在 pandas 0.25 上代码写的是astype(int)升级到 pandas 1.0 之后立刻被IntCastingNaNError打爆。这其实是个好事因为原本的静默错误终于暴露了。如果你需要同时兼容老版本和新版本建议统一改用astype(Int64)和pd.to_numeric这两种写法在 pandas 0.25 里也能正常工作。另外注意convert_dtypes()在 pandas 1.0 引入2.x 更稳定老版本没有。pd.NA在 1.0 引入0.25 里没有用了会报错。DataFrame.replace([np.inf, -np.inf], np.nan)是老牌写法各版本都支持。最好在 requirements 里固定 pandas 版本并在 CI 里跑一个简单的 dtype 测试确保升级时不踩雷。类型转换这种事看起来是小问题但一旦进入生产环境一个非有限值可能让整张报表数据全部归零或偏移。回到最初的IntCastingNaNError。我个人用了很多年 pandas现在看到这个报错反而不慌了因为它横竖在告诉我数据里存在不该存在的非有限值。比起默默转错它选择大声喊出来这是 pandas 设计上的进步。每次遇到它我会先查数据来路再选转换方案最后回到源头把异常值规范掉。你要是在自己的数据管道里也撞上了按这篇文章的顺序排查一遍基本不会再被它卡住。