性能优化第一刀：先改代码降复杂度，还是先加资源扛过去？

【背景】 接了一个性能需求：QPS 要翻倍，或者 P99 必须压到某个值，成本还得压一压。团队里立刻分成两派。一派说"先扩容、升配、加缓存、调连接池/线程池/超时，代码别动，动代码风险大、排期长"；另一派说"加机器是治标，先把 O(N²) 的循环、N+1 查询、全表扫描干掉，性能上去了成本还降了"。我这两年多，亲眼见过这两种路线各自翻过车，也见过两种路线最后殊途同归。所以想借这个帖子把大家的真实选择摊开聊聊。

【常见分歧 / 几种做法】

1. 资源派：横向扩容、升配、加缓存、调连接池/线程池/超时/重试。优点是快、可控、可回滚、基本不动业务代码；缺点是成本线性涨，而且很可能只是把真正的瓶颈藏起来了——你只是把水从杯子倒进了桶，桶也快满了，下次流量峰值还得再交一次"过路费"。
2. 代码派：降算法复杂度、合并查询、减少序列化/网络往返、去掉无谓的同步锁。优点是单位成本下来、一劳永逸、还能顺带降本；缺点是改动面大、回归风险高、排期长，线上还压着真实流量，动错就是事故。
3. 折中派：先加资源止血、保住线上，再排期改代码治本。听起来最稳，但现实里"再排期"经常变成"永远排不上"，最后系统一直靠堆资源活着。

【我的倾向与理由】 我这两年的经验是——先定位瓶颈，再决定动哪一刀，而不是先选流派。绝大多数线上 P99 抖动，耗时其实很集中（往往 80% 的时间花在 20% 的代码 / 依赖上）。如果瓶颈是算法 / 查询本身，加资源只是把崩溃时间往后推；如果瓶颈在外部依赖（DB、RPC、GC、网络、连接池），改代码也救不了，该加资源 / 换架构就得加。所以我的判断顺序是：先用压测 / 线上 trace 定位 Top 耗时 → 判断这是"单位成本"问题（改代码更划算）还是"总量"问题（加资源更直接）→ 能改代码就改代码，改不动或来不及才加资源。加资源永远是"止血"，改代码才是"治本"，但治本必须带 deadline，否则线上扛不住、人也没耐心改。

【想听大家在什么场景下怎么选】

• 你们团队遇到"QPS 要涨 / 要降本"时，第一反应是加机器还是改代码？为什么？
• 有没有"加资源扛了半年，最后发现根本不用加、代码改一下就够了"的反例？
• 反过来，有没有"急着改代码、结果线上炸了、又退回加资源"的踩坑？
• 小团队（人少、没有专职性能 / DBA）和大团队，这个决策会不会不一样？
• 在"大促 / 流量不可控"这种场景下，你们更信哪一派？

贴出你的场景和最终选择，最好带点数据（改前改后的 P99 / 单实例 QPS / 机器成本），大家一起对照，比空谈"看情况"有用得多。