Python五年实战总结：20条避坑指南与高效编程经验

先说个真实感受。我在上一家公司待了三年半最怕的不是线上服务宕机而是半夜收到“批量任务结果异常”的告警。因为查到最后原因往往不是哪个高深的架构问题而是一行当时觉得“反正能跑”的代码。五年下来真正让我长记性的从来不是某个大型系统的崩溃瞬间反而是这些不起眼的小问题——它们一次次地提醒我Python写起来确实快坑也埋得是真深。这篇文章不打算讲高深源码也不列什么性能调优秘笈就把我五年来踩得最深、想起来就牙痒的20条教训原原本本摊开。每条都对应真实场景有代码的地方直接给写法能抄就抄能避就避。1. 代码层面的坑不是跑不起来才算bug而是三个月后看不懂自己写的1.1 默认参数的“共享记忆”与遍历时删改先说一个看起来人畜无害、实际上坑死过我的写法可变对象作为函数默认参数。def send_mail(subject, body, to_list[]): to_list.append(someoneexample.com) ...Python在函数定义时只计算一次默认值也就是说to_list永远是同一个列表。第一次调用列表是空的一切正常第二次调用列表里还留着上一次的收件人邮件越发越多用户被重复轰炸。我早期做批量通知脚本就栽在这上面上线第二天就被投诉。最气人的是这种bug特别容易被当成“偶发问题”——第一次调用正常第二次才异常复现还得靠运气。修复很简单默认参数写None函数内部再新建列表。def send_mail(subject, body, to_listNone): if to_list is None: to_list [] to_list.append(someoneexample.com) ...另一个高频翻车操作是遍历字典时直接删除元素。for key in conf_dict: if not conf_dict[key]: del conf_dict[key]Python 3 下直接抛出RuntimeError: dictionary changed size during iterationPython 2 虽然不报错但行为完全不可预测。我清理过期缓存时图省事这么写过线上脚本直接崩报错信息打印了三行第一眼还没看懂是什么意思。正确做法是遍历它的副本或者先收集要删除的键循环结束后再统一删。for key in list(conf_dict.keys()): if not conf_dict[key]: del conf_dict[key]1.2 浅拷贝和深拷贝差一字数据全乱copy.copy()和copy.deepcopy()的区别我在第三年才真正刻进脑子里。浅拷贝只复制最外层对象嵌套的 dict、list、自定义对象仍然是引用。有一回做批量任务调度每个任务结果是一个 dict挂在总列表下面。我用浅拷贝复制了一份任务列表然后去修改某个任务的status字段结果发现所有任务的status一起变了。界面展示的数据全部错乱我排查了整整一个下午看到代码里的results.append(copy.copy(task))才反应过来。判断标准就一句话如果数据结构里还有 dict、list 或自定义对象不要图省事直接deepcopy或者干脆用 JSON 序列化来生成独立副本简单、直观、不会猜错。只有纯数字、纯字符串这种不可变对象的列表浅拷贝才没有风险。1.3 异常处理的两个极端全吞与一视同仁except Exception: pass大概是 Python 代码里最常见的定时炸弹。吞掉异常最坏的结果不是“程序崩了”而是“程序看起来正常但数据已经错了”。批量导入 Excel 时某一行格式不对异常被 silently 吞掉脚本继续跑最后报表里少了一行且没有任何提示线上任务吞掉异常后后续逻辑全盘带偏等到用户反馈才发现已经晚了。我的底线很简单catch 之后至少打一行日志把堆栈留下。try: do_something() except Exception: logger.exception(do_something failed, context: %s, context)如果不打算处理就别 catch让它快速失败如果要向上层抛也别甩一个裸异常重新包装成业务异常再抛。说到这“一视同仁”就是另一个极端。except Exception把所有错误当同一种处理KeyError 和 ConnectionError 的策略完全不同混在一起等于没有策略。我踩过最疼的一次是把“接口超时”和“记录不存在”统一返回“查询失败”用户反复重试把依赖的上游服务直接打挂了。后来我们定义了一套业务异常层级可重试的网络超时、暂时不可用、不可重试的数据缺失、校验失败、需要人工介入的权限、配置错误。上层根据异常类型决定重试策略错误处理才真正可控。2. 性能与并发写起来很爽跑起来性能崩2.1 字符串拼接 看似聪明实际是性能陷阱在大循环里用拼字符串是新手最容易忽略的性能问题。Python 字符串是不可变对象每次都会生成一个新字符串然后把旧字符串整个复制一遍。循环次数少看不出问题数据量一上去就是灾难级表现。我处理过一个 5 万行的日志清洗任务刚开始用msg line逐行拼接跑一次要十几秒。改成先放进 list、最后.join()耗时直接降到几十毫秒。这里面的差距是指数级的不是省一点半点的差别。# 慢 result for line in lines: result process(line) # 快 parts [process(line) for line in lines] result .join(parts)凡是在循环里组装字符串一律养成“先收集、后 join”的习惯。就算只是为了格式化输出,.join(str(x) for x in items)也比循环里反复干净得多。2.2 循环里的隐藏IO瓶颈从来不在语法很多人一觉得程序慢就怀疑 Python 本身其实绝大多数瓶颈不在语言而在循环体里的隐藏 IO。比如循环内反复调用os.path.exists或者每读一行就发一次 HTTP 请求又或者在循环里启动子进程做校验——真正的开销在网络往返和磁盘寻址语法层面的优化根本拯救不了。我遇到过一个处理 10 万条配对数据的脚本每条数据都要调用一次外部命令做格式校验。结果 CPU 没跑满系统负载却被子进程启动打崩了。后来把逐条调用改成一次性批量校验再把需要查询的数据提前批量取出性能提升不是百分之十是上百倍。所以只要看到循环体里出现这四类东西——文件读写、网络请求、子进程、数据库查询——先停下来问一句能不能移到循环外能不能批量处理能不能延迟到真正需要的时候再做这一条思考习惯救过我的项目不止一次。2.3 GIL、多线程与真正的并行Python 多线程在 CPU 密集场景下会被 GIL 锁住这是语言层面的机制不是机器有几个核心能绕过的。我早年写过四个线程并行处理大矩阵以为能跑满四核结果 CPU 占用率始终只有 100%当时还以为是自己电脑有问题查了半天才发现是 GIL 在起作用。后来把任务拆给multiprocessing或者干脆让底层 C 库自带的多线程来做矩阵运算速度立刻起来了。这里的关键是分清任务类型任务类型推荐方案原因CPU 密集计算、解析、编解码multiprocessing / 底层库多线程绕开 GIL真正利用多核IO 密集网络请求、文件读写、爬虫threading / asyncioGIL 在 IO 等待时释放线程能并发等待两者混杂按热点拆分分别处理避免把不同瓶颈搅在一起IO 密集场景下线程仍然有用因为网络请求在等待响应时并不占用 GIL。但别把线程当成“并行武器”一上来就用先分清场景再选武器。2.4 不量性能就优化等于盲人摸象异步也不是万能药过早优化是不少有一定经验的开发最容易犯的毛病。我有一回处理上百万行日志第一反应是“Python 太慢是不是要上 C 扩展”。后来用性能分析工具跑了一遍发现绝大部分时间花在文件读取和解码上CPU 占用反而很低。改成大块读取、只在关键解析路径上做优化效率提升了几个数量级全程没碰 C。教训就一条遇到慢先 profile。不要看着循环长得丑就动手重写先让数据告诉你瓶颈在哪里。另一个相关教训是盲目上 asyncio。有一段时间项目需要并发抓取数据我兴冲冲把同步代码全改成 async结果里面一个关键的解析函数还是同步阻塞 IO。整个事件循环被这个阻塞调用卡死并发度反而比原来的线程池更差。async 不是“改个关键字就自动变快”的银弹里面绝不能出现阻塞调用。要么换成真正的异步库要么用run_in_executor把阻塞任务扔到线程池。小任务杀鸡用牛刀异步的调试成本比同步代码高太多没有明确收益就别硬上。3. 依赖、环境与版本三四个项目共用一个解释器的惨痛账单3.1 requirements.txt 不锁版本半年后开机就崩这个坑我大概踩了不下三次。项目在 A 机器上跑得好好的换到 B 机器重装依赖瞬间报错。罪魁祸首就是 requirements.txt 里写的宽松约束requests2.0半年后 pip 解析到最新版某个库“顺手”改了默认行为原来可用的接口直接变了代码应声崩溃。最疼的一次是凌晨发版新版库把超时默认值改了整个批处理任务被拖垮现场改代码、临时锁版本才救回来。现在我的做法很简单项目里的直接依赖用~或精确版本控制然后定期用pip freeze生成完整锁定文件。别嫌 lock 文件啰嗦——它记录的是“这个项目当时跑通的完整环境”是可复现性的最后一道保险。3.2 虚拟环境不是可选项是必选项刚工作的前半年我图省事所有包都直接装进系统 Python。一个项目用旧版 Web 框架另一个项目要新版两个版本互相覆盖最后谁都不稳。更惨的是系统自身依赖的包被顺手升级操作系统的组件直接坏掉。这种问题一旦发生重装环境都不一定救得回来。从那以后每个项目第一天就创建一个venv并把创建命令写进 README这是铁律。团队写作时更是如此——你永远不知道接手你项目的同事机器上是什么状态。与其让他在依赖地狱里挣扎不如从一开始就让环境跟着项目走。生产环境的情况更严重。直接在线上服务器pip install到系统 Python 是绝对禁忌跟裸奔没有区别。后来我把服务改成容器化部署构建阶段把依赖装进镜像运行环境随代码一起发布彻底干掉“一个人一台机器一手动装环境”的不可复现流程。就算暂时上不了容器也至少给生产环境准备一个只读的独立虚拟环境任何人都不能随手往里面装东西。3.3 “最新版”的诱惑与版本不统一的兼容地狱追最新版这件事我曾经吃过很大的亏。当时把一个老项目的 Web 框架升级到最新版因为文档说“新特性很香”。结果升完发现一个核心 API 被标记为实验性行为跟旧版本不一样业务功能一会儿正常一会儿异常。之后我给自己立了一条规矩新项目可以用较新的稳定版老项目和长期维护的系统只盯仍在维护的保守版本升级前先查兼容性公告再在测试环境完整跑一遍回归。版本不统一也很要命。团队里有人用 Python 3.6有人用 3.9还有机器默认 Python 2.7。同一段代码在这台机器能跑换台机器就崩。最常见的分歧点包括字典顺序、f-string、类型注解、异步关键字。解决办法很土但很有效项目根目录写清楚目标解释器版本启动脚本里强制校验python --version不符就直接报错退出。别让“跑不起来”的锅甩给运气。4. 测试、日志与工程规范线上不出事靠的是平时下的笨功夫4.1 不写单测等于把核心逻辑交给运气“这个脚本跑一次就行不用写测试”——这种话我听过太多次自己也说过。直到有一次做数据清洗自测时看起来一切正常上线三个月后才遇到特殊字符导致逻辑出错回查过去三个月的数据发现中间有一批已经被错误处理了。如果一开始就给核心函数写几个单元测试覆盖正常、异常、边界三种情况这个问题当天就能暴露。写测试不一定要搞严格的 TDD但至少做到一点每次改动逻辑之前先有测试把当前行为钉住。这样才不会出现“修了 A 功能弄坏了 B 逻辑”的经典悲剧。一个纯粹靠人工回归、改一次提心吊胆一次的项目本质上是没有工程保障的。4.2 只测 happy path边界异常全靠现场补课比不写测试稍微好一点、但依然危险的是只测“正常情况”。列表非空、请求成功、文件存在、参数合法全测一遍全绿然后上线就放心了。结果生产环境第一个请求就遇到空列表、第一个文件就损坏代码全流程崩掉。单测真正的价值恰恰体现在失败路径上除数为零、字典缺 key、服务超时、文件不存在、并发写入、数据量极大、数据量为零。把这些边界情况码住至少能挡掉 90% 的线上突发。有一次我把一个函数改得看似更优雅顺手加了几个边界测试结果测出一个数组越界——如果没那几条测试上线后必然又是一次事故。4.3 日志不分类不打点线上排查基本靠脑补线上服务一出问题大家第一反应就是翻日志。但如果你的代码里全是print或者只打关键成功节点、不打失败现场那这个日志基本等于没有。我总结了一套最低要求每个业务的进出点至少打一行结构化日志包含时间、追踪标识、关键参数、数据变化量异常日志必须带异常类型和完整堆栈否则出问题根本不知道怎么复现。这里特别想强调追踪标识。没有 trace-id一条请求在多个服务之间跳转你根本没法把零散日志串成一条线。以前排查跨服务问题拿着时间戳在两个系统里翻来翻去全靠肉眼对。后来每条请求入口自动生成一个唯一标识传到每个下游排查时间直接缩到原来的五分之一。日志不一定要上多贵的平台但格式统一、关键信息齐全是最低标准。4.4 规范、格式与文档别让三个月后的自己成为陌生人代码风格这个事情曾经我觉得无所谓能跑就行。后来团队只要两个人协作就为了空行、命名、import 顺序反复争吵更可怕的是没有静态检查一些低级错误——变量名拼写错误、未定义变量、类型不一致——全在代码运行时才暴露。于是我们上了静态检查工具、代码格式化工具和 import 整理工具规则固定并在 push 之前用钩子自动跑一遍。从那以后代码评审的时间至少少了一半。文档也是同样逻辑。代码没人看得懂、接口文档只写了结论、部署步骤靠群里口口相传这些我都经历过。半年后再看自己写的模块连入口函数都要想半天更别提接手的人。我的底线是README 至少写清楚这个项目是什么、怎么跑、怎么测、环境要求每个公共函数的 docstring 写明参数、返回类型和异常关键的设计决策在代码旁边注释写清楚“为什么这么做”。这些写的时候觉得慢接受项目的时候才发现是真救命。别把“写注释”当成给公司做贡献其实是给三个月后的自己留后路。这20条写出来看起来没有一条是高深理论但每一条背后都对应一次真实的加班和深夜告警。说实话代码能力提升靠的往往不是多聪明而是同样的错误不再犯第二遍。这些年我带过的新人很多也是在某个坑里翻过车之后才把“能跑就行”的念头换成“是不是还有边界没考虑”。如果你现在刚入行或者正在写第一个小系统一时用不上全部但请先把默认参数、异常处理、虚拟环境和版本锁定这几条记在心里——那是我被教育得最惨的几堂课正好也是新手最容易踩中的雷区。