性能问题高频追问怎么答
追问 1：你怎么证明这是前端性能问题，不是后端问题
我一般会先看 TTFB、接口耗时和资源瀑布图。如果首包和接口时间明显高，那更偏后端或网络；如果接口本身没问题，但主线程长任务很多、React 重渲染明显、输入操作后页面迟迟没反馈，那更偏前端。很多时候不是二选一，而是哪一边更主要，我会先定位主要矛盾。
追问 2：为什么不一开始就上 memo、useMemo
因为很多性能问题的根因不是“某个组件慢”，而是状态边界太大、更新范围太广。memo 和 useMemo 是手段，但不是总开关。如果一上来全加，成本很高，而且可能几乎没效果。我一般会先缩小更新影响范围，再决定需不需要做缓存。
追问 3：如果指标和用户体感不一致怎么办
这时候我不会盲信某一个数字。我会先确认采集口径和场景对不对，比如是不是后台页、是不是特定设备、是不是高数据量场景。然后再结合录屏、日志、用户反馈和页面操作链路去看。性能治理不是只看仪表盘，而是让指标和真实体验尽量对齐。
追问 4：怎么防止性能问题后面再次反弹
我一般会做三件事。第一，把关键指标接进监控，比如 LCP、INP、CLS；第二，把这次优化沉淀成团队判断标准，比如什么场景优先查状态边界，什么场景优先查长任务；第三，在代码评审和发布前把高风险点前置暴露出来，不让问题每次都等到线上再发现。
追问 5：如果时间很紧，你会优先优化哪里
我会优先做影响最大、收益最直接的点。比如首屏慢就先动首屏资源和关键渲染路径，交互卡就先处理主线程长任务和最明显的重复渲染，列表卡就先上虚拟列表。也就是说，我会先做能明显改善体感的动作，而不是追求理论上最完整的方案。
追问 6：如果优化后效果不明显怎么办
这通常说明一开始定位不够准，或者问题是多个因素叠加。我会回到基线和数据上重新看，确认到底是资源、渲染、主线程还是接口问题。性能优化最怕的是一边做一边猜，所以我会尽量让每一步优化都对应一个明确假设和验证结果。
一句收口
我会把性能问题理解成一个“定位 - 优化 - 验证 - 防回归”的闭环，而不是一次性修 bug。这样面试官更容易感受到你做的是治理，不是偶然救火。