1. 为什么会把异常处理和匿名函数放在一起讲如果你学过前几节课能写变量、能写函数、能跑通几个小脚本那这第五节课的内容就是你从“会写”到“写稳”的一道分水岭。先说异常处理。写Python的人没有一刻不在跟报错打交道文件读着读着突然说找不到、用户输入了一个空值、网络请求超时、除零运算直接把整个程序干趴下。这些都叫“异常”。异常处理解决的并不是“怎么让程序不报错”而是“程序报错了之后我能不能让它优雅地兜住、记录、修复而不是整个进程直接崩溃留下一堆看不懂的红色Traceback就走了”。再说匿名函数也就是lambda。它本质上就是“临时用一次的简单小函数”。名字里的“匿名”两个字听着玄乎其实表达的意思非常朴素——有些函数只在一个地方用用完就不再需要了甚至不值得给它起个名字干脆用lambda一行写完用完即弃。你在看别人的代码时经常能看到sorted(data, keylambda x: x[age])这种写法这就是lambda最常见的出场方式。这两个知识点单独看都不难但绑在一起学是有道理的。异常处理教你应付“程序运行时的意外”lambda教你写出“更精简、更函数式、更Pythonic”的代码。两者都属于“让你的代码能扛事、且像样”的进阶基本功也是后续学爬虫、学数据处理、学接口开发时天天要用的东西。这一节课适合什么人看如果你已经懂变量、类型、条件判断、循环并且自己动手写过三五个小脚本那这个进度刚刚好。如果连函数是怎么定义的都还迷糊建议先把上一节的内容补一补再往下看不然lambda这段会比较吃力。老规矩这节的核心是“能落地的代码”所以每段我都会给可直接运行的示例并结合实际场景解释“为什么这么写”。2. 异常处理的全貌从try-except到自定义异常2.1 最小可用的try-except写法先从一个最简单的例子开始。假设你要打开一个文件f open(data.txt, r, encodingutf-8) content f.read()这段代码在data.txt不存在时会直接抛出一个FileNotFoundError程序当场终止。一旦终止后面所有的逻辑都不会执行。这在真实的项目里是很危险的——没有兜底、没有日志、没有任何收场动作用户看到的就是一个光秃秃的报错。最基础的解决办法是用try-except把它包起来try: f open(data.txt, r, encodingutf-8) content f.read() except FileNotFoundError: print(文件不存在请检查文件路径)就这么几行程序的“韧性”就已经提升了一个档次。try下面的代码是“我尝试去做的事”except下面的代码是“如果出了我指定的这类问题我就这么处理”。程序不会崩友好提示也给了。这里有一个重点必须讲清楚except后面跟的异常类型是“精确打击”而不是“无差别轰炸”。上面例子写的是FileNotFoundError那就只有文件不存在时会进这个分支。如果是读取过程中出现了编码问题抛的是UnicodeDecodeError那上面的处理就管不着了。对于初学者最容易踩的第一个坑是把except写成了光秃秃的except:也就是所谓的“裸捕获”。try: x int(input(请输入数字: )) except: print(输入有误)这个写法在语法上没错但在工程习惯上是强烈不推荐的。为什么因为它会把系统级的KeyboardInterrupt、MemoryError这些你不该拦的东西也拦下来。举个极端例子用户按了CtrlC中断程序这本来应该直接停下来但你的裸except把这次中断也当作“普通错误”吃了程序还继续跑这就不对了。建议的写法是精确到异常类型try: x int(input(请输入数字: )) except ValueError: print(无法转换为数字请重新输入)ValueError意思是“值本身有问题”——输入的字符串不是合法的数字格式这就是int()转换失败时抛出的异常类型。这样写意图明确也方便后面针对不同错误走不通分支。2.2 多个except、else与finally的完整配合真实项目里的异常绝不止一种。一个调接口的请求既可能超时也可能返回空数据还可能因网络问题连接不上。这时你可以写多个except分支import requests try: resp requests.get(https://api.example.com/data, timeout5) resp.raise_for_status() data resp.json() except requests.exceptions.Timeout: print(请求超时请稍后重试) except requests.exceptions.ConnectionError: print(网络连接失败请检查网络) except ValueError: print(返回内容不是合法JSON) except Exception as e: print(f发生了未预期的错误: {e})注意这里的排列顺序更具体的异常写在前面更通用的Exception兜底写在最后。因为except是自上而下匹配的如果先把Exception写在前面那Timeout、ConnectionError这些统统会被它接住后面的分支永远走不到。这就好比消防通道从一楼被堵死了上面楼层的人根本下不来。else和finally是两个容易被忽略的分支但用法非常明确else只有try块里没有发生任何异常时才会执行。适合放“正常路径的后置逻辑”比如解析成功之后的后续处理。finally无论有没有异常都会执行。典型用途是释放资源——关闭文件、关闭数据库连接、释放锁。一个更完整的例子f None try: f open(config.txt, r, encodingutf-8) config f.read() except FileNotFoundError: print(配置文件缺失使用默认配置) config 默认配置 else: print(配置文件加载成功) finally: if f: f.close()这个结构的执行逻辑是文件存在时执行try→ 执行else→ 执行finally文件不存在时执行except→ 跳过else→ 执行finallyfinally的最大价值在于“善后工作不遗漏”。哪怕try块里出现了你没预料到的崩溃finally也能保证f.close()被执行。如果你之前习惯用with open(...)来管理文件那更稳妥因为with语句底层就是帮你自动处理了关闭逻辑。这里之所以演示finally是因为在数据库连接、线程锁、临时文件等场景里你未必有现成的“with”可用理解finally仍然很有必要。2.3 主动抛出异常raise的用法写代码不只是“被动接住异常”有时候我们需要“主动抛出异常”。比如你写了一个函数校验用户传入的参数不合法那最好的做法不是返回一个“不太对”的结果而是直接抛异常让调用方明确知道出错。一个典型的场景注册功能里校验密码长度。def register(username, password): if len(password) 8: raise ValueError(密码长度至少8位) if username : raise ValueError(用户名不能为空) return f用户{username}注册成功 try: result register(小张, 123) except ValueError as e: print(注册失败:, e)这里用raise ValueError(...)主动抛出异常本质上是“把问题在源头就拦截下来、并传递出清晰的错误信号”。如果你选择返回False或None调用方还得自己去猜“是哪里出了问题”。异常的好处就是类型本身就是信息提示文案也随身携带。2.4 自定义异常当内置异常不够用时等代码积累到一定量你会遇到“内置异常类型表达不了我业务上的特殊错误”的情况。例如你写了一个银行转账类余额不足这种错误用ValueError不是不行但不直观。这时可以自定义异常class BalanceNotEnoughError(Exception): 余额不足时抛出的自定义异常 pass def transfer(account, amount): if amount 0: raise ValueError(转账金额必须大于0) if account.available_balance amount: raise BalanceNotEnoughError(余额不足当前余额: str(account.available_balance)) try: transfer(user_account, 3000) except BalanceNotEnoughError as e: print(转账失败:, e)自定义异常的规则很简单继承Exception类就行通常还会补上文档字符串说明这个异常是干什么的。这样做的价值在于当你的代码越写越大try-except分支越来越细业务异常有了自己专属的类型调用方就可以非常精确地针对某一种异常做专门处理而不是靠字符串去匹配错误信息。我个人的经验是自定义异常别滥用。如果你只是写几十行的练习脚本内置异常完全够用。但当你的项目开始分模块、多文件有明确的业务边界时定义两三个专属异常会让代码的可读性和可维护性上一个档次。3. 匿名函数lambda一行写完的“轻量函数”3.1 从def到lambda压缩的是什么先看一个对比。如果要对一组数字按绝对值排序用普通函数写是这样def abs_sort(x): return abs(x) numbers [3, -5, 2, -8, 1] sorted_numbers sorted(numbers, keyabs_sort)这个abs_sort函数只用了一次却占了三行代码还得起个名字。用lambda改写numbers [3, -5, 2, -8, 1] sorted_numbers sorted(numbers, keylambda x: abs(x))lambda的语法结构是lambda 参数: 返回值拆开看就是三句话lambda关键字说明这是匿名函数冒号左边是参数列表支持多参数用逗号分隔冒号右边是一个表达式这个表达式的计算结果会自动作为返回值比如add lambda a, b: a b print(add(3, 5)) # 输出8等效于普通函数def add(a, b): return a b注意lambda右边只能是一个“表达式”不能是语句块。你不能在里面写循环不能定义变量再赋值更不能写if ... else多行逻辑。lambda适合的是那种“一行能算完”的场景。一旦逻辑多起来老老实实用def才是正道。还有一个关键点lambda虽然定义了可以赋值给变量但从设计意图上它更适合“直接传参使用”。上面那个add lambda a, b: a b的写法不推荐因为你既然都要赋给一个变量去重复使用了那它就不是“匿名临时函数”给它起个正常名字、用def定义可读性更高、报错排查也更容易。3.2 lambda的典型使用场景sorted、map、filter、maxlambda最常见的使用场景就是“作为另一个函数的参数”。来四个高频例子。第一个按字典的某个键排序students [ {name: 张三, score: 78}, {name: 李四, score: 92}, {name: 王五, score: 85}, ] sorted_students sorted(students, keylambda s: s[score], reverseTrue) print(sorted_students)这段就是从高到低给学生按分数排了个序。key参数的意思就是“告诉sorted按什么规则取出比较大小的依据”lambda在这里负责“从每条记录中提取出分数”。第二个配合map做批量转换prices [19.9, 30, 85.5] price_floats list(map(lambda p: float(p), prices)) print(price_floats)把字符串列表统一转成浮点数。map函数接受一个函数和一个可迭代对象对每个元素依次调用这个函数返回一个迭代器。这里的lambda就是“转换规则”。第三个配合filter做筛选numbers [1, 2, 3, 4, 5, 6, 7, 8] evens list(filter(lambda n: n % 2 0, numbers)) print(evens)filter的意思就是“按条件过滤”lambda给出的是保留与丢弃的判断条件返回True就保留返回False就丢弃。第四个配合max/min找极值words [python, java, c, javascript] longest max(words, keylambda w: len(w)) print(longest)找出列表里最长的字符串。max的key也接受一个规则函数lambda在这里提供了“按什么维度来比较大小”的依据。这四个场景的共同特点是lambda不是主角它是作为配置项、作为规则传给了别的函数。这也正是lambda真正的用武之地——它不是让你“少写几行”而是让你能够把一段逻辑“当场描述清楚”。3.3 lambda的边界什么时候别硬上lambda有些场景里lambda反而不是好选择我把踩过的坑列一下。第一逻辑超过一个表达式时。比如你要按“分数高且名字长度大于2”来排序这已经不是一行表达式能说得清的了。硬写lambda会变成一大坨可读性极差sorted_students sorted(students, keylambda s: (s[score] 80 and len(s[name]) 2))这种写法不是不能跑但代码的“意图”已经完全被语法淹没了。换成普通函数情况就清楚得多def sort_rule(s): return s[score] 80 and len(s[name]) 2第二你需要错误排查时。lambda在回溯信息里显示的是lambda一旦出了问题报错只告诉你“是lambda那一行出错了”但具体是哪个数据、哪个变量状态不对你很难直接看明白。模块化的def函数就好排查得多——因为它有名字、有清晰的函数体你可以单独调用它打印中间结果。第三你需要复用逻辑时。同一个排序规则在多个地方使用那把它写成def函数并提取到一个公共模块里才是正确选择。每次到处复制lambda后续一旦规则变了你得一个个去找、去改维护成本直接拉满。4. 实战整合一个会“出岔子”的数据清洗脚本4.1 场景设定与目标单独讲语法容易忘拼起来用一次就记住了。这里设计一个贴近真实工作的小场景有一个CSV文件里面记录了一批订单数据。字段分别是“用户名、金额、城市”。原始文件里可能有缺失值、非法金额、未知城市等情况程序要完成三件事按行读取文件正确处理“文件不存在”等异常。用lambda对读取到并清洗好的数据按金额从高到低排序。统计有效数据的总金额和平均金额把结果打印出来。这个场景基本涵盖了本节课的两个知识点而且问题足够真实。我给出一版完整的可实现代码下面逐段拆解。文件里的示例数据长这样name,amount,city 张三,89.5,北京 李四,, 王五,120,上海 赵六,abc,广州 钱七,59,杭州其中李四的金额是空的赵六的金额写成了非数字。这些都是数据清洗中非常典型的脏数据。4.2 完整实现与逐段讲解import csv def load_orders(file_path): 读取订单文件返回原始行数据 orders [] try: with open(file_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: orders.append(row) except FileNotFoundError: print(f错误: 文件{file_path}不存在) return [] except UnicodeDecodeError: print(错误: 文件编码不是UTF-8请检查源文件) return [] return orders def clean_orders(orders): 清洗订单数据过滤掉金额缺失或非数字的记录 valid [] for order in orders: try: amount float(order[amount]) if amount 0: raise ValueError(金额不能为负数) except (ValueError, KeyError): continue order[amount] amount valid.append(order) return valid def main(): orders load_orders(orders.csv) if not orders: return valid_orders clean_orders(orders) if not valid_orders: print(没有有效数据可处理) return # 用lambda按金额从高到低排序 sorted_orders sorted(valid_orders, keylambda o: o[amount], reverseTrue) # 汇总统计 total_amount sum(order[amount] for order in sorted_orders) avg_amount total_amount / len(sorted_orders) print(按金额排序后的订单:) for order in sorted_orders: print(f {order[name]}: {order[amount]}元 ({order[city]})) print(f有效订单数: {len(sorted_orders)}) print(f总金额: {total_amount:.2f}元) print(f平均金额: {avg_amount:.2f}元) if __name__ __main__: main()这段代码里有几点值得专门说一说。第一在load_orders里我用try-except接住了FileNotFoundError和UnicodeDecodeError。实际处理数据文件时文件不存在是家常便饭编码不对更是高频事故——最常见的坑是Windows下用gbk编码保存的文件直接在Linux服务器上用utf-8去读瞬间UnicodeDecodeError。把这两种异常单独分支打印明确提示调试时一眼就能定位问题比一个光秃秃的except Exception呼噜一口全接住要省事得多。第二在clean_orders里我尝试把amount字段转换为浮点数。float()会抛ValueErrorfloat(abc)也会抛ValueError而order[amount]访问不到键时抛的是KeyError。这里把它们合并写成except (ValueError, KeyError)表示这两类问题统一按“无效数据”处理直接continue跳过这一行。这种并排捕获的写法很常用注意括号是必需的写成except ValueError, KeyError那是旧版本语法在Python 3里直接在语法层面就报错了。第三排序那行用了lambdakeylambda o: o[amount]。如果你的数据已经清洗到这一步其实用operator.itemgetter(amount)是更高效的写法但lambda的可读性对教学场景更友好而且性能差异在几千条数据量级上完全感受不出来。真正需要优化的场景是几十万条以上的排序那时引入itemgetter值得考虑。第四统计部分用了生成器表达式sum(order[amount] for order in sorted_orders)。这里没有出现lambda但它和lambda一样都是Python“函数式表达”这一路的思想——把“遍历累加”这种高频操作浓缩成一行表达式代码干净利落。如果你只想统计总金额其实根本不需要先排序把sum放在clean_orders结果上直接算就行。我之所以在这个脚本里先排序再统计是为了同时演示lambda的排序用法也让输出更直观。将这段脚本存在clean_orders.py里然后在同目录下放一个orders.csv运行效果大致如下按金额排序后的订单: 王五: 120.0元 (上海) 张三: 89.5元 (北京) 钱七: 59.0元 (杭州) 有效订单数: 3 总金额: 268.50元 平均金额: 89.50元李四和赵六两条脏数据被正确地过滤掉了程序从头到尾没有崩溃。4.3 这个实战脚本可以怎么扩展这个脚本本身已经具备了“读文件-清洗-排序-统计”的典型数据管道雏形。你可以在它的基础上继续加东西比如把清洗后的结果写回到一个新的CSV文件或者增加城市维度的统计用groupby按城市分组然后对组内金额做汇总。每一次扩展你都会更清楚地意识到“异常处理”是在为整个流程兜底——因为真实生产环境里脏数据永远比你预想的多。5. 高频报错与排查技巧速查5.1 本节最常见的几种异常把这一节内容容易遇到的高频异常整理成表格方便你平时查阅。表格里的异常类型、触发场景、报错特征都是实打实常见的。异常类型常见触发场景报错关键信息处理建议FileNotFoundErroropen()打开不存在的文件No such file or directory检查路径是否拼错、文件是否在指定目录UnicodeDecodeError用错了编码读取文件utf-8 codec cant decode byte确认文件真实编码使用gbk等正确编码重试ValueErrorint()/float()转换失败invalid literal for int()捕获后提示用户输入合法数据ZeroDivisionError除数为0的除法运算division by zero运算前先判断除数是否非零KeyError字典中访问不存在的键xxx用dict.get()代替直接下标访问TypeError函数调用参数类型不匹配unsupported operand type(s)检查传入实参是否与形参类型一致一个值得强调的排查习惯报错信息永远读最后一行。Python的Traceback信息是从上往下列出一层层的调用关系真正的异常类型和错误描述在最后一行。很多初学者看到一长串红色就慌了其实你只需要看最后一行比如TypeError: unsupported operand type(s) for : int and str它已经告诉你是号两边出现了int和str类型不相容。5.2 三个实用小技巧再分享三个实际工作中非常有用的小技巧。第一个用logger.exception(e)代替print(e)。在正规项目里错误日志最好记录下来而不是只打到控制台。Python的logging模块里有一个logger.exception(e)方法它会把异常信息连同Traceback栈一起记到日志里排查问题的时候价值巨大。第二个善用traceback.format_exc()。如果你需要把详细的错误堆栈转成字符串方便在界面展示或者发送到告警平台可以用它import traceback try: x 1 / 0 except ZeroDivisionError: error_detail traceback.format_exc() print(error_detail)这个error_detail字符串里包含完整的调用栈信息调试时比只打印一个错误摘要要清晰得多。第三个写文件读写的场景优先用with open(...) as f而不是手工f.close()。with语句会在代码块结束后自动关闭文件即使中途抛了异常文件也会被正常关闭少了很多资源泄漏的隐患。6. 最后再分享一点我的使用习惯这一节的内容如果只说一句话总结那就是写代码要默认“一定会出错”然后把出错时的退路提前铺好。我自己写Python这些年最大的感受就是“看起来没问题”的代码在真实数据面前经常一秒现原形。接口超时、数据库连接突然断了、上游数据格式悄悄变了这些情况都不是“万一”而是“必然”。所以我在每个生产脚本里都会习惯性考虑如果这里出错了用户会看到什么程序能不能安全退出关键的日志有没有记录下来lambda用多了之后我也会刻意克制。写一行lambda虽然痛快但如果那个逻辑稍加变化、或者需要在别处复用我就立刻把它改成def函数。代码这东西首先是写给人读的其次才是给机器跑的。“能跑”和“好维护”是两码事异常处理和lambda就是你在这条路上跨出的第二步。按这个节奏下一节课就可以往文件操作和数据处理的方向走了。那些场景里异常处理和匿名函数会反复出现到时候你会发现今天花的时间非常值。