性能优化如何结合真实项目经历用 STAR 讲
使用方式
适合回答这类问题：
- 讲一个你做过的性能优化项目
- 讲一个你解决线上卡顿问题的例子
- 讲一个你如何定位并推进复杂问题落地
- 讲一个能体现你工程判断力的案例
STAR 模板一：优化复杂工作台交互性能
S，Situation
当时我们做的是一个比较重的前端工作台，页面上同时有看板、会话、详情、实时状态这些模块。随着数据量变大，用户在拖拽卡片、切换筛选条件或者接收实时回流时，会明显感觉页面卡顿，尤其是列表区和详情区会一起重渲染。
T，Task
我的任务不是只把某个组件改快，而是要定位到底是包体积、状态边界还是渲染链路出了问题，然后把页面交互恢复到可用范围，同时保证后面功能继续迭代时不会很快反弹。
A，Action
我先用 React Profiler 和浏览器 Performance 面板去看一次操作到底触发了哪些组件重渲染，先把问题从“感觉卡”变成“知道卡在哪”。
然后我把状态更新按边界拆开，避免一个页面级大状态带着整棵树一起刷新。
对于长列表和重内容区，我优先减少渲染量，比如做局部更新、虚拟列表或者把不在当前视口的内容延后渲染。
同时我也会看交互链路里有没有长任务，比如筛选时同步做了太重的排序、格式化或者派生计算，这类就拆分或延后执行。
如果发现是首屏资源问题，我再补代码拆包、懒加载和关键资源优化，让首屏和交互两条线分开治理。
R，Result
最后页面卡顿从“用户明显可感知”降到“多数交互可以顺畅完成”，而且更重要的是，我不是只修了一个点，而是把定位方式、状态边界和性能治理思路一起沉淀下来了。后面再加功能时，团队知道应该先看渲染范围还是主线程长任务，而不是继续盲目加 memo。
STAR 模板二：从指标出发推进性能治理
S，Situation
当时不是某个用户直接说卡，而是我们从监控数据里看到 LCP、INP 和 CLS 在一部分页面上持续偏高，说明问题不是个别机器，而是页面本身在首屏、交互和稳定性上都有隐患。
T，Task
我的任务是把这些指标和真实问题对上号，不能只是知道数值高，还要知道分别该查哪里，并且推动对应优化真正落地。
A，Action
我先按指标拆问题。LCP 偏高时先看首屏资源、图片、字体和包体积；INP 偏高时先看主线程长任务、重复渲染和同步计算；CLS 偏高时先看尺寸预留、骨架屏和异步模块插入方式。
然后我把监控 SDK 采回来的指标和浏览器 Performance、React Profiler、页面录屏这些信息结合起来看，尽量避免只凭一个数值猜原因。
在推进上，我不会把它讲成“性能优化一把梭”，而是拆成几类明确动作：首屏资源治理、渲染边界治理、布局稳定性治理。这样每个问题都能对应到负责人和改动范围。
R，Result
最后比较重要的结果，不只是指标下降，而是团队对性能问题的表达方式更统一了。大家不会只说“页面有点慢”，而是会说现在更像是 LCP 问题、INP 问题还是 CLS 问题，这样排查和优化效率会高很多。
STAR 模板三：体现 owner 意识的讲法
S，Situation
性能问题最麻烦的地方在于，它通常不是单点 bug，而是前端、接口、资源、渲染边界和状态设计一起叠出来的。如果只盯一个局部点，很容易今天修这里，明天又从别处长回来。
T，Task
我承担的不是只修一个慢函数，而是把定位链路、治理动作和后续防反弹机制一起补上，让性能问题从“救火”变成“可持续治理”。
A，Action
我先把问题分类，而不是混着看。是首屏慢、交互卡，还是页面抖，这三类处理方式完全不同。
然后我先做数据化定位，用指标和性能工具确认瓶颈，再决定是拆状态边界、减渲染量，还是做资源优化。
修完之后我也不会停在代码层，而是会把经验沉淀成团队可复用的判断方式，比如什么情况下优先看 LCP，什么情况下优先看主线程长任务，什么情况下优先查布局预留。
R，Result
这样带来的结果通常不只是“这次变快了”，而是团队下一次再遇到类似问题时，排查路径会更短，优化动作也更有方向。面试里我会强调这一点，因为它更能体现 owner 意识和工程判断，而不是只会修一个具体卡顿点。
使用建议
- 如果题目偏“讲一个你做过的性能优化项目”，优先用模板一。
- 如果题目偏“你怎么用指标驱动优化”，优先用模板二。
- 如果题目偏“你如何推进复杂问题落地”，优先用模板三。
- 回答时尽量把
S/T/A/R压到 2 到 3 分钟，不要讲成流水账。