橙心橙怡写代码这些年，我越来越觉得“优雅”不是审美问题，而是成本问题。你这段代码写出来，真正读它的不是机器，而是下一位维护者——极大可能，那就是六周后的你自己。很多人一提“代码优雅”就想到设计模式、函数式编程、架构重构这些重家伙，但实际工作中，能让代码从“能跑”到“好用”的，往往是几十个又小又具体的习惯。我整理了很久，把日常Review和写代码过程中真正会反复用到的点收拢成了50个小技巧，按命名、函数、重复、条件、错误、并发、习惯这条线串起来。这套东西我不追求讲得多高深，每个点拿出来都能马上用，适合刚工作不久想把代码写干净的初学者，也适合带团队想统一代码风格的负责人参考。
那先回答一个问题：到底什么叫“优雅代码”？这个标准如果不定义清楚，后面讨论就会变成玄学。
1. 先把“优雅”翻译成三个可度量的词
如果只说“代码要好读、好维护”，很容易落空，因为这两个词不同的人会有完全不同的理解。我的标准一直很简单，就三条：
第一，定位成本低。线上出了问题，你能顺着报错信息几分钟内找到对应代码块。如果每次排查都要全局搜索 temp1、result2 然后顺着逻辑推理半天，那不管你用什么设计模式都算不上优雅。
第二，修改成本低。产品提一个新需求，如果你要动的地方是局部的、集中的，不需要牵连七八个文件，那说明当前的划分是健康的。反过来，哪怕只是改一个显示格式，都要顺着调用链改上五层，那代码结构基本已经恶化了。
第三，出错概率低。代码读起来顺不顺，直接影响写的人会不会在边缘条件上栽跟头。一个函数有七层嵌套、五个标志位互相影响，你再小心也难保证不破坏某种状态；而结构扁平、边界清晰的代码，人不容易犯错，也不太会给后来者挖坑。
有个简单的自测方法：把你写好的代码放一个月再回来看。如果你需要靠 git log 或者当时的需求单才能想起来这段逻辑在干嘛，大概率是当时写得太“自嗨”了。不要觉得代码写完能跑就万事大吉，能跑只是起点，能让下一个修改它的人不骂人才算合格。
这50个小技巧，本质上都是在为这三条服务。下面我就按代码从命名到函数、从逻辑到维护的顺序，一条条聊。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 命名是代价最低的重构：把“读得懂”当成底线
我见过最让人崩溃的代码，不是逻辑复杂，而是变量名和人玩捉迷藏。之前帮同事Review一段支付相关的脚本，变量叫 a、b、c，函数叫 deal、doIt、handleIt。我对着需求的Excel表格一个个猜，最终才确认 a 是金额、b 是费率、c 是结算结果。命名这件事不需要任何框架知识，也不需要大块时间重构，纯粹是写的时候多花十秒钟，就能省掉别人半小时。这一节我把命名相关的经验一次性讲透。
小技巧01：变量名要能大声读出来，而不是靠记忆力解码。 用 userId、userName、totalAmount 这种词，任何人在任何地方看到都能立刻理解；反过来，uid 还算常见，但 u_id、usrid、user_id_2 这种风格混用的名字就非常折磨人。尤其是拼音缩写，比如 je（金额）、dh（订单号），除了你没有人能读懂，甚至你自己过两个月也未必还记得。给变量起名时先在心里念一遍，如果念出来你自己都觉得含糊，那就得换。
小技巧02：布尔变量用 is / has / can 这类词开头。 这样变量本身就是一句话的描述：isActive、hasPermission、canRetry、allowOverride。看到 if isActive: 你不需要额外翻译，但如果你写的是 if flag == 1:，读者就要先去翻 flag 是在哪里赋的值、1 又代表什么。另外尽量不要用否定形式的布尔名，比如 notFound、noError，一旦遇到 if not noError:，读起来简直像绕口令。
小技巧03：作用域越大，命名越要完整。 一个只在循环体三行里用的临时变量叫什么都可以，i、j、item 完全没问题；但一个贯穿整个模块的全局状态，如果你也叫 data 或者 res，那灾难就开始了。经验法则是：一个变量的可见范围越大，它的名字就要携带越多的信息，比如 userProfileById 好过 profile，paymentRetryCount 好过 count。
小技巧04：集合类型尽量用复数或在名字里点明结构。 userList、categoryMap、tagSet、allOrders，读者一看就知道遍历出来是什么东西。最怕的是所有集合都叫 list 或 arr，然后在某个函数里你对它做了 map 变换，后面的人根本不知道该传入什么结构。名字里带上了结构信息，很多错误在阅读阶段就能被拦住。
小技巧05：函数名用动词开头，明确表达动作。 sendEmail()、fetchUserProfile()、validateInput()、calculateTotalPrice() 都是好名字，因为函数本身就是对某个行为做封装。写代码时少用 processData()、doSomething()、handleRequest() 这种“万能动作”。如果你发现很难给函数起一个准确的动词，往往说明这个函数要做的事情本身就不清晰，这是比命名更严重的问题。
小技巧06：单位、量纲最好直接塞进命名里。 以前处理支付时吃过一次亏，两个服务之间传金额，一个按“分”传，一个按“元”收，结果所有人盯着数值都对不上账。后来统一改成 amountInCents、priceInYuan，这类问题基本绝迹。同样的还有 timeoutSeconds、maxSizeBytes。名字里带上单位，会让单位转换错误在Review阶段就暴露——因为人眼扫到 timeoutSeconds = 300，很容易和一目了然的 timeout = 300 形成不同预期。
小技巧07：不要用 data、info、result 这些万能桶给变量兜底。 不是说完全不能用，而是它们太没有辨识度了。一个类或者一个函数里出现三四个 result，每个 result 依赖上下文才能区分，脑子稍一放松就会用错。取名为 orderResult、paymentInfo、apiResponseData 并不会多花多长时间，却能让你在复杂逻辑里减少无数猜谜时间。
小技巧08：成对出现的操作要用同一套词根。 有 open() 就要有 close()，有 start() 就要有 stop()，有 increment() 就要有 decrement()。设计函数时如果语言或框架没有强约束，也尽量不要一会儿用 launch()、一会儿用 begin()，读者会怀疑这俩到底是不是一回事。维护过开源项目的人应该深有体会，API 命名的一致性直接影响使用者心智。
小技巧09：能用命名说清楚的事，就不要靠注释补。 假设你要写 # 这里的价格是已经含税的价格，为什么不直接把变量叫 priceWithTax？注释应当解释“为什么”，比如“这里不用缓存是因为订单状态经常变动”，而不是解释“是什么”。如果变量名已经需要注释来解释，那优先改名，而不是写注释。注释会腐烂，和代码脱节，可名字就写在代码里，它必须每时每刻都对。
小技巧10：类名和模块名回答“它是什么”，函数名回答“它做什么”。 所以类名多用名词，比如 EmailSender、PriceCalculator、OrderRepository，而不是一堆 Util、Manager、Helper 大杂烩。你自己回想一下，多少人把所有无家可归的静态方法都塞进一个 Utils 类里，最后那个类几百个方法，比垃圾场还难翻。如果你发现自己写了一个叫 CommonUtils 的类，停一停，想想里面的东西到底该怎么按业务拆开。
3. 函数干净不干净，看边界而不是行数
网上经常有“函数不能超过20行”这种教条，但说实话，这种硬性规定很容易把人带偏。我见过有人为了压行数，把一个业务逻辑拆成了十几个互相调用的小函数，读者要把代码跳来跳去拼接半天才看明白本来想干嘛。判断一个函数是否健康的准绳不在于多少行，而在于它有没有清晰的边界：输入输出是否明确、职责是否单一、副作用是否可控。这一节我按函数设计常犯的毛病来梳理。
小技巧11：一个函数只做一件事，判断标准是“能不能一句话说清”。 比如 public void createOrder(OrderRequest req) 你能一句话说清，它负责创建订单。如果描述变成“先校验订单合法性，再计算价格，然后保存订单，最后发送通知邮件”，那就说明它至少做了四件事。你说不清，代码自然就难读。解决办法是先按主流程把动作列出来，把每个动作各自抽成独立函数，然后让主函数像目录一样清晰。
小技巧12：边界的处理交给卫语句，别让主流程被嵌套吞掉。 很多初学者喜欢写：如果条件满足就进入主流程；但更推荐的是反过来，先处理边界条件，不满足就直接返回。比如：
python复制def send_notification(user):
if user is None:
return
if not user.is_active:
return
if user.email is None:
return
# 主流程：真正发送通知
send_email(user.email)
这种“早些返回，把主要逻辑留在最外层”的模式，比三层 if 嵌套清晰得多。读者一看函数开头就知道有哪些前置条件，心里有数，不会一头扎进一堆括号里。
小技巧13：别用一个布尔参数切换函数内部的两种行为。 比如 sendMessage(reminder=True) 这种设计其实是在用参数强行合并两个本不该合并的逻辑。更好的做法是拆成 sendWelcomeMessage() 和 sendReminderMessage()，两个公共方法各自表达清晰的意图。如果它们底层有大量共享代码，可以抽一个私有函数接收内部差异参数，但公开出去的方法一定要直白。否则每个调用方都要靠“这个布尔值到底是什么含义”来猜。
小技巧14：优先写纯函数，也就是“同样的输入永远产生同样的输出，且不修改外部状态”。 纯函数的好处在于特别好测、特别容易定位问题。你不需要关心它是第几次被调用、之前有没有人改过全局变量。比如下面这种写法就很不纯：
python复制total = 0
def add_price(price):
global total
total += price
如果多处调用 add_price，最后 total 的值很难追踪。更推荐返回新值：def add_price(total, price): return total + price。真实项目里不可能所有函数都纯，但优先保证核心计算逻辑是纯的，你会省去大量的调试时间。
小技巧15：Python 里千万别用可变对象做默认参数。 这是新手最容易踩的坑。
python复制def add_item(item, items=[]): # 不好
items.append(item)
return items
这个 items=[] 只会在函数定义时创建一次，后续所有没传 items 的调用都共享同一个列表，结果就是你明明调了两次，却发现第一次的数据还在里面。正确姿势是：
python复制def add_item(item, items=None):
if items is None:
items = []
items.append(item)
return items
而且这么做还有一个额外好处：你顺便把“修改传入列表”的副作用也规避了。
小技巧16：函数不要偷偷修改入参。 同样是列表，list.sort() 会原地修改传入的列表，而 sorted(list) 返回一个新列表。很多语言里没有这么清晰的区分，你要尽量遵循一个原则：如果调用方传入一个对象，函数默认不应该修改它，除非函数名就明确表示这是一次修改操作。我在Review里看到不少人喜欢在函数里做 data["status"] = "done"，这会让数据的流向变得特别难跟踪。真要改，更好的方式是返回一个新结构：{**data, "status": "done"}。这样原数据没有被污染，调用方可以选择后续怎么处理。
小技巧17：参数超过三个，就要考虑用对象把相关参数包起来。 举个例子，一个搜索函数传了 keyword、category、sortBy、page、pageSize、filter，六个独立参数排在那里，调用的时候前后错一个位置就出事了。更合理的做法是抽一个 SearchRequest 数据类，把相关查询条件收拢在一起。这不只是为了减少参数个数，更是为了后续新增字段时不会波及所有调用方。
小技巧18：入口处校验输入，快速失败，不要让非法数据在系统里走很深。 如果你的函数要求 amount 必须大于零，那在函数开头就校验并抛出明确的错误，而不要带着这个非法值一路计算，最后出来一个极其诡异的结果。Python 里注意别依赖 assert，因为运行 python -O 时断言会被移除；关键校验请用显式的 if + raise ValueError(...)。
小技巧19：返回值类型要保持稳定，别一会儿返回对象一会儿返回 None。 很多老代码的经典问题就是“查询成功返回 User，失败返回 None”，于是所有调用方都必须写 if user is not None 来防御。更好的做法是：如果你预期可能查不到，可以返回一个 Optional[User] 并让调用方显式处理；如果你确认查不到属于异常情况，就直接抛出异常。最怕的是同一函数里既返回 None 又返回 False，调用方根本猜不到你失败时究竟给什么。
小技巧20：高层函数只做流程编排，不要让细节混在同一个层次。 如果你在一个 process_order 函数里看到十几个字段拼接、看到 SQL 语句、看到发邮件逻辑，那个函数的抽象层级就乱套了。理想状态下，高层函数读起来应该像一段业务说明：
python复制def process_order(order):
validate_order(order)
charge_payment(order)
reserve_stock(order)
send_confirmation(order)
至于每一步具体怎么实现，到各自的低层函数里再看。这样哪怕你对业务不熟，也能一眼看出整条流程的骨架。
4. 当重复开始发臭：抽离的时机比手法更关键
“不要重复自己”是每个程序员最早听到的原则之一，但讽刺的是，很多人把它做成了另一种灾难：一看到相似代码就急着抽公共函数，结果抽出来的抽象层级奇高，参数一大堆，改一处还要担心另外几个场景是不是受到牵连。我的经验是：重复本身不是最可怕的，真正可怕的是你在不确定它们未来是否会同向演化的情况下，强行把它们焊在一起。这一节聊的更多是抽离的时机和判断依据。
小技巧21：抽函数前先问一句：这两段代码以后会一起变吗？ 如果答案不确定，宁可先留着重复。比如两个接口都有一段“把金额转成字符串”的逻辑，这个大概率以后会一起调格式，可以抽；但两段代码碰巧都是先取用户再取订单，不代表它们有共同抽象——一个以后可能改成优先读缓存，另一个可能改成批量查询，这种“偶然重复”强行合并反而是祸根。
小技巧22：抽出来的粒度，要以“一个业务动作”为单位。 不是看到几行很像就把它们截出来丢进 common.py。判断标准很简单：这个被抽出的函数能不能用一个业务动词命名？如果只能叫 helper1、commonProcess，那说明你其实还没想清楚它在业务上到底是什么。代码可以散落，但语义必须有归属。
小技巧23：能用表/字典驱动的事情，不要再写一长串条件分支。 比如之前做支付渠道接入，每个渠道的费率不一样，有些人会写：
python复制if channel == "alipay":
rate = 0.006
elif channel == "wechat":
rate = 0.006
elif channel == "card":
rate = 0.028
一旦渠道多了，这个函数就会越来越肥。更简单的写法是定义一张映射表：
python复制CHANNEL_RATE = {
"alipay": 0.006,
"wechat": 0.006,
"card": 0.028,
}
rate = CHANNEL_RATE[channel]
表驱动带来的好处是，业务数据集中在一起，后续调整费率只改这一处，新增渠道也只是加一行。
小技巧24：面对同形状数据的重复处理，用循环和表结构来消灭。 我有一个比较典型的场景：表单里有多个时间字段需要做格式校验和默认值兜底。初学者会一个字段一个字段写校验，代码长得像复读机。如果你把它们放进一个字段配置列表，然后写一个统一的处理循环，整个函数会短很多，也更容易加字段。很多人对循环有偏见，觉得它性能差，但这里面的差距绝大多数时候不值得你手动展开代码。
小技巧25：能用标准库解决的问题，尽量别自己造轮子。 排序、日期处理、字符串格式化、URL解析、集合操作，标准库都是经过成千上万项目锤炼过的，边界条件处理得比你想象中周全得多。自己实现一个快速排序作为练习没问题，但在业务代码里手写排序还写错比较函数，就有点说不过去了。当然，阅读源码是好事——了解轮子怎么转能帮你用得更准，但生产代码优先选成熟方案。
小技巧26：善用 map / filter / 列表推导这类函数式手段。 一段循环加临时变量加条件判断，很多时候能压缩成一个清晰的表达式，例如：
python复制# 不推荐：传统循环包了一大堆临时变量
result = []
for order in orders:
if order["status"] == "paid" and order["amount"] > 0:
result.append(order["amount"] * 0.9)
# 推荐：意图聚合在一个表达式里
discounted = [
round(order["amount"] * 0.9, 2)
for order in orders
if order["status"] == "paid" and order["amount"] > 0
]
但你要注意一个度：函数式链条不要接得太长，如果一行里出现五六个方法链、三层推导，大家反而看不懂。这时拆成有名字的中间变量更友好。
小技巧27：配置信息要单一来源，别让同一个值散落在多处。 一个超时时间，可能出现在代码常量、配置文件、数据库设置里，改漏一处就会出诡异问题。我的做法是：能收进一个常量或配置文件里的，就不在业务代码里写魔法值；如果这个值必须在多个服务间共享，宁可做一个统一配置下发机制，也不要让每个服务各维护一份。很多线上的疑难杂症，追到根因就是对同一配置的理解不一致。
小技巧28：警惕“万能工具类”成为新的隐藏重复。 每当你发现 Utils、Common、Helper 这种类越来越膨胀，就要意识到它其实是个收纳筐，里面堆满了各种没有归属的方法。工具的命名同样应该按业务或技术能力划分，例如 DateUtils、StringUtils、PaymentUtils 都还可以接受，但一个 MyUtils 里面有五十个不相关的方法，代码的组织性已经出问题了。
5. 条件逻辑的减负手术：别再一层层套娃了
我看过一段业务代码，功能无非是根据订单状态发不同通知，但硬生生写成了四层嵌套，每层都要判断两个以上条件。当时改一个需求，我在里面绕了快一个小时，最后不得不把整个函数打散重写。条件逻辑是最容易拖垮可读性的部分，但也是最有规律可循的部分。这一节给出七个实操性很强的减负技巧。
小技巧29：嵌套超过两层，先尝试用卫语句拍平。 这不是说所有嵌套都不能超过两层，而是当 if 里套 for 再套 if，再套一个 try，人的大脑处理不过来了。观察一下你写嵌套代码的动机：多半是想把“满足所有条件才执行主逻辑”描述清楚。换一个角度，把每个不满足的条件都当作提前退出的理由，代码就会像阶梯一样一级级往下走，而不是一圈圈往里钻。
小技巧30：给复杂的布尔表达式起个有业务含义的名字。 一段条件如果长得像 if user.is_active and not user.is_blocked and user.created_at < now and user.role in ("admin", "member")，最好抽出变量：
python复制can_apply_refund = (
user.is_active
and not user.is_blocked
and user.created_at < order.created_at
and user.role in {"admin", "member"}
)
if can_apply_refund:
...
你甚至可以把这段判断抽成一个函数，方便测试。重点是读者不需要逐字解析一长串逻辑，读一个名字就能明白意图。
小技巧31：能查表就不写长链式判断。 比如把状态码翻译成描述信息，不同支付渠道的映射字段，不同错误码对应的处理策略。用字典/表结构组织这些映射后，扩展和修改变得非常直接。很多人会觉得“我这个逻辑不是单纯查表”，那你可以把表里的值定义为“处理策略对象”或“函数引用”，既保留查表的简洁，又能应对不同的行为分支。
小技巧32：定期删除死代码和永远无法进入的分支。 有些条件分支写上之后就再也没被触发过，比如某个老渠道下线后，代码里还留着对它的完整判断。这些死分支不会让程序直接出错，但它们会让每个后续阅读者多消耗脑力去猜测“什么情况下会走到这里”。版本管理工具就是用来帮你找回历史代码的，不要怕删，不要用注释把一段逻辑“冻结”在那里。
小技巧33：正面表达优先，负负得正最容易让人迷糊。 if not user.is_blocked: 还好，但如果紧接着 if not not_found:，这就是逼读者心算。处理边界时，建议把“不要做什么”翻译成“提前排除什么”。比如：
python复制# 不太舒服
if not user.is_blocked:
send_message(user)
# 直接返回负向条件，旁边的人不需要继续分析
if user.is_blocked:
return
send_message(user)
用后者，阅读者看到 is_blocked 就直接跳过了主流程，不需要在脑子里做否定转换。
小技巧34：如果分支是在区分对象的类型，优先考虑多态而不是到处判断。 比如一个媒体文件系统，要根据音频、视频、字幕生成不同的处理流程。如果所有调用方都写上 if media_type == "video" then ... elif media_type == "audio" then ...，每新增一种类型就要改所有调用点。这时可以让每种媒体类多态地实现自己的 process() 方法，高层调用只依赖一个统一的接口。多态的手法听起来比前面的技巧重一些，但业务里类型分叉一旦增长，用多态收口往往是最优雅的方向。
小技巧35：标志位太多，说明状态管理出了问题。 如果你在一个类里看到 isLoading、isError、hasRetried、isModalOpen 同时被多个方法改来改去，那控制流会变成一个迷宫。一个典型的反模式是“用布尔值手动模拟状态机”。更好的做法是显式定义一组状态，例如 订单状态 从 PENDING 到 PAID 到 SHIPPED，状态之间的转移规则集中管理。手动维护四五个相互影响的布尔值，迟早会在某个组合状态上出错。
6. 错误处理的目标不是“不崩”，而是“三分钟内定位”
说句实话，代码写多了，你不会指望它永远不报错，但你一定希望它出问题时别让你大海捞针。很多项目的错误处理做得很糙：要么所有异常混成一个，要么捕获后打一行日志就吞掉了。真到线上出故障，你翻着日志，看到一排 Exception occurred，完全不知道是哪个用户、哪个订单、哪个环节出的问题。这一节聊聊如何让错误处理变成可观测的工程，而不是一种摆设。
小技巧36：except 之后不要一吞了之。 我理解有时候你确实想忽略某种非关键错误，比如监控上报失败不应阻断主流程。但“忽略”必须是主动决策，最好在代码里注释为什么可以忽略，并且至少要保证这条路径有日志或指标可以观测。最怕的是 try ... except Exception: pass，程序看起来没崩，但实际功能已经残缺，用户都在反馈了运维还看不到日志。这种吞错代码比报错更危险，因为它把问题藏起来了。
小技巧37：异常的粒度要跟着业务动作走，不要全统一成一个“系统异常”。 比如用户上传文件时，磁盘满了、文件格式不对、文件太大，这三种错误的处理方式是截然不同的。如果你把它们都转成一个 UploadError，调用方就无法针对不同场景做不同提示和重试。写代码时先问一句：这个错误是谁会处理，他需不需要区分具体原因？如果答案是“需要”，就尽量保留细分异常类型，别嫌麻烦。
小技巧38：用户看到的提示和系统日志要分开。 给用户看的是“网络开小差了，请稍后重试”，日志里记的却是完整的堆栈和质量、数据库连接池的信息。很多人把服务端异常原样返回给前端，等于把系统内部肌肉照了个X光，既不安全也不专业。反过来，日志里如果只写一句“操作失败”，那排查人员会想打人。内部日志要足够详细，至少包括用户标识、请求参数、失败原因、堆栈。
小技巧39：自定义异常可以带上足够的上下文。 比如：
python复制class InsufficientBalanceError(Exception):
def __init__(self, account_id, balance, required):
self.account_id = account_id
self.balance = balance
self.required = required
super().__init__(
f"account {account_id} balance {balance} < required {required}"
)
抛出这个异常时，日志里就已经带着账号和余额数据，再配合一个 logger.exception(...)，你完全不用重新去查数据库就能明白发生了什么。写一个带上下文的自定义异常，成本其实很低，但回报很高。
小技巧40：尽早失败，别让非法值在系统里旅行。 假设一个接口需要 userId，但调用方传了空字符串，这个空值如果在入口处没被拦住，可能会在层层传递后变成一个奇怪的数据库查询条件，然后返回一个让人摸不着头脑的空结果。你要做的是在入口就写清楚校验逻辑并抛出可读的错误，比如 raise ValueError("user_id must not be empty")。通常系统底层对非法值都是束手无策的，能在接口层解决的问题别指望它到后面自愈。
小技巧41：该释放的资源，交给语言机制而不是人的自觉。 在 Python 里用 with open(...) as f，在 Java 里用 try-with-resources，在 Go 里用 defer，在 C++ 里用 RAII。这些模式保证了即使中途抛异常，资源也能被正确释放。很多人习惯手动 close()，然后在某个提前 return 的分支里忘记释放资源，开发环境可能没事，线上跑一段时间就会冒出“文件句柄泄漏”“连接池耗尽”这种疑难杂症。能交给机制的，不要靠脑子记。
7. 异步和并发里的克制力：别让等待时间白白叠加
这几年后端业务里异步用得越来越多，很多人一上来就用线程、加锁，搞得很复杂；实际上大部分场景只需要理解几个底层原则就能写出又稳又清晰的代码。异步优化的核心其实很简单：不相关的等待不要排队，共享的资源不要乱抢。这一节我只讲四个我在代码里反复用到的点，每一个都解决过真实的问题。
小技巧42：能用 async/await 的时候，就别手动开线程去等结果。 写一个网络请求，如果用了阻塞式库，再套上多线程模拟并发，很容易触发一系列的共享变量问题，排查成本非常高。async/await 让你在单线程里用事件循环管理多个等待，代码看起来还是顺序写的，但底层并不会白白卡住。Node 生态和 Python 的 asyncio 都提供了相当成熟的支持。要注意的是，Python 里的阻塞调用会卡住整个事件循环，所以需要异步库配套使用，不要混着乱用。
小技巧43：互不依赖的异步调用，要尽早并发调度，不要写成顺序 await。 这是我看过最常见的性能浪费：
python复制profile = await fetch_profile(user_id)
orders = await fetch_orders(user_id)
fetch_profile 和 fetch_orders 彼此无关，却在这里变成了“一个跑完再跑另一个”，总耗时是两份网络延迟的叠加。正确做法是：
python复制profile_task = asyncio.create_task(fetch_profile(user_id))
orders_task = asyncio.create_task(fetch_orders(user_id))
profile, orders = await asyncio.gather(profile_task, orders_task)
两件事的等待时间重叠起来，总共只花差不多一份网络延迟的时间。这个优化不会让代码变复杂，收益却非常直观，写异步时养成“发现无关调用就上并发调度”的习惯。
小技巧44：并发任务要有上限，不要一次把整个列表全部打出去。 比如要给一万个用户群发通知，如果你用 asyncio.gather(*[send(user) for user in users])，相当于同一瞬间发出一万个请求，很可能直接把下游服务打崩。正确做法是使用 asyncio.Semaphore 限制并发数，比如每次最多运行 20 个任务，处理完再放下一批进来：
python复制sem = asyncio.Semaphore(20)
async def bounded_send(user):
async with sem:
await send(user)
await asyncio.gather(*(bounded_send(u) for u in users))
这里 20 只是示例，具体数值要看下游服务的承受能力。控制并发度不是怕麻烦，而是对下游系统的基本尊重。
小技巧45：任何外部 IO 都要设置超时，并且把超时当作正常流程来处理。 网络请求、数据库调用、消息队列消费，都不能无限等下去。一个没有超时的请求挂在那里，会慢慢吃光连接池，最后整个服务雪崩。设计时应该有个默认超时时间，比如 5 秒；超时之后进入重试逻辑或熔断逻辑，而不是一直干等。很多初学者把超时当作“不敢想的情况”，但真实环境里慢请求、挂起请求才是最常见的故障源。
8. 真正拉开差距的，是提交、Review与小步重构这些日常动作
前面聊了命名、函数、控制流这些“写在代码里”的技巧，但代码不是凭空变成好代码的——它是通过一次次的提交、Review 和重构逐渐演化的。很多项目前期写得挺规矩，结果三个月后烂成一锅粥，不是谁突然技术变差了，而是日常动作没有跟上。最后一节说说那些看起来不起眼但对代码质量影响最大的习惯。
小技巧46：提交之前，重读一遍自己的 diff。 这是成本最低的代码走查方式。你写完代码时的思维是连贯的，但提交前再看一眼改动列表，很容易发现自己留下了 debug 日志、改了一半的变量名、或者一段根本无用的注释。很多规范问题其实在提交前就能自我发现，不需要麻烦别人来 Review。也建议提交信息里说清楚“改了什么、为什么”，不要总写 update、fix 这类没营养的话，这会让你三个月后翻历史时摸不着头脑。
小技巧47：格式化交给工具，人工精力留给逻辑。 团队里经常有人为了缩进、空格、单双引号吵架