Python 中千万不要直接返回 None
Python技术迷约 3 分钟隔壁组小王，他突然就吐槽说“千万别在 Python 里随手就 return None，坑死人”。我当时还迷糊着，后来仔细一聊，发现这事儿真挺多踩坑的。
你别说，就那天我还碰到一个例子，写个接口数据查询的函数，结果那兄弟 return None，前端直接报500，说啥 json 解析不了。我说这咋整，他还一脸懵，结果一查，data 是 None，你 json.dumps(None) 得出来就是 null，对吧，前端有时候预期里 data 至少得是个 {} 或 []，你弄个 None，他那边 if data 判断全挂了。其实这场景太常见了，尤其公司那堆旧代码，谁还没踩过。
有时候你写个函数，比如：
defget_user_by_id(user_id):
# 查询数据库
user = db.query(User).filter_by(id=user_id).first()
ifnot user:
returnNone
return user
表面上看很正常吧，查不到就 None。但你下游调用的人要是没判空，直接 user['name']，分分钟 TypeError：'NoneType' object is not subscriptable。我当年新来的实习生就这么挂了一次，还是周末凌晨被call醒的那种，第二天小伙脸都绿了，哈哈哈。
其实用 None 最大问题就是：“语义不清”。你到底是没查到，还是出错了，还是查到空对象？None 没法表达清楚。那怎么搞？我一般都是两种方式：
返回明确类型的默认值
你像查列表，没查到你就直接 return []，查 dict，你就 return {}。查对象你就看场景，有时候可以 return 一个有默认属性的实例，至少不会 None。
用自定义的返回结构
有段时间我们组统一都封装成 dict，比如：
defget_user_by_id(user_id):
user = db.query(User).filter_by(id=user_id).first()
ifnot user:
return {'success': False, 'data': None, 'msg': '未找到用户'}
return {'success': True, 'data': user, 'msg': 'ok'}这样前端也省事，不用猜是不是 None，直接 success 判下就行了。
有一次，组里那个老王（不是小王），他特别喜欢装那种“懒得写多余代码”的劲儿，就硬是喜欢 return None。结果线上有一堆接口都要写这种 if 判断：
res = get_xxx()
if res isnotNone:
# do sth
else:
# 处理异常
后来实在受不了了，我直接搞了个装饰器，把 None 都变成默认值，反正后台日志看了一周，异常明显降下去了。你别不信，这种小细节，真的能救命。就好像你随便 return None，别人用你代码都得小心翼翼的，每次都得写 if 判断，代码可读性直接拉垮。
有个小技巧，反正我后来都这样：
defsafe_get_user(user_id):
user = db.query(User).filter_by(id=user_id).first()
return user or {}
就是你查不到我就给你个空字典，反正你拿着用也不会崩。你说这有时候是不是有点投机取巧？但实际开发，真的没人愿意处理各种 None，能省心的就省心。
当然你要真想严谨点，可以学下 Java 那种 Optional，但 Python 场景下用的少，毕竟是动态语言嘛。不过写项目文档的时候，最好写清楚这个函数永远不会返回 None，让大家都能安心用。
哦对了，还有一种情况我也踩过坑——你写递归函数的时候，没 return 的地方自动变 None，结果最后 return 出去的是 None，不是你想要的结构。比如：
defdfs(node):
ifnot node:
return
# 处理逻辑
你没写 return，默认就是 None，你下游用 dfs(node) 以为有返回，结果其实啥都没有。后来我都强迫症，写递归都加 return，省的稀里糊涂的。
反正结论就一个：Python 里你随手 return None，绝对不是偷懒，是给自己挖坑，尤其是多人协作，接口层面建议所有函数都别让人猜，直接保证类型一致，没人会嫌你麻烦。你们谁还有啥血泪教训，欢迎来补充啊
-END-
我为大家打造了一份RPA教程，完全免费：https://www.songshuhezi.com/rpa.html
虎哥作为一名老码农，整理了全网最全《python高级架构师资料合集》，总量高达650GB，点击下方公众号回复关键字 python 全部免费领