面试官问“按钮点了没反应，怎么排查”，如果只答接口慢、加缓存，很容易被追问：假如请求早就结束了呢？
我做的 OfferFlow 世界面经里，有一道真实前端题：什么是长任务，为什么阻塞页面交互，如何用 PerformanceObserver 识别，以及怎样拆分。本文围绕这道题写一份原创解题示例，不把示例当作唯一标准答案。
先说清楚，长任务不等于长请求
主线程上的一个任务执行超过50毫秒，是长任务的常见判断门槛。主线程忙着执行JavaScript、布局等工作时，用户输入和绘制机会可能被延后。
但接口耗时很长，并不自动表示主线程一直被占用；页面卡顿也可能与网络、渲染、资源加载等有关。先区分现象和证据，才能决定下一步查哪里。
先拿到一条观察记录
在支持Long Tasks API的浏览器中，可以先用一个最小的观察器：
const canObserve =
typeof PerformanceObserver !== "undefined" &&
PerformanceObserver.supportedEntryTypes?.includes("longtask");
if (canObserve) {
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log("[longtask]", {
startTime: entry.startTime,
duration: entry.duration,
context: entry.name,
});
}
});
observer.observe({ type: "longtask", buffered: true });
}
这里拿到的是时间与上下文线索，不是自动定位到了业务代码的某一行。entry.name也不等于业务函数名。观察到记录以后，再结合浏览器Performance面板、交互时间点和业务日志排查。
浏览器支持情况需要单独判断，不支持该API时不能据此得出“没有长任务”。
拆分方案，回答适用前提与代价
第一种，把大批处理拆成小块，在块之间把执行机会交还给主线程。块大小需要结合设备与实际耗时调整；单纯把所有工作塞进连续的微任务，不能保证页面获得绘制机会。
第二种，把适合的纯计算放到Web Worker。要考虑通信、序列化和启动成本；Worker不能像页面脚本一样直接操作DOM，也不是把函数挪进去就自动变快。
可用的回答顺序是：观察到什么 → 怀疑什么 → 怎么验证 → 怎样拆分 → 如何比较交互体验与开销。优化以后，仍需要在实际设备和真实负载下复查。
在OfferFlow里怎么找
首页进入“世界面经”，从岗位树选“前端开发”→“Web前端工程师”，打开长任务题，再看参考答案与条目已有记录。
这次已实际打开该题与参考答案区域，画面来自公开面经内容。产品支持共创与记录，不代表每一题的答案都完整或必然正确。本文没有新增题目，也没有修改公开答案。
参考资料： developer.mozilla.org/en-US/docs/… developer.mozilla.org/en-US/docs/…
我是OfferFlow开发者，本文为开发者自荐、AI辅助整理。代码是本文原创最小示例；隔离页面中的人工长任务仅用于检查观察器能否收到记录，不是OfferFlow性能测评，也不能当成真实业务优化结论。
