性能优化方案如何取舍

维护说明

• 这页统一引用 性能公共素材 的取舍口径。
• 如果要改取舍表达，优先改素材页。

一句话先定性

性能优化不是看到哪里慢就全改，而是先看收益最大的是哪一层，再决定优先动资源、状态边界、渲染量还是交互链路。

30 秒版本

如果面试官问性能优化怎么取舍，我一般会先看三件事：问题影响范围有多大、优化收益有多直接、改动风险有多高。比如首屏卡得很明显，我会优先动首屏资源和关键渲染路径；长列表卡，我会优先上虚拟列表；如果只是某个局部计算慢，我才会考虑 memo 或缓存。我的原则是先做收益大、验证快、风险可控的动作，而不是一上来就大改架构。

1 分钟版本

我做性能优化时一般会先排优先级，而不是把所有手段都上一遍。最常用的判断框架有三个维度：第一，影响范围，是不是核心页面、核心链路、主要用户群都会受影响；第二，收益大小，优化之后是不是能明显改善首屏、交互或稳定性；第三，改动成本和风险，会不会牵一发而动全身。

比如首屏问题，我通常优先做代码拆包、懒加载、图片压缩、缓存和关键资源优化，因为收益直接、验证也快；交互卡顿我会先拆长任务、减渲染量；长列表问题优先虚拟列表，因为它能直接减少渲染数量。反过来，如果某个方案改动很大、收益又不确定，我一般不会把它当第一选择。

所以我的取舍思路通常是：先做最影响体感、最容易验证、最不容易带来副作用的优化，再考虑更深层的结构调整。

2 到 3 分钟版本

如果面试官问性能优化怎么取舍，我一般会强调一点：性能优化不是技术动作堆砌，而是一个典型的工程取舍问题。因为你几乎永远不可能把所有问题一次性都优化到极致，所以关键不是“会多少招”，而是知道先动哪里最值。

我通常会从四个维度判断。第一是用户体感，哪个问题最容易被用户直接感知，比如首屏白得久、输入有明显迟滞、页面一直抖，这类优先级一定高。第二是影响范围，是不是核心页面、核心路径，还是某个边缘场景。第三是收益确定性，也就是你做完之后是不是大概率能看到明显改进。第四是改动风险，特别是会不会引入新的复杂度和维护成本。

比如首屏慢，如果已经能确认是包体积和关键资源问题，那我通常优先做拆包、懒加载、资源压缩和缓存，因为这些动作的收益比较确定，而且验证也快。再比如长列表卡，如果问题已经很明显，那虚拟列表通常比在单个 cell 上做很多细碎优化更划算，因为它直接减少渲染数量。

反过来，有些优化虽然听起来高级，但未必值得优先做。比如到处加 memo、useMemo，如果真正问题是状态边界太大，那这些动作很可能收益很有限，还会增加代码复杂度。所以我一般会先收缩更新范围，再决定需不需要加缓存。我的原则一直是：先做结构上能减少工作量的动作，再做局部技巧优化。

另外一个很重要的取舍点，是止血和长期治理要分开。比如线上已经明显卡了，那我可能先上一个收益快的方案，比如减少首屏渲染量、降级某些重逻辑、先用虚拟列表止血；等问题被控制住，再去做更底层的状态边界治理、组件拆分或者监控补齐。这样既能保护线上体验，也不会把团队拖进一次过大的改造里。

所以如果让我总结，我会说性能优化最核心的取舍原则就是三句：优先优化用户最有体感的问题，优先做收益最大且验证最快的动作，优先做能从根上减少工作量的优化，而不是一上来就堆技巧。

如果面试官追问“为什么不建议一开始就大改架构”

因为大改架构的成本和风险都很高，而且很多性能问题不一定需要那么重的动作。先用数据确认瓶颈，再做收益最大、验证最快的优化，通常更稳。

如果面试官追问“你怎么判断一个优化值不值得做”

我会看三件事：它影响是不是核心场景，收益是不是能被用户感知，改动是不是容易验证。如果这三件事都成立，我会优先做；如果收益不确定、风险又高，我一般会往后放。

最后一句收尾

所以性能优化的取舍，本质上不是会不会某个技巧，而是能不能用工程视角选出“现在最值得做的那一步”。