1. 别急着写 if x is None先搞清楚“空”到底是什么写 Python 也写了十来年我见过太多新人在判空这件事上栽跟头。最典型的就是拿is None去判断一个空字符串结果程序跑起来死活不进那个分支最后 debug 半天发现是自己把“空”和None混为一谈了。在 Python 里空和None是两码事。None代表的是一个“什么都没有”的对象它是NoneType类型的唯一实例而字符串、列表、字典这些容器“为空”指的是它们里面没有元素长度为 0。这两者不能划等号。空字符串是一个合法的字符串对象只不过它的长度是 0空列表[]也是一个合法的列表对象只不过它不包含任何元素。所以你要判断“空”先得想清楚自己到底要判断哪一种情况。举个例子一个函数可能因为没找到结果而返回None也可能返回了一个空字符串。如果你笼统地用一个if not result去判断这两者都会被拦下来但如果你用if result is None空字符串就不会被拦下来。这看起来是细节但在实际业务里这两种情况的处理逻辑往往是不同的——前者可能意味着异常或未匹配后者可能意味着正常但没有任何内容。用错了判断方式代码的语义就差远了。还有一个特别容易踩的坑if not x会把None、空字符串、空列表、空字典、0、False全部当成 False 处理。这在大多数场景下很方便但也正因为太方便反而容易掩盖问题。比如你判断一个列表是否为空if not my_list没问题但如果你判断一个数字是否为 0if not num也没问题可它同时也会把None当成条件成立万一num是计算缺失传入的None你就把“未知”和“数值为 0”混在一起了。所以判空的第一步不是写代码而是先在脑子里想清楚我要判断的是“对象是否存在None”还是“容器里有没有内容长度/布尔值”想清楚了再选方法。2. 字符串判空从最简单的方法到那些隐蔽的坑2.1 直接用布尔值判断但要知道它背后的逻辑字符串判空最常用、也最简洁的方式就是直接把它放在条件里s if not s: print(字符串是空的) else: print(字符串非空)这段代码的底层逻辑是字符串对象实现了__bool__方法Python 会调用它来确定这个对象在布尔上下文中的值。空字符串的__bool__返回False非空字符串返回True。所以if not s在空字符串时成立在非空字符串时不成立。这个方法简单、直观而且性能也不错因为它内部拿到的是字符串的长度做判断不会做额外操作。但这里有一个非常经典的坑如果字符串里面是空白字符比如空格、制表符、换行符if not s判断出来的结果是“非空”。因为 的长度不是 0它包含一个空格字符。可很多时候我们业务上说的“空”是指用户没输入任何有效内容而不是用户输了一堆空格。我做过一个用户注册的表单校验用户名如果只输空格后端拿到的是 用if not username拦不下来结果数据库里存了一条全是空格的用户名。这就是典型的“字符串判空”没做彻底的场景。正确的做法是先去除首尾空白字符再做判断username username.strip() if not username: print(用户名为空)所以我的建议是在做字符串判空之前先明确你的业务是否需要把纯空白字符视为空。表单校验、文本搜索这类场景一定要先strip()再去判空而业务逻辑里明确区分“空字符串”和“空白字符串”的场景才保留原有的判断方式。2.2 len() 判空和“为什么我不推荐”用len(s) 0判断空字符串也是常见做法逻辑上没有错结果也和if not s一致。但在 Python 里我一般更推荐直接if not s。原因有二第一代码更简洁少一个函数调用读起来也直白。第二len()判断只是判断“长度是否为 0”它和if not s的结果完全等价既然等价就选读起来更舒服的写法。当然len()也有它的用武之地。比如你在写一个函数返回值可能是None也可能是字符串。这个时候len(s) 0在s为None时会抛TypeError而if not s不会。这个差异在合适的设计里是好东西——它逼着你先处理None的情况而不是让空字符串和None混在一起。实际项目里我遇到过这么一种情况一个接口返回的字段有时是字符串、有时是空字符串、有时干脆没有这个字段为None。这个时候如果我用if not field三种情况全当作“空”处理可能掩盖了“字段缺失”这种异常情况如果用if field is None又会漏掉空字符串。这种时候我会根据业务需要分开判断if field is None: # 字段缺失走异常处理或默认值 pass elif not field.strip(): # 字段存在但内容为空或纯空白走空值处理 pass else: # 字段有有效内容正常处理 pass这样虽然代码多几行但每个分支的语义都非常清晰不会留下模糊地带。在工程里模糊往往是 bug 的温床。判空看似简单但如果你不把“None”和“空”的语义区分开后面维护代码的人包括三个月后的你自己很容易搞错。2.3 字符串判空避坑口诀总结一下字符串判空的几个注意点纯空白字符串空格、\t、\n等在if not s中不属于空需要strip()后判断。用len(s) 0和if not s效果等价但后者更 Pythonic。如果函数可能返回None不要直接用is None判断“空”要考虑业务上是否你希望和空白字符也算空。字符串判空在表单校验、数据清洗、参数校验中出现频率极高建议封装成一个工具函数统一处理空白与空串的情况。3. 列表判空直接判断、len 判断与“有没有元素”的另一层含义3.1 列表的布尔判断也有自己的规则列表的判空方法和字符串类似my_list [] if not my_list: print(列表为空)列表对象的__bool__方法同样在看长度长度为 0 返回False否则返回True。所以if not my_list能正确判断空列表。同理len(my_list) 0也可以。两种方式在纯判空场景下没有区别选哪个看你自己的偏好。但列表的判空有一个和字符串完全不同的关注点很多情况下我们不只是想知道列表里有没有元素还想知道这些元素是不是有价值的元素。比如列表里全是None或者全是空字符串业务上这可能等同于“空列表”。举个实际场景你从数据库里查询出一批用户 ID结果可能是一个空列表也可能是一个[None, None]的列表。如果用if not user_ids后者不会被当作空。这时候如果你直接去遍历赋值得到的结果可能就是一批None值埋下很深的 bug。所以我会建议在做列表判空时先想清楚“这个列表里是否可能存在无意义的元素”如果需要过滤可以先用列表推导式把None和空字符串过滤掉再判断user_ids [uid for uid in user_ids if uid] if not user_ids: print(没有有效的用户ID)这样过滤之后再判空才真正反映了业务上的“没有有效数据”含义。3.2 列表推导、生成器与判空的“隐式陷阱”列表的判空还有一个很容易被忽略的关联陷阱你判断的常常不是已经存在的列表而是一个生成器或迭代器。我在项目里见过有人写filtered (item for item in items if item.status active) if not filtered: # 这个判断几乎永远成立因为生成器对象本身不是空的 ...生成器对象做布尔判断永远是True因为它自己就是一个对象没有长度也没有__bool__说自己是空。这一行代码不但没用还会误导人以为你已经判断了“过滤结果是否为空”。实际上要判断生成器是否为空只有一个办法——把它转换成列表或者遍历它。而这个转换又会消耗生成器所以正确的写法是filtered [item for item in items if item.status active] if not filtered: ...或者如果你确实想保留生成器的惰性就稍显笨拙地写filtered [item for item in items if item.status active] # 注意这里已经用了列表推导式我个人的习惯是如果是小数据量直接列表推导式如果是大数据量且不需要同时持有全部结果就老老实实用 for 循环和标志位判断或者用一个单独的计数器。千万别拿生成器去直接判空那是一个很隐蔽的逻辑错误。3.3 字典、元组、集合的判空列表判空学会了字典、元组、集合的判空思路是一样的。它们也都实现了__bool__所以d {} t () s set() if not d: print(字典为空) if not t: print(元组为空) if not s: print(集合为空)这里最常见的坑出在set()身上。有些新手会把空集合写成{}但{}在 Python 里是空字典不是空集合。要创建空集合只能用set()。如果你写了if not {}你判断的是一个空字典而不是一个空集合这在逻辑上可能不会出错——因为空集合和空字典的布尔值都是False但代码的语义就不对了。一个函数内部如果声明result {}却想当集合用后面result.add(x)会直接抛AttributeError。所以记住创建空集合用set()不要用{}。元组的判空还有一个小众但真实的场景当你解包的时候如果元组为空a, b t会报ValueError: not enough values to unpack。所以解包前如果元组可能是空的一定要先判断长度或者直接判断元组是否为空。这不算什么高级技巧但说明一个道理——判空不只是为了走分支有时是为了避免程序直接崩溃。4. 判断“非空”的几种写法与风格选择聊完了“空”自然要聊“非空”。在实际编码里“非空判断”用的频率可能比“空判断”还高尤其是条件不满足就直接返回或跳过的时候。最直接的是if my_list: ...这与if not my_list正好相反逻辑清晰读起来也自然“如果列表里有东西就做什么”。项目里我更偏爱这种写法因为它让代码的正面路径更明显避免一上来就写否定逻辑。比如一个处理函数开头往往是def process_items(items): if not items: return [] ...这里的空判断优先返回让主体逻辑不需要嵌套这种“提前返回”的写法在复杂函数里特别有用。它避免了 else 嵌套层层加深也让代码的兜底分支一目了然。还有人会写if len(items) 0。结果一样但多了一个函数调用可读性也一般。在新手教程里经常出现这种写法是因为教学上更容易解释“长度大于 0”的含义。不过在真实项目里我会直接用if items。写多了你会发现Python 的布尔上下文本身就是为这种场景设计的你不用反而绕远了。说到风格判空还有一种常见的写法是引入operator.truth或者bool()来做明显的类型转换。比如if bool(items): ...这种写法是显式地把对象转为布尔值可读性还行但实际没必要。if items内部做的事情就是bool(items)多写一个bool()只是视觉上的重复。除非你在非常追求“显式优于隐式”的团队里否则我不会这么写。那有没有“判断非空”的复杂场景值得单独说有。当列表中包含大量元素时if my_list的布尔判断只是查一下长度不会遍历元素性能很好。但如果你写的是if any(my_list)那就要小心了——any()会从头遍历列表直到遇到第一个真值元素。如果列表里第一个元素就是非空的any()很快返回True但如果列表里全是假值元素它就要遍历完整个列表这在线性扫描时就亏了。所以如果只是想判断“列表是否为空”用if my_list就好不要用if any(my_list)——后者的语义其实是“是否存在至少一个真值元素”和“列表非空”不完全等价而且性能更差。同样的道理if all(my_list)的语义是“所有元素都是真值”它和“列表非空但可能有空元素”是完全不同的场景。把all()和any()用在判空上都是误用。它们真正的场景是判断列表里是否全部满足某条件、是否存在满足某条件的元素。我在做数据清洗时经常这样用if all(item is not None for item in items): # 所有元素都不是 None可以正常处理 ...这个才是all()的正确用途。判空就回到最朴素的if items别为了“显得高级”用错内置函数。5. 用一个小案例串起全部知识点从原始数据清洗到接口返回前面讲了这么多我把这些知识点放到一个真实的小案例里串一遍。假设你要写一个函数接收一段文本和一个关键词列表然后从文本中提取出包含关键词的句子并返回这些句子的列表如果没有匹配任何句子返回一个空列表如果输入文本为空或关键词列表为空则返回空列表。这个场景涵盖了字符串判空、列表判空、过滤、提前返回这些知识点。代码可以这样写def extract_matching_sentences(text, keywords): # 第一步判空直接拦住无意义调用 if not text or not text.strip(): return [] if not keywords: return [] # 第二步按句切分这里按中文的句号、逗号切分简单示例 sentences [s.strip() for s in text.replace(, 。).split(。) if s.strip()] # 第三步过滤出包含任意关键词的句子 matched [s for s in sentences if any(kw in s for kw in keywords)] # 第四步列表判空后返回 if not matched: return [] return matched这个函数虽然简单但我在里面做了几层判空每一层的语义都不同not text判断字符串是否为None或空字符串。这是最外层的兜底。not text.strip()判断纯空白字符串。如果用户传了一串空格这里就会拦住。not keywords判断关键词列表是否为空。列表为空时没有匹配意义。if s.strip()列表推导式里的这个条件是在过滤掉切分后产生的空字符串。if not matched判断最终匹配结果是否为空。这 5 层判空每一层都有它存在的理由。你可以在自己项目里体会一下如果少掉任何一层函数在特定输入下就会出现问题——要么返回了不该返回的值要么在边界输入时产生意外结果。这个函数还能引出一个额外的好习惯在返回空列表时统一用return []而不是return None。这样调用方的代码就可以放心地直接for s in extract_matching_sentences(...)不用额外判断None。如果你返回None调用方一旦忘记判断代码大概率会在某次运行中报TypeError。这是我在团队里反复强调的约定之一函数返回列表时用空列表表示“没有结果”不要用None。用None会让“无结果”和“异常”纠缠在一起增加调用方的负担。6. 判空时最容易踩的 5 个坑我全部帮你列出来好的代码习惯是从坑里爬出来之后养成的。下面这些情况我基本都在真实项目里见过你大概率也会遇到。6.1 用is None去判断所有“空值”这是新手最常见的错误。is None只能判断None不能判断空字符串和空列表。如果你在一个可能有或[]返回的分支里写if result is None你只是在拦截“结果缺失”的情况空字符串和空列表照样会往下走。这种 bug 通常隐藏很深因为测试数据里如果恰好没有空字符串你可能根本发现不了。6.2 滥用if not x把 0、False、None 全兜进来了if not x的合并判断能力是把双刃剑。当你只关心“这个容器是否为空”时它很好用但当你判断的变量可能是数字、布尔值、None时它的合并语义可能会错误地吞掉0和False。我在一个配置解析的模块里就吃过这个亏——某个配置项的0被当成了“未配置”导致默认值覆盖了用户主动设置的 0。从那以后我对“用not去判断数字或布尔值的空 / 无”变得非常谨慎。6.3 忘了处理纯空白字符串表单、爬虫抓取、文本解析这些场景里输入经常带空格、全角空格、换行符。如果你不strip()字段值明明是空白字符串你却认为它有内容然后往数据库里写。这类脏数据一旦产生清洗成本远大于在入口做一次判空的成本。我的习惯是凡是来自外部输入POST 参数、文件内容、命令行参数、网页抓取的字符串做任何逻辑之前一律先 strip()再判空。6.4 拿any()和all()当判空工具any()的语义是“迭代器中是否存在至少一个真值元素”它是用来判断条件的不是用来判断容器的。用if not any(my_list)去代替if not my_list既做不到精确判空还多了一次遍历。同理all()也是一种“全部满足”的条件判断不要拿它当“列表是否为空”的检测器。条件判断和容器判空是两回事混着用会写出语义混乱且性能不佳的代码。6.5 在判空之前没有考虑None的情况下调用len()如果你直接if len(s) 0而s是None程序会直接抛TypeError。有些时候这是好事因为None确实不应该通过但如果业务上“空”就是包含None和那len()就不好使了。我的建议是如果函数的返回值可能是None也可能是字符串或列表就在函数的入口处先把None规约成空字符串或空列表或者用if not s一并判断避免让len()直接面对None。这样处理简单逻辑也不容易绕。6.6 送给团队的判空规范小结在我自己维护的项目里判空规范大概是这样的字符串来自外部的字符串先strip()再判断空函数返回的可能为None的字符串用not判断或者先规约None为。列表/字典/集合/元组用if not container判断空容器不要拿len()去判断not就是最地道的写法。数字判断为 0 时不要用if not num要写if num 0避免None被误判。返回值函数返回列表时用[]表示空结果不要返回None。这张表看起来简单但几乎覆盖了我这些年遇到的所有判空相关 bug。它让我少了很多“明明结果不对却不知道错在哪”的时刻。7. 关于判空两三个容易忽略的小细节最后聊几个我在实际写代码时才会遇到的问题教程里很少提到。一是判断空字符串和判断空列表在性能上的差异。两者底层都是查长度速度都非常快但如果你在一个超大循环里频繁判空尽量把判空放在循环外面或者用短路逻辑提前返回。Python 的函数调用开销不算低判空本身没多大开销但嵌套在深层循环里的判空会反复执行战略上应该尽量减少不必要的工作。二是如果你需要判空的对象来自自定义类记得实现__bool__或者__len__方法。一个容器类的实例如果不实现__len__bool(instance)默认返回True你if not instance永远进不了分支。这一点在写数据模型、集合类封装时特别重要。我自己写过一个配置对象内部维护一个列表如果不在类里实现__len__外部判断“是否存在配置项”就只能靠访问内部属性那接口就不优雅了。实现了__len__之后所有调用方都能直接用if not config代码整体干净了很多。三是如果判空背后需要处理大量数据不要反复在列表推导式里判断同一个对象的空状态。比如[x for x in data if x.strip()]如果x本身重复次数很多可以先做个去重或者用filter配合一个预处理的迭代器。这是性能调优的层面了但和你判空的正确性有关系——一个在 1000 条数据上没问题的判空逻辑在 1000 万条数据上可能就是性能瓶颈。说到底Python 判空看似简单真正写起来还是有不少门道的。核心就一句话先想清楚“空”在这段业务里到底意味着什么再选择对应的判断方式同时养成统一返回空容器而不是None的习惯就能规避掉绝大多数相关 bug。我这些年最深的体会是编程里的很多问题其实不是语法不会而是语义没想清楚。判空这件事就是语义问题的最好缩影——你搞懂了你在判断什么代码自然就写对了。