项目里最难的问题是什么
先理解原理和示例，再练习完整口述与追问。
回答要点
准备两个真实案例，每个按“现象 → 影响 → 定位证据 → 根因 → 修改 → 验证 → 防复发”讲。性能、请求竞争、复杂表单、SSR 登录态、线上兼容问题都可以。
别只说“查资料解决了”。说明看了什么日志、怎么排除其他原因、为什么这个修改能解决问题。
原理拆解
“最难”不由代码量决定，而由约束、定位过程和取舍决定。先区分现象与根因：列表闪动是现象，多个响应无条件写入同一状态可能是根因。好的排障回答需要提出假设、找到证据并排除其他解释。修改后既验证正常路径，也验证触发问题的时序和失败分支，最后考虑怎样让同类问题更早被发现。
示例与推演
请求乱序的证据可以是一张时间线：A 使用旧条件发出，B 使用新条件发出，B 在 100ms 返回，A 在 500ms 返回。页面最终显示 A，说明问题不在新接口返回的数据，而在写入条件。加入请求版本后重放同样时序，旧结果不再写入，再检查旧请求 finally 是否仍会把新请求的 loading 清掉。
易错点
不能只报最终修复代码。需要说清为什么不是缓存、分页参数或接口脏数据，并且不把一个教学案例冒充自己的线上经历。
参考回答可直接练习口述
可按这个结构口述真实案例：“最有挑战的是[问题]。我先复现并确认影响范围，再通过[日志、网络或性能记录]排除[其他原因]，定位到[根因]。最后采用[修改]，并验证[正常、异常与边界场景]。结果是[真实数据或可观察行为]，同时增加[必要监控或保护]。”例如请求乱序这一类问题，可完整解释：先发出的旧请求后返回，覆盖了新条件结果；用请求标识隔离旧响应，必要时取消旧请求，loading 也只由最新请求控制。该例仅供理解，不能直接冒充个人经历。