1. 为什么“02”这个编号值得单独写一篇很多人看到“02-python你应该知道这这些”这个标题第一反应可能是又是一个Python基础合集。但我做了十多年一线开发带过不少新人也 review 过大量项目代码发现一个很普遍的现象——大家学 Python 的路径几乎都是“语法入门 → 框架上手 → 遇到问题再补”中间缺了一层。这层缺失的东西恰恰就是标题里那个“02”想说的在语法和框架之间有一批“你应该知道”的东西它们不新鲜但决定了你写出来的代码是能维护的还是三个月后自己都不想看的。这篇内容我打算聊的就是这批东西。它不是入门教程不会从变量和循环讲起也不是高级技巧合集不涉及元类、描述符那种偏门玩法。它面向的是已经能写 Python、能跑通脚本、但总觉得代码“差点意思”的人——可能是刚工作一两年的开发者可能是从别的语言转过来的工程师也可能是自己写小工具但想写得更规范的人。核心目标只有一个把那些日常高频、但容易被忽略的 Python 实践讲透让你看完能直接改自己手头的代码。我先把这篇要覆盖的范围交代清楚避免你读到一半发现不是自己想要的。整体分四块第一块讲代码组织和命名这类“软规范”第二块讲数据结构与内置工具的选型逻辑第三块讲函数与错误处理的实操细节第四块讲调试、日志和性能这些工程化习惯。每一块我都会给出“为什么这么做”的理由而不是甩一句“PEP8 规定”。因为规范背后的原因才是你能迁移到其他场景的东西。提示这篇里的所有代码示例都可以直接复制运行Python 版本以 3.10 为准。如果你还在用 3.6/3.7大部分内容依然适用个别语法我会单独标注。2. 代码组织与命名那些“看起来无所谓”的决定2.1 命名不是审美问题是信息密度问题新手最容易低估的就是命名。我见过太多data、temp、result、list1、list2满天飞的代码。写的时候爽读的时候痛苦。命名本质上是在用标识符承载信息一个好的名字能省掉一行注释一个烂的名字能让读者反复回翻上下文。我自己的命名习惯遵循三条变量名体现“是什么”而不是“什么类型”。user_list不如active_users因为前者只告诉你它是个列表后者告诉你里面装的是活跃用户。函数名体现“做什么”用动词开头。process()太泛normalize_phone_number()一看就懂。布尔值用is_、has_、can_开头。flag这种名字等于没起is_expired一眼就知道判断条件。这里有个反直觉的点名字长一点没关系短而模糊才是灾难。现代编辑器有自动补全你多敲几个字符的成本远低于别人包括未来的你理解代码的成本。我见过有人为了“简洁”把calculate_monthly_revenue缩成calc_mr结果半年后全组没人记得mr是 monthly revenue 还是 margin ratio。2.2 模块拆分什么时候该拆什么时候别拆另一个高频困惑是“一个文件写多大该拆”。网上有种说法是“超过 500 行就拆”我觉得这个标准太机械。我的判断依据是职责是否单一而不是行数。举个实际场景你写一个数据处理脚本里面有读文件、清洗、计算、导出四段逻辑。如果这四段加起来 200 行放一个文件完全没问题拆开反而增加跳转成本。但如果“清洗”这一段自己就有十几种规则、依赖好几个辅助函数那即使总行数不多也应该把清洗逻辑单独抽成一个模块。我通常用这个信号判断当我在文件里找某个函数需要滚动超过两次屏幕时就该考虑拆了。因为这说明文件已经超出了“一眼能扫完”的范围认知负担开始上升。拆模块时有个坑要避开不要为了拆而拆制造循环依赖。A 模块 import BB 又 import APython 虽然能处理一部分这种情况但运行时会出各种诡异问题。避免的方法是让依赖关系保持单向——底层工具模块不依赖上层业务模块业务模块可以依赖工具模块。2.3 类型注解不是给机器看的是给人看的Python 3.5 引入类型注解后争议一直没停。有人觉得动态语言加类型是“背叛”有人觉得是刚需。我的立场很明确在中大型项目里类型注解的收益远大于成本在小脚本里可以按需使用。类型注解最大的价值不是运行时检查Python 默认不检查而是让 IDE 和读者知道数据的形状。当你看到一个函数签名def parse_config(path: str) - dict[str, Any]:你立刻知道它接收字符串路径、返回字典。没有注解的话你得读函数体才能确认。我自己的实践是公开函数、跨模块调用的函数、数据结构复杂的函数一定加注解内部临时的小函数可以省略。这样既保证了关键接口的清晰度又不会让写代码变成填表格。from typing import Optional def find_user(user_id: int, cache: Optional[dict] None) - Optional[dict]: 按 ID 查找用户找不到返回 None。 if cache and user_id in cache: return cache[user_id] # 实际查询逻辑省略 return None注意Optional[dict]表示“可能是 dict 也可能是 None”这个信息在调用方处理返回值时非常关键。没有它调用方可能忘记判空直接user[name]就崩了。3. 数据结构与内置工具选对了省一半代码3.1 list、dict、set 的选型逻辑很多人写 Python 只用 list 和 dictset 几乎不碰。但 set 在去重和成员判断上的性能优势是数量级的。我做过一个实测判断一个元素是否在 10 万个元素的集合里list 用in平均耗时约 2 毫秒set 只要 0.02 毫秒左右差了一百倍。原因是 list 是线性查找set 是哈希查找。所以选型逻辑很简单需求首选原因有序、可重复、按下标访问list天然支持索引和顺序键值映射、快速查找dict哈希实现查找 O(1)去重、成员判断、集合运算set哈希实现去重和判断极快有序且需要去重dict3.7 保序兼顾顺序和唯一性这里有个细节Python 3.7 之后 dict 是有序的所以“需要有序的去重”场景用 dict 的 keys 比用 set 再排序更省事。比如你想保留一组 ID 的首次出现顺序并去重ids [3, 1, 3, 2, 1, 5] unique_ordered list(dict.fromkeys(ids)) # 结果[3, 1, 2, 5]dict.fromkeys这个用法很多人不知道它比list(set(ids))好在保留了顺序比手写循环去重简洁得多。3.2 列表推导式与生成器什么时候用哪个列表推导式是 Python 的标志性语法但滥用的情况很普遍。我的原则是推导式只用于“简单转换 简单过滤”逻辑一复杂就退回普通循环。什么叫简单我的标准是推导式里不超过一个if且表达式本身不超过一行。比如[x * 2 for x in nums if x 0]就很清晰。但如果你写成嵌套两层 for 加两个 if还带个三元表达式那读起来就是天书不如老老实实写循环。生成器表达式用圆括号而不是方括号则适合数据量大、只需要遍历一次的场景。因为它不一次性生成所有元素内存占用小。比如读取一个超大文件的行# 列表推导式一次性把所有行读进内存 lines [line.strip() for line in open(big_file.txt)] # 生成器表达式逐行处理内存友好 lines (line.strip() for line in open(big_file.txt))如果文件有几个 G前者可能直接把内存撑爆后者则稳如老狗。这个区别在处理日志、CSV 这类场景里特别重要。3.3 collections 模块被低估的宝藏标准库的collections模块里有几个工具用好了能省掉大量样板代码。我挑三个最常用的说。defaultdict当你需要“字典的值是列表往里面追加元素”时普通 dict 得先判断 key 存不存在defaultdict 直接帮你初始化。from collections import defaultdict # 普通写法 groups {} for name, dept in employees: if dept not in groups: groups[dept] [] groups[dept].append(name) # defaultdict 写法 groups defaultdict(list) for name, dept in employees: groups[dept].append(name)Counter统计频次的神器一行搞定词频统计。from collections import Counter words [apple, banana, apple, cherry, apple] counts Counter(words) print(counts.most_common(2)) # [(apple, 3), (banana, 1)]namedtuple当你需要一个“轻量级对象”但又不想写类时namedtuple 让元组字段有名字可读性大幅提升。from collections import namedtuple Point namedtuple(Point, [x, y]) p Point(3, 4) print(p.x, p.y) # 3 4这三个工具我在实际项目里几乎每周都会用到强烈建议纳入工具箱。4. 函数设计与错误处理把边界情况想在前面4.1 默认参数的陷阱可变对象不能当默认值这是 Python 最经典的坑之一但每年还是有无数人踩。看这段代码def add_item(item, target[]): target.append(item) return target print(add_item(1)) # [1] print(add_item(2)) # [1, 2] ← 不是 [2]问题在于默认参数只在函数定义时求值一次所以那个空列表是所有调用共享的同一个对象。正确做法是用None做默认值函数内部再初始化def add_item(item, targetNone): if target is None: target [] target.append(item) return target这个坑的隐蔽性在于单次调用看不出问题只有多次调用才暴露。我建议你养成习惯只要默认值是 list、dict、set 这类可变对象一律改成 None。4.2 异常处理别用裸 except也别吞异常try/except用错的方式主要有两种。第一种是裸except:它会捕获所有异常包括键盘中断和系统退出导致程序无法正常终止。第二种是捕获了异常但什么都不做也就是“吞异常”出了问题完全没线索。我的写法习惯是捕获具体的异常类型并且在 except 块里至少记录日志。import logging try: value int(user_input) except ValueError as e: logging.warning(输入无法转为整数: %s, 原始值: %r, e, user_input) value 0这里捕获ValueError而不是所有异常是因为我知道int()转换失败只会抛这个。如果捕获Exception可能把内存错误、类型错误也一起吞了掩盖真正的 bug。还有一个进阶技巧用else和finally让意图更清晰。else块在 try 没抛异常时执行finally无论怎样都执行。比如文件操作try: f open(data.txt) except FileNotFoundError: print(文件不存在) else: try: content f.read() finally: f.close()不过实际写文件操作我更推荐直接用with语句它会自动关闭文件比手动 finally 更简洁try: with open(data.txt) as f: content f.read() except FileNotFoundError: print(文件不存在)4.3 函数返回值保持一致别一会儿 None 一会儿抛异常一个函数如果有时返回 None、有时抛异常、有时返回正常值调用方会非常痛苦。我的原则是要么统一用返回值表示失败比如返回 None 或特定哨兵值要么统一用异常不要混着来。一般来说“预期内的失败”用返回值“意外情况”用异常。比如查找用户找不到是预期内的返回 None 合理但数据库连接断了是意外抛异常合理。这个区分能让调用方的代码逻辑清晰很多。5. 调试、日志与性能工程化习惯的养成5.1 print 调试没错但 logging 更专业我不反对用 print 调试快速验证时它确实方便。但一旦代码要长期运行、要部署到服务器就必须换成 logging。原因有三print 没法分级、没法输出到文件、没法在发布时一键关闭。logging 的基本用法import logging logging.basicConfig( levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s ) logging.debug(调试信息生产环境不显示) logging.info(正常流程信息) logging.warning(警告可能有问题) logging.error(出错了)关键点是level参数。开发时设成 DEBUG能看到所有细节上线后设成 INFO 或 WARNING自动过滤掉噪音。这个开关是 print 做不到的。我踩过的一个坑不要在日志里用 f-string 直接拼接而应该用占位符。因为 f-string 无论日志级别如何都会先求值如果那个表达式很耗时比如序列化大对象就白白浪费了性能。用%s占位符的话只有真正要输出时才会格式化。# 不推荐无论是否输出都会执行 repr(big_object) logging.debug(f对象内容: {big_object!r}) # 推荐只有 DEBUG 级别启用时才格式化 logging.debug(对象内容: %r, big_object)5.2 性能优化先测量再动手新手最容易犯的性能错误是“凭感觉优化”。觉得某个循环慢就花半天改成推导式结果发现瓶颈根本不在这。正确的做法是先用工具测量找到真正的热点再优化。Python 自带的timeit模块适合测小段代码import timeit # 测两种写法的耗时 t1 timeit.timeit([x * 2 for x in range(1000)], number10000) t2 timeit.timeit(list(map(lambda x: x * 2, range(1000))), number10000) print(f推导式: {t1:.4f}s, map: {t2:.4f}s)对于整个函数的性能分析用cProfileimport cProfile def slow_function(): total 0 for i in range(1000000): total i ** 2 return total cProfile.run(slow_function())它会输出每个函数调用的次数和耗时一眼就能看出瓶颈在哪。我做过不少优化经验是80% 的性能问题集中在 20% 的代码上找到那 20% 比盲目优化所有代码有效得多。5.3 常见问题速查表我把这些年带新人时被问得最多的问题整理成一张表方便你对照排查。现象可能原因排查方向函数多次调用结果互相影响默认参数用了可变对象检查def f(x[])这类写法循环里修改列表导致漏元素遍历时增删元素改用副本遍历或推导式重建中文乱码文件编码不一致统一用 UTF-8open 时指定 encoding导入模块报 ModuleNotFoundError路径或虚拟环境问题确认 sys.path 和当前环境程序占用内存持续增长循环引用或缓存未清理用 gc 模块检查审查全局缓存浮点数计算结果不精确二进制浮点表示误差金额计算改用 decimal.Decimal这张表里的每一条我都在真实项目里遇到过。尤其是浮点数那条涉及金额计算时用 float 是灾难0.1 0.2 ! 0.3这个经典例子背后是二进制无法精确表示十进制小数。金融类场景一定要用decimal模块。6. 一些让我少走弯路的实操心得前面讲的都是相对“硬”的知识点最后这部分我想聊几个偏经验的东西都是我自己踩坑踩出来的。第一虚拟环境不是可选项是必选项。我早期图省事所有项目共用一个全局环境结果 A 项目要 requests 2.20B 项目要 requests 2.28升级一个另一个就崩。后来养成习惯每个项目建独立虚拟环境用python -m venv .venv一行搞定再也没出现过依赖冲突。这个习惯的成本极低收益极高。第二写代码时多想一步“别人会怎么用”。比如你写一个函数参数传 None 会怎样传空字符串会怎样传超大数字会怎样把这些边界情况在脑子里过一遍很多 bug 在写的时候就能避免。我现在 review 自己的代码第一件事就是看边界处理。第三善用if __name__ __main__:。这个写法很多人知道但不用。它的作用是让模块既能被导入、又能直接运行。如果你在模块顶层直接写执行代码别人 import 你的模块时那些代码也会跑非常烦人。把执行逻辑放进这个判断里是模块化的基本素养。第四注释写“为什么”不写“是什么”。i 1 # i 加一这种注释毫无价值代码本身已经说清楚了。有价值的注释是解释“为什么这里要加一”——比如“补偿索引从 0 开始的偏移”。注释应该承载代码表达不了的意图。第五定期重构别等代码烂透。我见过太多“先能跑就行以后再整理”的项目最后都变成了没人敢动的祖传代码。我的做法是每完成一个功能花十分钟看看有没有可以抽出来的重复逻辑、有没有可以改得更清晰的名字。小步重构的成本远低于大修。这些心得没有一条是“技术难点”但每一条都实实在在影响代码质量和开发效率。Python 这门语言入门容易写好难难就难在这些细节的积累上。标题里那个“你应该知道”说的其实就是这些——不是语法书上的知识点而是真正写代码时用得上的判断力和习惯。