Tina 小姐姐做了这么多年后端开发，我听过最多的一句话是“先跑起来再说”。这句话成就了无数MVP，也留下了无数烂摊子。所谓开发效率与运行性能的平衡艺术，其实就是搞清楚什么时候该快，什么时候该慢。很多团队把性能优化当成上线之后的补救措施，以为先抢时间后补性能是理所当然。但现实是，等业务跑起来再回头处理性能问题，成本往往是提前注意的好几倍。这篇文章我打算从自己踩过的坑和总结出来的方法出发，聊聊怎么在写代码时保持开发效率，又别让线上性能失控。适合正在写业务代码、被线上性能问题反复折腾的开发者，也适合带团队做技术决策的同学。
1. “先跑起来再说”是怎么把系统拖垮的
1.1 为什么这句话如此流行
开发效率最直接的衡量标准，是功能从想法到上线的时间。产品要抢市场、业务要验证假设，所有人都希望今天提需求，明天就能用上。在这种节奏下，写代码时脑子里想的通常不是“这个查询会不会慢”，而是“怎么用最短的时间把流程打通”。这很正常，也不能全怪开发不够严谨。因为大部分场景里，业务能不能活下去，比系统是不是完美更重要。
但问题在于，“先跑起来”如果成为惯性，系统就会开始积累看不见的成本。最典型的就是N+1查询。一开始表里的数据只有几千行，循环查数据库根本感觉不到压力；等用户量上来，一个页面几十次查询，数据库连接池直接被打满。这时候你再想回头修，发现查询代码散落在十几个地方，要么改ORM配置，要么改调用逻辑，测试范围就像滚雪球一样越来越大。表面上你抢回了一周的上线时间，后面可能要花一个月来还。
1.2 技术债的利息比想象中高
我习惯把这种后补式优化称作“借了笔高利贷”。你提前透支的是运行性能，事后要还的是成倍的开发时间和排障精力。举一个我实际经历过的例子：一个报表功能当时赶着上线，只用了三天就写完了。结果三个月后，因为表数据量涨到几十万行，某个统计接口直接超时，整个管理后台都卡住。我们排查了两天才定位到一个隐性问题：有个统计SQL用了函数包裹索引字段，导致索引失效。然后修复加数据订正又用了两天。前后一周的时间，就为了还技术债。
所以我想说的并不是“所有东西都要在一开始就做得极其复杂”，而是要在开发过程中对性能保持敏感。比如写循环查询时，先想想能不能一次性查出全部数据；设计表结构时，多看一眼WHERE条件有没有匹配的索引；接口返回字段确定后，问一句“这个字段前端真用得到吗”。这些习惯不会让开发变慢，反而能让后续更省心。平衡艺术的第一课，就是把这种敏感变成肌肉记忆。
而且这类问题并不是只出现在新手代码里。有经验的开发也会因为业务压力选择“先打补丁、后补优化”。最难受的是，这种补丁往往不是一次性的。今天为了赶一个展示需求，直接在循环里加查询；明天为了修数据不对，又写了一个定时任务去刷数。补丁叠补丁，系统越改越难维护，性能也越来越差。到后来，哪怕你想做一次正经的重构，也没有人敢动了，因为谁都不知道拆掉哪一层会不会引爆下一个雷。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 用性能预算把模糊的“快”变成可量化的需求
2.1 性能预算是什么
很多团队做性能优化没有尽头，是因为没有定义“够了”。有人觉得接口200ms正常，有人觉得500ms能接受，所有人的标准都来自主观感受，自然容易吵架。性能预算的概念很简单，就是给系统定一个可量化的底线：比如“订单列表接口P95响应时间不超过200ms”“首屏渲染不超过1.5秒”“批量导入接口吞吐量不低于1000行/秒”。把这些数字写进需求文档，开发和测试就有了统一的判断标准。
性能预算的好处不只是定指标，它还能倒逼团队做取舍。当你知道核心链路P95不能超