性能优化方法论：从定位瓶颈到验证收益的完整实践

1. 从“更好的优化”这个标题说起“更好的优化”这四个字看起来像是一句正确的废话但恰恰是这种模糊的表述暴露了绝大多数人在面对性能瓶颈时的真实困境——知道自己需要优化但不知道从哪里下手更不知道什么才算“更好”。我做了十多年一线开发和技术咨询见过太多团队在优化这件事上反复横跳有人一上来就换框架、换数据库、换语言折腾了三个月QPS 只涨了 15%也有人只改了三行代码把某个循环里的重复查询提到外面接口响应时间直接从 800ms 降到 90ms。这两者的差距不在于技术能力而在于是否建立了一套可度量、可拆解、可验证的优化方法论。这篇文章想聊的就是怎么把“更好的优化”从一个口号变成一套可执行的动作。不管你是后端工程师、前端开发者、数据分析师还是做运维、做产品的同学只要你手头有需要提速、降本、提效的任务这套思路都能直接拿去用。我不会讲太多理论重点放在怎么找到真正的瓶颈、怎么判断优化收益、怎么避免“优化完反而更慢”的尴尬局面。全文会围绕四个核心环节展开——定位、拆解、实施、验证每个环节都会配上我实际踩过的坑和可复现的操作步骤。2. 优化之前先搞清楚“更好”的定义2.1 没有基线的优化都是耍流氓我见过最离谱的一次优化事故是一个团队觉得系统“太慢”花了两个月重构了核心模块上线后发现整体耗时反而增加了 20%。原因很简单他们从来没有测过优化前的真实数据凭感觉认为“慢”又凭感觉认为“重构后会快”。优化这件事第一步永远是建立基线。基线不是什么高大上的东西就是一组可重复测量的数字。比如接口的平均响应时间、P95 响应时间、每秒查询数、内存占用峰值、CPU 使用率曲线。这些数字不需要多精确但必须满足三个条件可复现、可对比、可归因。可复现的意思是你在同样的硬件、同样的数据量、同样的并发条件下每次测出来的结果波动不超过 5%。如果波动超过 10%说明你的测量方法本身有问题可能是测试数据随机性太大也可能是环境里有其他进程在抢资源。可对比的意思是优化前后的测量条件必须完全一致不能优化前用 4 核 8G 的机器优化后用 8 核 16G 的机器然后说“性能提升了 3 倍”——那是加机器加出来的不是优化出来的。可归因的意思是你要能说清楚这个数字变化是由哪个具体改动引起的而不是“我改了一堆东西反正快了”。实操建议用脚本把压测命令固化下来每次优化前后跑同一套脚本输出同一份报告。我习惯用 wrk 或 k6 做 HTTP 层压测用 py-spy 或 perf 做 CPU 火焰图用 explain analyze 看数据库执行计划。这些工具的具体用法后面会展开。2.2 优化的三个维度时间、空间、成本“更好”这个词之所以模糊是因为它没有指明方向。优化可以追求更快时间维度、更省空间维度、更便宜成本维度但这三者往往互相冲突。比如你把所有数据都缓存到内存里读取速度确实快了但内存占用上去了机器成本也上去了。再比如你用更紧凑的数据结构压缩存储省了磁盘但解压需要额外 CPU 时间。所以每次优化之前你必须明确这次优化的首要目标是什么次要目标是什么哪些指标可以牺牲我通常会把优化目标分成三档硬指标、软指标、可放弃指标。硬指标是必须达成的比如“接口 P95 必须降到 200ms 以内”软指标是尽量达成的比如“内存占用最好别超过 4G”可放弃指标是明确可以牺牲的比如“磁盘占用增加 30% 可以接受”。把这三档写下来贴在工位上优化过程中每次做取舍的时候都回头看一遍能避免很多无效争论。2.3 二八定律在优化中的真实体现帕累托法则在性能优化里体现得淋漓尽致80% 的耗时往往集中在 20% 的代码路径上。但问题在于那 20% 的代码往往不是你以为的那 20%。我做过一个统计在十多个不同的 Web 项目里开发者凭直觉猜测的瓶颈位置和实际 profile 出来的热点函数重合度只有 35% 左右。也就是说三分之二的情况下你花大力气优化的地方根本不是真正的瓶颈。所以“更好的优化”的第一个动作不是写代码而是测量。测量工具的选择取决于你的技术栈Java 用 async-profiler 或 JFRPython 用 cProfile 加 snakevizGo 用 pprofNode.js 用 clinic.js前端用 Chrome DevTools 的 Performance 面板。工具不重要重要的是养成“先测再改”的习惯。我见过太多人一上来就改代码改完发现没效果又改回去来回折腾最后项目延期自己也累得够呛。3. 定位瓶颈从“感觉慢”到“知道哪里慢”3.1 分层排查法从外到内逐层剥离系统慢可能慢在网络、慢在网关、慢在应用、慢在数据库、慢在磁盘。如果你一上来就盯着应用代码看很可能忽略了更外层的瓶颈。我习惯用分层排查法从最外层开始逐层往里剥。第一层是网络层用 curl 的 -w 参数或者 httpstat 看 DNS 解析、TCP 连接、TLS 握手、首字节时间、内容传输各占多少。如果 DNS 解析就花了 200ms那你优化应用代码到死也没用。第二层是网关和负载均衡层看有没有连接排队、有没有限流、有没有健康检查导致的抖动。第三层是应用层看线程池、连接池、GC 日志、锁竞争。第四层是存储层看数据库慢查询、索引命中、磁盘 IOPS。第五层是操作系统层看 CPU 上下文切换、内存换页、网络重传。每一层都有对应的工具和指标关键是不要跳层。我见过一个案例应用层查了半天没发现问题最后发现是 Kubernetes 的 readiness probe 配置太激进导致 Pod 频繁重启请求被反复中断。这种问题你在应用代码里永远找不到。3.2 火焰图一眼看出谁在吃 CPU火焰图是我最推荐的 CPU 瓶颈定位工具没有之一。它的原理很简单采样器每隔几毫秒抓一次调用栈把相同调用栈的样本合并用宽度表示占用 CPU 的比例。读火焰图的方法也很直观横轴是时间占比纵轴是调用深度最宽的那一块就是最耗 CPU 的函数。如果某个函数在火焰图顶部很宽说明它自己消耗了大量 CPU如果它在底部很宽但顶部很窄说明它调用的子函数消耗了大量 CPU。我实际用下来async-profiler 对 Java 应用最友好一条命令就能生成 HTML 格式的火焰图支持按包名过滤还能看锁竞争和内存分配。Python 的话py-spy 的 record 模式可以生成 speedscope 格式的火焰图对线上环境几乎零侵入。Go 自带的 pprof 更不用说了标准库直接支持。唯一要注意的是采样频率不要设得太高否则本身就会影响性能也不要设得太低否则样本不够统计意义不强。一般 10ms 到 100ms 之间比较合适。3.3 数据库慢查询最容易被忽视的重灾区应用层的火焰图只能告诉你 CPU 花在哪里但很多系统的瓶颈根本不在 CPU而在等待 IO。数据库慢查询就是最典型的例子。我做过一个粗略统计在中小型 Web 项目里超过 60% 的响应时间花在数据库查询上而其中又有超过一半的查询是没有走索引的全表扫描。更可怕的是很多 ORM 框架会自动生成 N1 查询你在代码里只写了一个循环背后却发了几百条 SQL。定位慢查询的方法因数据库而异。MySQL 可以开 slow_query_log设置 long_query_time 为 0.1 秒跑一段时间后分析慢查询日志。PostgreSQL 可以开 log_min_duration_statement或者用 pg_stat_statements 扩展看累计耗时最长的查询。MongoDB 可以用 profiler 或者 explain 看执行计划。关键是要养成习惯每次上线新功能后隔一天去看一眼慢查询日志把新增的慢查询揪出来。我见过太多项目上线时好好的跑了三个月数据量上来了某个没加索引的查询突然变成全表扫描整个系统就崩了。避坑技巧不要只看单次查询耗时要看累计耗时。一个查询单次只要 10ms但每秒执行 1000 次累计就是 10 秒的 CPU 时间。用 pg_stat_statements 的 total_time 排序往往能发现这种“蚂蚁搬家”式的性能杀手。4. 拆解优化方案从“能跑”到“跑得好”4.1 缓存最有效但也最容易翻车的优化手段缓存是性能优化里的万金油用对了立竿见影用错了后患无穷。我先把结论放在这里缓存的核心不是“存什么”而是“什么时候失效”。我见过太多缓存事故根源都是失效策略没设计好。比如把用户权限信息缓存了 24 小时结果管理员把某个用户禁言了那个用户还能继续发言一整天。再比如把商品库存缓存了 10 分钟结果超卖了几百件。缓存的失效策略大致分三种定时过期、主动更新、写时失效。定时过期最简单但一致性最差主动更新一致性最好但实现复杂容易漏掉更新点写时失效是折中方案写数据的时候删缓存读的时候再重建。我个人的经验是对于变化不频繁、一致性要求不高的数据比如商品分类、城市列表用定时过期就够了过期时间设个 5 到 30 分钟对于变化频繁、一致性要求高的数据比如库存、余额要么不用缓存要么用写时失效加分布式锁。还有一个容易被忽视的点缓存击穿和缓存雪崩。缓存击穿是指某个热点 key 过期瞬间大量请求同时打到数据库。解决办法是加互斥锁只让一个请求去重建缓存其他请求等待。缓存雪崩是指大量 key 同时过期解决办法是给过期时间加随机抖动比如基础过期时间 10 分钟实际设置为 10 分钟加减 2 分钟内的随机值。这些技巧听起来简单但真正在代码里落实到位的人不多。4.2 异步化把“必须等”变成“可以等”很多性能问题本质上是因为同步等待。用户请求进来你调了三个外部接口每个接口平均 200ms串行执行就是 600ms。如果这三个接口之间没有依赖关系完全可以并行调用总耗时降到 200ms 出头。再进一步如果某个接口的返回结果不是用户立即需要的可以把它扔到消息队列里异步处理接口直接返回用户体验瞬间提升。异步化的关键不是“用了异步”而是“哪些能异步、哪些不能异步”。我的判断标准很简单如果这个操作的结果会影响用户当前看到的页面内容就不能异步如果只是发通知、写日志、更新统计就可以异步。比如用户下单扣库存必须同步因为库存不够要立刻告诉用户但发短信通知、更新销量排行完全可以异步。我见过一个反例有人把扣库存也异步了结果用户下单成功但库存没扣超卖了。这种优化就是负优化。4.3 批量化把 N 次变成 1 次批量化是另一个立竿见影的优化手段尤其适合数据库操作和远程调用。比如你要插入 1000 条数据逐条 insert 和批量 insert 的性能差距可能是几十倍。再比如你要查 100 个用户的信息循环里逐个查和用 in 一次性查差距同样巨大。批量化之所以有效是因为它减少了网络往返次数和事务开销。每次网络往返都有固定的延迟每次事务提交都有日志刷盘的开销批量处理把这些固定开销摊薄了。但批量化也有坑。第一个坑是批量太大导致内存溢出比如一次性查 10 万条数据放到内存里直接把 JVM 撑爆。解决办法是分批处理比如每 500 条一批循环处理。第二个坑是批量操作失败后的回滚问题比如批量插入 1000 条第 500 条失败了前面 499 条要不要回滚这取决于业务需求但必须在设计阶段就想清楚。第三个坑是批量操作可能锁住太多行影响其他事务需要控制批量大小和执行频率。4.4 算法和数据结构最根本但也最费脑子的优化前面说的缓存、异步、批量本质上都是“绕过”问题而不是“解决”问题。真正根本的优化是换一个更高效的算法或数据结构。比如把 O(n²) 的嵌套循环改成 O(n log n) 的排序加二分查找把链表改成哈希表把递归改成迭代。这类优化的收益往往最大但难度也最高因为需要你对业务逻辑和算法都有深入理解。我举一个实际案例。有个项目需要判断一个用户是否在某个百万级用户的名单里原来的实现是把名单加载到 List 里然后 contains 判断每次判断都要遍历整个 List平均耗时几十毫秒。后来改成用 HashSet判断时间降到微秒级。改动很小但效果惊人。再比如有个统计功能需要计算两个大集合的交集原来用双重循环数据量上来后直接卡死。后来改成先排序再用双指针求交集时间复杂度从 O(n²) 降到 O(n log n)处理时间从几分钟降到几秒。经验之谈算法优化不要追求一步到位先看能不能把 O(n²) 降到 O(n log n)再考虑能不能降到 O(n)。大多数业务场景下O(n log n) 已经足够好了没必要为了理论上的最优解把代码写得晦涩难懂。5. 实操过程一个真实项目的优化全记录5.1 项目背景和初始状态去年我接手了一个内容管理系统的性能优化系统是典型的 Java Spring Boot 加 MySQL 加 Redis 架构部署在 4 核 8G 的云服务器上。问题表现是文章列表接口在数据量达到 50 万篇后响应时间从最初的 200ms 涨到了 3 秒以上高峰期甚至超过 10 秒前端经常超时。运维那边看监控CPU 使用率常年 80% 以上MySQL 的 CPU 更是接近 100%。我先做了基线测量。用 wrk 压测文章列表接口100 并发持续 60 秒结果是平均响应时间 3.2 秒P95 响应时间 8.7 秒QPS 只有 31。然后开慢查询日志发现列表查询的 SQL 执行时间平均 2.8 秒。用 explain 看执行计划发现是全表扫描type 是 ALLrows 是 50 万。再看代码发现列表查询用了 ORM 的动态查询根据前端传的筛选条件拼接 where 子句但没有为所有可能的筛选组合建索引。5.2 第一步数据库索引优化数据库是最大的瓶颈所以先从数据库下手。我分析了慢查询日志里出现频率最高的几种查询模式发现主要是按分类、按标签、按发布时间排序这三种。原来的表只在主键上建了索引其他字段都没有索引。我根据查询模式建了三个联合索引category_id 加 publish_time、tag_id 加 publish_time、status 加 publish_time。建索引的时候注意了字段顺序把区分度高的字段放在前面范围查询的字段放在最后。建完索引后用 explain 验证type 从 ALL 变成了 rangerows 从 50 万降到了几千。再压测平均响应时间从 3.2 秒降到了 800msQPS 从 31 涨到了 120。效果很明显但还不够。因为列表查询还需要返回文章的作者信息、分类名称、标签名称这些数据分散在四张表里原来的实现是查完文章列表后循环里逐个查作者、分类、标签典型的 N1 查询。50 篇文章就是 200 次额外查询每次查询就算只要 1ms累计也是 200ms。5.3 第二步消除 N1 查询消除 N1 查询的方法很简单把循环里的单条查询改成批量查询。具体做法是先查出文章列表收集所有作者 ID、分类 ID、标签 ID然后用 in 查询一次性把作者、分类、标签都查出来在内存里做映射。这样 200 次查询变成了 3 次查询耗时从 200ms 降到了 5ms 以内。但这里有个细节要注意in 查询的参数不能太多。MySQL 对 in 列表的长度有限制虽然可以调但参数太多会导致解析开销增大。我的做法是分批查询每批 500 个 ID循环处理。另外查出来的结果要用 Map 存起来key 是 IDvalue 是对象这样在内存里做映射的时候是 O(1) 查找不会引入新的性能问题。改完 N1 后再压测平均响应时间降到了 400msQPS 涨到了 250。到这里数据库层面的优化基本到位了。但 400ms 对于列表接口来说还是偏慢用户能感知到明显的延迟。接下来要动应用层和缓存层。5.4 第三步引入 Redis 缓存列表接口的数据变化频率不高新文章发布后几分钟内被看到的概率不大非常适合缓存。我设计了三级缓存策略第一级是本地缓存用 Caffeine 存最热的前 100 个查询结果过期时间 30 秒第二级是 Redis 缓存存所有查询结果过期时间 5 分钟第三级是数据库缓存未命中时才查。缓存的 key 设计很关键。我用的是“接口名加查询参数哈希”的方式比如 article:list:category1tag2page1size20 的 MD5 值。这样不同的查询参数对应不同的 key不会互相覆盖。缓存的 value 用 JSON 序列化虽然比二进制序列化慢一点但可读性好排查问题方便。过期时间设了 5 分钟并且加了正负 30 秒的随机抖动防止缓存雪崩。引入缓存后压测结果大幅提升平均响应时间降到了 80msP95 降到了 200msQPS 涨到了 800。但这时候出现了一个新问题缓存和数据库的一致性问题。如果一篇文章被删除了缓存里还有用户会看到已删除的文章。我的解决办法是写操作发布、编辑、删除文章时先更新数据库再删除缓存而不是更新缓存。删除缓存比更新缓存更安全因为更新缓存可能因为并发导致旧数据覆盖新数据。5.5 第四步JVM 和连接池调优应用层还有一个容易被忽视的优化点JVM 参数和连接池配置。原来的 JVM 用的是默认参数堆内存只有 2GGC 用的是 Parallel GC每次 Full GC 都要停顿 1 秒以上。我改成了 G1 GC堆内存调到 4G设置 MaxGCPauseMillis 为 200ms。改完后Full GC 频率从每小时几次降到每天几次每次停顿控制在 200ms 以内。连接池方面原来用的是 HikariCP 默认配置最大连接数 10。在 100 并发压测下连接池经常被打满请求排队等待连接。我把最大连接数调到了 50最小空闲连接调到 10连接超时设为 3 秒。这里有个计算公式可以参考最大连接数等于 CPU 核数乘以 2 再加磁盘数。对于 4 核机器8 到 10 个连接其实就够了但考虑到网络延迟和查询耗时适当放大到 50 也没问题只要数据库能承受。调完 JVM 和连接池后最终压测结果平均响应时间 45msP95 响应时间 120msQPS 稳定在 1500 以上。从最初的 3.2 秒到 45ms提升了 70 倍。CPU 使用率从 80% 降到了 30%MySQL 的 CPU 从 100% 降到了 20%。5.6 优化前后的关键指标对比指标优化前优化后提升倍数平均响应时间3200ms45ms71 倍P95 响应时间8700ms120ms72 倍QPS31150048 倍应用 CPU 使用率80%30%降低 62%数据库 CPU 使用率98%20%降低 80%慢查询数量每小时12000100%这张表是我从监控系统里导出来的真实数据不是估算。我想说的是优化不是玄学每一步改动都有明确的数字支撑。你改了什么哪个指标变了变了多少都要能说清楚。如果改了一堆东西但指标没动那就要反思是不是改错了地方。6. 常见问题与排查技巧实录6.1 优化后反而变慢了怎么排查这是最让人崩溃的情况辛辛苦苦改了半天上线后监控显示响应时间不降反升。遇到这种情况第一件事是回滚第二件事是复盘。回滚要快不要犹豫先恢复服务再慢慢查原因。复盘的时候重点看三个地方是不是引入了新的锁竞争、是不是缓存命中率太低、是不是批量操作太大导致内存压力。我遇到过一次典型的“负优化”为了提高查询速度给一个频繁更新的表加了索引。结果写入性能大幅下降因为每次插入都要更新索引而那个表的写入量远大于读取量。这就是没有权衡读写比例的后果。索引不是越多越好每个索引都会增加写入开销。一般来说一个表的索引数量不要超过 5 个写入频繁的表更要严格控制。还有一个常见的负优化是缓存粒度太细。比如给每个用户、每个商品都单独缓存导致缓存 key 数量爆炸Redis 内存不够用开始频繁淘汰命中率反而下降。解决办法是调整缓存粒度把变化频率相近的数据合并缓存或者用更紧凑的序列化方式减少内存占用。6.2 压测结果和线上表现不一致怎么办压测环境再逼真和线上环境总有差异。常见的差异来源有数据量不同、网络延迟不同、其他服务干扰、硬件配置不同。我一般会做两件事来缩小差异第一压测数据量至少是线上数据量的 50%不要用几千条数据压测一个线上有百万条数据的系统第二压测时监控所有相关指标不只是响应时间还有 CPU、内存、磁盘 IO、网络带宽看看瓶颈是不是转移了。如果压测结果好但线上还是慢那就要怀疑是不是有外部依赖拖后腿。比如你的接口调了一个第三方服务压测时第三方服务响应很快线上却因为网络抖动或者对方限流变得很慢。解决办法是给外部调用加超时和熔断超时时间设短一点比如 500ms超过就返回降级数据不要让整个接口被拖死。6.3 优化到什么程度才算够这是一个哲学问题但也可以量化。我的判断标准是优化到“投入产出比开始明显下降”为止。具体来说当你花一天时间只能换来 5% 的性能提升时就该停下来了。因为继续优化的边际收益太低不如把时间花在功能开发或者代码可维护性上。我见过一些团队为了追求极致的性能把代码写得极其复杂结果新人看不懂改一个 bug 要花三天维护成本远超性能收益。另一个判断标准是优化后的指标是否满足业务需求。如果业务要求 P95 在 500ms 以内你优化到 200ms 就够了没必要非要压到 50ms。留一些余量给未来的数据增长和流量增长比把系统压到极限更明智。系统长期在高负载下运行出故障的概率会显著增加稳定性比极致的性能更重要。6.4 常见问题速查表问题现象可能原因排查工具解决方向响应时间突然飙升慢查询、GC 停顿、锁竞争慢查询日志、GC 日志、火焰图加索引、调 GC、减少锁粒度CPU 使用率高但 QPS 低死循环、正则回溯、频繁 GC火焰图、线程 dump优化算法、调 JVM 参数内存持续增长不释放内存泄漏、缓存无上限堆 dump、MAT 分析修复泄漏、加缓存淘汰策略数据库连接超时连接池太小、慢查询占满连接连接池监控、慢查询日志调大连接池、优化慢查询缓存命中率低缓存粒度太细、过期太快Redis 监控、命中率统计调整粒度、延长过期时间压测结果波动大测试数据随机、环境干扰多次压测取平均值固定测试数据、隔离环境这张表是我从十多个项目里总结出来的基本上覆盖了 80% 的常见性能问题。遇到问题的时候先对照这张表定位方向再用具体工具深入排查比盲目试错效率高得多。独家避坑技巧每次优化只改一个变量。如果你同时改了索引、缓存和 JVM 参数然后性能提升了你根本不知道是哪个改动起了作用。更糟糕的是如果性能下降了你也不知道该回滚哪个。我习惯的做法是改一个点压测一次记录数据确认有效后再改下一个点。虽然慢一点但每一步都踏实。7. 优化之外的思考可观测性和自动化7.1 没有监控的优化是盲人摸象优化做完不是终点上线后的持续监控才是。我见过太多项目优化上线后没人看监控过了两个月数据量涨了性能又不行了但没人知道是什么时候开始不行的。所以优化完成后必须配套做好监控。监控不需要多复杂但至少要覆盖四个黄金指标延迟、流量、错误率、饱和度。延迟看 P50、P95、P99流量看 QPS错误率看 HTTP 5xx 和异常数量饱和度看 CPU、内存、连接池使用率。监控工具的选择取决于你的技术栈。Prometheus 加 Grafana 是目前最流行的组合几乎什么都能监控。如果不想自己搭也可以用云厂商提供的监控服务。关键不是工具而是养成看监控的习惯。我每天早上到工位的第一件事就是花五分钟看一眼核心指标的昨日曲线有没有异常波动有没有新的慢查询。这个习惯帮我提前发现了好几次潜在的性能问题避免了线上事故。7.2 把优化经验固化成自动化检查一个人优化得再好也架不住团队里其他人写出新的性能问题。所以更高阶的做法是把优化经验固化成自动化检查让机器帮你守住底线。比如在 CI 流程里加一步慢查询检查如果新增的 SQL 没有走索引直接构建失败。再比如加一步接口性能回归测试如果某个接口的 P95 比基线高了 20%自动告警。这些自动化检查听起来复杂但实现起来并不难。慢查询检查可以用 pt-query-digest 分析慢查询日志接口性能回归可以用 k6 或者 JMeter 跑固定场景。关键是要把基线数据存下来每次构建都和基线对比。我所在的团队就是这么做的效果很好新人提交的代码如果引入了性能问题在合并之前就会被拦下来不会等到上线后才被发现。7.3 优化的终点是架构演进最后说一点个人体会。性能优化做到一定程度你会发现单靠调优已经不够了瓶颈变成了架构本身。比如单机数据库再优化也扛不住千万级 QPS这时候就需要考虑读写分离、分库分表、引入搜索引擎。再比如单体应用再优化也扛不住千万级并发这时候就需要考虑微服务拆分、无状态化、水平扩展。优化和架构演进是相辅相成的优化为架构演进争取时间架构演进为优化打开空间。但架构演进不是越早越好。我见过一些团队业务量还没起来就搞微服务、搞分库分表结果复杂度上去了开发效率下来了性能却没提升多少。我的建议是先用尽单机优化的手段等到单机确实扛不住了再考虑架构层面的改动。因为架构改动的成本远高于代码优化而且一旦改错回滚的代价极大。优化的本质是在当前约束下找到最优解而不是追求理论上的完美架构。