面试官问“你项目中遇到的最难的问题是什么”，应该怎样回答？

本题是回答思路与示例，不对应某个官方规范。示例中的数字只用来演示怎样表达，讲自己的项目时请用真实数据。

简答

这道题考的不是问题本身有多难，而是你遇到问题时怎么想、怎么做，以及你在里面起了多大作用。所以选题要满足三个条件：是你亲自主导或深度参与解决的；有一定技术深度，不是“需求改了好几次”这类沟通问题；你能把每个细节讲清楚，经得起追问。

讲的时候按五步来。先说背景和影响，比如“商品列表页在低端安卓机上滑动明显卡顿，用户投诉集中”，让面试官知道问题为什么重要。再说怎么定位，用了什么工具、看到了什么数据、怎样排除其他可能。然后说方案，最好讲出两三个备选和你选择的理由。接着说结果，尽量用数字。最后说复盘，比如加了监控、写进了规范。

整段控制在两三分钟。不要一上来就讲技术细节，先用一两句话交代清楚问题，面试官感兴趣自然会追问。

要注意，千万不要编造或夸大。面试官往往会顺着你说的细节一路追问，比如“为什么不用另一种方案”“这个数据是怎么测的”，讲不出来比选一个普通的问题更扣分。

一个完整的示例

下面以“长列表页卡顿”为例，演示五步怎样串起来：

背景：我们的商品列表页一次加载几百条数据，每条有图片和多个标签。上线后收到不少反馈，说在中低端安卓机上滑动卡、点击筛选要等一下才有反应。性能监控里这个页面的 INP 明显超出了 200 毫秒的“良好”标准。

定位：我先用 Chrome DevTools 的 Performance 面板在降速模式下录制，发现点击筛选后有一个两三百毫秒的长任务，主要耗时在组件重新渲染上；滑动时每帧也有大量布局计算。再看代码，筛选时整个列表几百个条目全部重新渲染，而且每个条目里有一个读取 offsetHeight 的逻辑，导致强制同步布局。

方案：考虑过分页加载，但产品要求保持连续滚动体验，就没有采用。最后做了三件事：列表改用虚拟列表，只渲染可视区域附近的条目；去掉条目里读布局属性的代码，改用 CSS 固定高度；筛选结果用 useDeferredValue 延迟渲染，让输入先响应。

结果：真实用户监测里，这个页面的 INP 从约 400 毫秒降到 150 毫秒以内，渲染的 DOM 节点从几千个降到一百个左右，相关投诉基本消失。

复盘：后来我把虚拟列表封装成了团队的通用组件，并在性能预算里给长列表页加了 INP 告警，避免以后再出现同类问题。

这个回答为什么有说服力？每一步都有具体的东西：工具、现象、数据、取舍和结果。面试官听完能判断你会不会排查问题、会不会权衡方案。里面涉及的知识点，比如 INP、强制同步布局、虚拟列表，也都可能被追问，要提前准备，可以看《INP 很高时，如何定位到底是哪一段交互变慢？》和《虚拟列表通过什么方式减少渲染成本？》。

哪些题材不适合

“需求变更太频繁”“和后端联调很痛苦”这类问题，主要是协作问题，很难体现技术能力，除非你讲的是怎样通过技术手段解决，比如推动接口契约测试。

“学一个新框架很难”也不太合适，因为它说明的是学习过程，而不是解决问题的能力。

如果实在没有很复杂的问题，就选一个普通问题讲深一点。比如一次线上白屏，讲清楚怎样通过错误监控和 Source Map 找到原因、怎样防止再发生，同样能体现能力。

常见追问

如果再来一次，你会怎么做？

这是在看你会不会反思。可以说在哪一步走了弯路，比如“一开始以为是接口慢，花了半天看网络请求，后来才发现是渲染问题；现在我会先录一次性能面板再下判断”，或者说哪个方案当时没时间做、现在会补上。

这个问题是你一个人解决的吗？

如实说清楚分工，比如“定位和方案是我做的，图片 CDN 的配置是运维同事改的”。面试官要判断的是你个人的贡献，团队成果说成个人的，一追问就会露馅。