Python判断输入是否是数字：四种方法、边界与选型

数字校验这件事很多人在写第一行业务代码时就撞上了表单里用户填了个“12.5.3”后端int()直接抛异常接口 500配置中心里某个值写成了INF校验居然放行结果算出来的价格是无穷大。Python 判断输入是否是数字看似一句话的事实际藏着字符集、进制、符号位、科学计数法、Unicode 数字、浮点边界这一连串深坑。我做过不少数据录入、命令行工具和配置解析的活儿isdigit、isdecimal、isnumeric、try/except、正则、手写状态机这几套方案来来回回用了很多次也踩过每一种的雷。这篇就把“Python 判断输入是否是数字”的四种主流方法彻底拆开讲从它们的底层判定逻辑讲到适用边界再配上可直接抄走的代码和一张横向选型表。不管你是刚学 Python 练手还是要给线上接口加一层输入校验看完都能对号入座找到合适的那一种并且知道为什么不该用另外几种。1. 先想清楚数字到底指什么再谈方法选型1.1 一个需求背后的三种语义“判断输入是否是数字”这句话本身是有歧义的。我遇到过同一段代码被三个不同的人提出三种期待的情况运营希望用户填“1,200”也算合法金额输入算法同事希望“1e-5”能被识别而数据库同事坚决认为只有纯整数才算合格的主键。这三种期待对应的是三种完全不同的语义如果不先拆清楚选哪种方法都是错的。第一种是字符形态语义这段字符长得像不像数字。它只关心字符本身不管能不能参与运算。全角在形态上确实是数字½也是。str的is*系列方法走的就是这条路。第二种是可解析语义这段字符能不能被转换成程序里的数值对象。1e5算不上“长得像数字”但它能被float()解析成 100000.0。½长得像数字可float()拿它没办法。try/except和Decimal走的是这条路。第三种是业务口径语义在你的业务里什么样的写法算合法。比如订单金额不允许负数、不允许科学计数法、最多两位小数。这类需求只有正则表达式和手写状态机能精确表达因为规则是你自己定的。选方法之前先回答一个问题**这段字符串拿到手之后要干什么**是直接参与算术运算还是只是存进数据库当字符串还是仅用于日志分类统计目的不同答案完全不同。1.2 最容易被忽略的一个前置动作去空白不管最后选哪种方案有一个动作我建议放在最前面做——去掉首尾空白。raw 12.5 s raw.strip()原因很实在。 12 .isdecimal()返回False但int( 12 )却返回12。也就是说如果你用isdecimal()做前置校验挡住了带空格的值后面的int()其实根本用不上反过来如果你依赖int()去容错那你的校验逻辑和转换逻辑就是两套口径早晚会打架。我踩过一次典型的坑某次数据导入脚本里先用s.isdigit()过滤掉不合法行再int(s)转换。结果一份 Excel 导出的 CSV 里数字列全带前导空格isdigit()全军覆没脚本一行数据都没导进去日志里还一片安静——因为我是把不合法的行continue掉的。后来加了strip()问题立刻消失。提示strip()默认会去掉各类空白字符包括全角空格\u3000。但float()内部对 Unicode 空白的处理范围可能和你想象的略有出入所以显式strip()比依赖转换函数自己容错更可控。2. 方法一is 系列字符串方法最省事也最容易误判2.1 isdigit、isdecimal、isnumeric 到底差在哪Python 的str上有三个长得很像的方法isdigit()、isdecimal()、isnumeric()。很多教程一笔带过说“都能判断数字”实际上它们的判定范围是一个比一个宽的子集关系isdecimal ⊆ isdigit ⊆ isnumeric。我拿几个特殊字符实测过结果很能说明问题字符isdecimal()isdigit()isnumeric()int()能否转换7TrueTrueTrue可以全角TrueTrueTrue可以²上标 2FalseTrueTrue不可以½二分之一FalseFalseTrue不可以一汉字数字FalseFalseTrue不可以Ⅷ罗马数字FalseFalseTrue不可以-5FalseFalseFalse可以3.14FalseFalseFalse可以空串FalseFalseFalse不可以这张表里的信息量比任何文字解释都大。isdecimal()只认“十进制数字字符”也就是能构成十进制数的那些码位isdigit()额外放行了上标、下标这类 digit 属性的字符isnumeric()则把分数、罗马数字、汉字数字全都收编了。注意看最后三行。这三个方法全都不认负号和小数点。原因很简单-和.根本不是数字字符它们是运算符和分隔符。所以任何带符号或小数的输入用is*系列判断必然失败。这是最经典的误用场景我在代码评审里见过太多次。2.2 为什么½.isnumeric()为 True 却不能运算这是个能让人懵很久的例子。½.isnumeric()返回True但float(½)直接ValueErrorint(½)同样报错。也就是说isnumeric()告诉你“它是数字”但 Python 的数值转换器根本没法把它变成数。根子在 Unicode 的属性定义上。Unicode 给每个字符打了若干布尔属性其中Numeric_Type分为 Decimal、Digit、Numeric 三档。isdecimal()检查 Decimal 档isdigit()检查 Decimal 加 Digitisnumeric()检查全部三档。但int()和float()的解析器只认Decimal_Type那一档因为它必须是“位置记数法”的字符才能参与进制计算。罗马数字Ⅷ是一个整体符号没法拆成“8 个 1 加 1 个 5”的位置表示所以被排除在外。理解这一点之后选型逻辑就清楚了如果你的下一步动作是数值转换绝对不要用isnumeric()或isdigit()只能用isdecimal()或者干脆别用这一族。2.3 这一族方法真正合适的场景那is*系列是不是就没用了不是。它在一种场景下非常顺手你已经确认输入不含符号和小数点只需要验证它是不是一串纯数字字符。典型例子是验证码、身份证号、手机号、银行流水号、订单编号这类定长纯数字串。这些字段在业务上本来就不允许负号和小数点用s.isdecimal()一行搞定可读性极好性能也是所有方案里最优的。def is_pure_digits(s: str) - bool: 只用于校验不含符号、小数点的纯数字串 return s.isdecimal()另外它还有一个反直觉的优势对空串返回False。正则如果写得不严谨r^\d*$会匹配空串isdecimal()天然免疫这个坑。所以如果你做的是批量过滤is*系列是很好的第一道筛子。3. 方法二try 加 float/int 转换工程上最常用的一招3.1 转换法的本质是以结果论英雄思路很直白能不能转成数值对象能转就是数字转不了就不是。这种先试后验的风格在 Python 里有个专门的名字叫 EAFPEasier to Ask for Forgiveness than Permission是社区里非常推荐的写法。def is_number_by_cast(s: str) - bool: try: float(s) return True except (TypeError, ValueError): return False为什么用float()而不是int()因为int(3.14)会抛ValueError。int()只接受纯整数形式的字符串连12.0都不行。你要覆盖整数加小数两种输入必须用float()。这是第二个高频误用点很多人写try: int(s)然后发现用户输3.14就报错还以为是用户输错了。float()能接受的输入比大多数人以为的宽。我列一下实测通过的写法12、-12、12、3.14、.5、5.、1e5、1E-5、 12 、1_000、全角、١٢٣阿拉伯-印度数字。3.2 三个必须知道的宽松点inf、nan、下划线float()的宽松是有代价的它放行了三个在业务上通常不该算数字的东西。第一个是无穷大。float(inf)、float(infinity)、float(-Infinity)全部合法返回inf。更隐蔽的是溢出float(1e400)不报错直接返回inf。我曾经在一个计算运费的模块里踩过这个坑某个渠道配置里写了个天文数字结果运费算出来是inf一路传到数据库才炸。第二个是nan。float(nan)合法返回nan而且nan ! nan恒为真意味着你后面写if value value之类的判空逻辑会完全失效。第三个是下划线分隔符。从 Python 3.6 开始支持数字字面量下划线float(1_000)返回1000.0int(1_000_000)返回1000000。这个特性对写代码很方便但作为用户输入的校验口径就太松了——用户不会没事敲下划线能出现下划线大概率是脏数据。所以生产环境里我通常会在转换法外面加一层显式排除import math def is_number_strict_float(s: str) - bool: if not isinstance(s, str): return False s s.strip() if not s or _ in s: return False try: v float(s) except ValueError: return False return math.isfinite(v) # 同时排除 inf 和 nanmath.isfinite()一次干掉inf、-inf、nan三类特殊情况比逐个math.isnan()加math.isinf()判断干净得多。3.3 想要小数精度就把 float 换成 Decimalfloat是二进制浮点0.1 0.2 ! 0.3这个经典问题在金额场景里是致命的。如果这个输入后续要参与钱的计算校验阶段就该用Decimal而不是float。from decimal import Decimal, InvalidOperation def is_number_decimal(s: str) - bool: s s.strip() if not s or _ in s: return False try: v Decimal(s) except InvalidOperation: return False return v.is_finite()Decimal的异常类型是InvalidOperation不是ValueError这点和float()不同写except ValueError是接不住的。而且Decimal(nan)、Decimal(Infinity)同样合法必须靠is_finite()拦住。Decimal的解析口径比float更严一些Decimal(1e400)不会变成inf而是老老实实给你一个巨大的数。在金额、税率、汇率这类场景这个差别就是事故和正常的差别。4. 方法三正则表达式校验口径由你自己定4.1 一条覆盖符号、小数、科学计数法的式子当业务规则明确到允许负号、允许小数、允许科学计数法、不允许前导空格这种程度时正则是最直接的表达方式。import re # 允许可选正负号整数部分 可选小数部分或纯小数部分可选指数部分 NUM_PATTERN re.compile(r[-]?(?:\d(?:\.\d*)?|\.\d)(?:[eE][-]?\d)?, re.ASCII) def is_number_regex(s: str) - bool: return NUM_PATTERN.fullmatch(s) is not None拆开看这条式子的每一段[-]?— 可选的一个正负号注意是?不是*不允许--5这种。(?:\d(?:\.\d*)?|\.\d)— 主体分两支。前一支是至少一位数字可选小数点加任意位数覆盖12、12.、12.5后一支是点打头加至少一位数字覆盖.5。(?:[eE][-]?\d)?— 可选的指数部分1e5、1E-5、1e5都能过。re.ASCII这个标志很关键。Python 3 的str正则里\d默认匹配 Unicode 十进制数字也就是说能被\d匹配上。加上re.ASCII之后\d退化为[0-9]只认半角。需不需要加取决于你的业务接不接受全角输入。做后台管理系统我一般不加用户从中文输入法切过来很容易打出全角做接口参数校验我一般加上因为前后端约定就是半角。4.2 用 fullmatch 而不是 match 或 search这是个非常容易翻车的细节。re.match只从字符串开头匹配不要求匹配到结尾。re.match(r\d, 12abc)是能匹配成功的返回的Match对象是真的但12abc显然不是数字。正确做法是用fullmatch它要求整个字符串都被模式吃掉。Python 3.4 之后就有这个方法了比在模式里手写^...$更不容易出错$有个小毛病它能匹配末尾换行之前的位置12\n在某些模式写法下会被误判。如果非要兼容老写法用match请务必在模式两端加上\Z而不是$NUM_PATTERN_OLD re.compile(r[-]?(?:\d(?:\.\d*)?|\.\d)(?:[eE][-]?\d)?\Z, re.ASCII)\Z是严格匹配字符串末尾不给换行留后门。这个差别在处理从文件读进来的行时特别重要因为readlines()保留的每行末尾都带\n。4.3 几种常见业务口径的正则速查实际项目里几乎不会用到上面那条完整的式子更多时候是各种收窄版本。我把常用的几条整理成表直接拿去改就行业务口径正则说明正整数[1-9]\d*不允许 0 开头不允许 0 本身非负整数含 0(?:0|[1-9]\d*)拦住007这种写法最多两位小数的金额-?\d(?:\.\d{1,2})?常用于订单、账单必带两位小数的金额-?\d\.\d{2}报表、对账场景百分比 0 到 100(?:100(?:\.0{1,2})?|(?:\d{1,2})(?:\.\d{1,2})? )注意去掉末尾空格后再用身份证号18 位\d{17}[\dXx]最后一位可能是 X手机号11 位1[3-9]\d{9}半角数字那张表里百分比那条我故意留了个空格提醒你实际写的时候要去掉。这类正则我一个一个在调试器里试过别看只有几个字符0和00的区别、.5和0.5的区别每一个都能让线上出问题。正则在四种方法里是可控性最强的一个规则怎么定完全由你说了算而且和前端、文档、接口协议之间可以直接对齐同一份规则文本。缺点是模式一复杂可读性就崩接手的人得盯着看半天。5. 方法四手写逐字符状态机可控性最强也最啰嗦5.1 为什么不直接用正则还要自己写正则好用但有两个实际问题一是超长正则在某些输入下可能出现灾难性回溯写得不严谨的时候二是模式的可读性对团队不友好改一个字符都可能影响全局。手写状态机的思路是从左到右扫一遍字符用一个状态变量记录我现在走到哪一步了每碰到一个字符就转移一次状态。写出来比正则长但每一步都赤裸裸摆在代码里谁都能读懂改起来也不会误伤别处。def is_number_fsm(s: str) - bool: 手写状态机允许正负号、小数、科学计数法不允许空白 if not s: return False i, n 0, len(s) # 1. 处理符号位 if s[i] in -: i 1 if i n: return False # 2. 整数部分 int_digits 0 while i n and s[i].isdigit(): int_digits 1 i 1 # 3. 小数部分 frac_digits 0 if i n and s[i] .: i 1 while i n and s[i].isdigit(): frac_digits 1 i 1 # 整数和小数部分至少要有一个数字 if int_digits 0 and frac_digits 0: return False # 4. 指数部分 if i n and s[i] in eE: i 1 if i n and s[i] in -: i 1 exp_digits 0 while i n and s[i].isdigit(): exp_digits 1 i 1 if exp_digits 0: return False # 5. 必须全部消费完 return i n这段代码的核心是最后那个return i n。它等价于正则里的fullmatch确保没有多余字符被漏掉。很多人手写的时候忘了这句结果12abc也能过。5.2 状态机最容易漏的三处判定上面对着写出来的代码有三处我一开始都写错过值得单独点出来第一处if i n: return False这个符号位之后的检查。如果只写符号而没有数字比如输入是-或者符号位吃掉了唯一一个字符i就等于n了。后面循环全都不进int_digits和frac_digits都是 0虽然最终会被int_digits 0 and frac_digits 0拦住但显式加一句更清晰也避免后续扩展时出错。第二处整数部分和小数部分的至少有一个是or不是and。写成and的话.5整数位 0 个和12.小数位 0 个都会被拒绝但这两个在float()那里都是合法的。用or才能对上float的口径。第三处指数部分后面必须至少跟一位数字。1e和1e都是不合法的靠exp_digits 0拦住。5.3 我实测下来的一个小优化纯手写状态机在处理大量输入时瓶颈往往在s[i].isdigit()这个调用上——它是 Unicode 感知的比直接比较 ASCII 码范围慢。如果你的输入确定只可能是半角数字把它换成0 s[i] 9能快一截。我在一个解析百万行日志的小工具上做过对比切过去之后整体耗时降了大概两成。当然这种优化要建立在输入来源可控的前提下如果用户输入的可能是全角数字换了反而会漏判。6. 四种方法横向对比怎么选不出错6.1 三维对比表把四种方法放在一起从严格度、可读性、性能三个维度拉一张表选型时对着看就行方法严格度可读性相对性能能否识别负数与小数典型适用场景isdecimal()只认十进制数字字符高最高否纯数字串、编号、验证码try float()宽松放行 inf/nan/下划线高中等异常路径慢是通用输入校验try Decimal()中等精度可控中中偏低是金额、汇率、税率正则fullmatch完全自定义中模式简单时高预编译后是业务规则明确、需对外对齐口径手写状态机完全自定义中高是需精细控制、不想依赖正则性能这块补充一点观察isdecimal()因为直接在 C 层做字符属性查表绝对是第一梯队预编译的正则紧随其后差距大概在一个数量级以内try float()在成功路径上其实不慢但失败路径要走异常栈回溯代价明显如果你的场景里绝大部分输入都是非法值比如过滤海量脏数据用异常做流程控制会让整体耗时涨上去。这种时候先用isdecimal()或正则做初筛再对初筛通过的做转换是更稳的组合拳。6.2 我实际项目里的选型习惯说几个真实场景下我会怎么选比抽象规则好用。场景一命令行工具读用户输入。我会用try float()并且专门处理KeyboardInterrupt别让它被except Exception吞掉。while True: raw input(请输入一个数字) try: value float(raw) if not math.isfinite(value): print(请输入有限的数值) continue break except ValueError: print(这不是一个合法的数字请重试)注意这里我直接用input()的返回值做转换而不是先校验再转换。省掉一次重复判断也避免了两套口径不一致。场景二Web 接口的 JSON 参数校验。这类场景通常有明确的契约文档我会用正则并且把模式定义成模块级常量让文档和代码能对得上。接口参数要求“最多两位小数的正数”那就一条^\d(\.\d{1,2})?$多余的一律 400。场景三Excel、CSV 批量入库。这种场景数据量可能几十万行而且脏数据比例高我会用组合方案def normalize_number(cell) - float | None: if cell is None: return None if isinstance(cell, (int, float)): return float(cell) if math.isfinite(cell) else None s str(cell).strip().replace(,, ) # 顺手去掉千分位 if not s: return None try: v float(s) except ValueError: return None return v if math.isfinite(v) else None开头那个isinstance判断不能省。很多表格库在读取纯数字单元格时直接给你float或int对象不是字符串这时候再去.strip()就 AttributeError 了。这个坑我在两个不同的项目里各踩过一次。7. 输入校验里真正会咬人的几个边界7.1 全角字符与不可见空白中文输入法下打出来的数字是全角的。这种输入在后台管理系统里极其常见尤其是年龄、数量这类小字段。好消息是int()和float()都能处理全角十进制数字int()返回123。坏消息是isdecimal()对全角返回True但很多人不加re.ASCII的正则也会放行它而前端传给后端时如果中间有编码转换可能就变成乱码了。另一种更隐蔽的是不可见字符。从某些系统复制粘贴过来的数字末尾可能带着零宽空格\u200bstrip()是去不掉它的strip()只处理空白字符零宽空格不算空白。这种情况下float()也会失败报错信息还特别迷惑因为打印出来看着完全正常。处理办法是在清洗阶段显式替换掉这些字符_INVISIBLE dict.fromkeys(map(ord, \u200b\u200c\u200d\ufeff), None) def clean_input(s: str) - str: return s.translate(_INVISIBLE).strip()dict.fromkeys加str.translate是批量删除指定字符最快的写法比连着写好几个replace清晰。7.2 千分位、货币符号和括号负数业务数据里经常出现1,234.56、888、(500)这几种写法。最后那个括号是财务里表示负数的常见约定(500)意思是 -500。标准的转换函数一个都吃不下去。我的处理习惯是先做规整再做校验两步分开写别糅在一起def normalize_money(s: str) - str: s s.strip() neg False if s.startswith(() and s.endswith()): neg, s True, s[1:-1] s s.replace(,, ).replace(, ).replace(, ).replace($, ).strip() return (- s) if neg else s规整完之后再走Decimal转换。这样做的好处是如果规整后的结果还是转不了你能明确知道是数据格式有问题而不是被一个混合的逻辑绕晕。另外要注意中文逗号和半角逗号,都要处理我见过从 Word 文档复制出来的表格里混着中文标点。注意千分位剔除只能做在“确认是金额字段”的场景。如果是编号类字段把逗号去掉可能把两条不同记录混成一条那问题就大了。7.3 浮点边界看起来是数字但算出来不对还有一种“假数字”值得单独说。0.1 0.2在 Python 里不等于0.3这不是 bug 是二进制浮点的固有特性。如果用户输入的是0.1和0.2你把它们转成float相加再和用户输入的0.3比较结果是False。这个坑和“判断是否数字”看起来无关实际上是同一个流程里紧挨着的两步。我的建议是只要涉及金额、比例、税额这类需要精确比较的输入从校验到存储全程用Decimal不要让float掺进来。比较的时候用Decimal(0.1) Decimal(0.2) Decimal(0.3)返回True。对应的校验函数也换成Decimal版本前面 3.3 节给过代码。多写这几行能省掉后面无数的对账麻烦。最后再分享一个我在代码评审里常用的检查清单看到“判断是不是数字”的代码时我会依次问四个问题输入有没有先strip()inf和nan挡住了没有校验和转换是不是同一套口径负数和小数点考虑到了没有这四个问题问下来八成的问题能在上线前抓住。