如何定位并拆解主线程长任务，从而改善复杂交互的响应延迟？

# 核心结论

定位长任务不能只找“最慢函数”，而应从一次真实的慢交互出发，把延迟拆成输入等待、事件处理和下一帧呈现三个阶段，再结合主线程任务、调用栈、样式布局和框架提交过程确定阻塞来源。治理优先级是减少总工作量，其次把非关键工作推迟到视觉反馈之后，再把可恢复计算切成能够让出主线程的小块；纯计算、解析或搜索等适合的任务可以迁移到 Web Worker。节流与防抖只能调整调用频率，不能自动降低单次任务成本。

# 底层机制

主线程任务通常具有运行至完成的语义。一个任务开始后，新的用户输入、计时器回调和渲染机会一般要等待它结束。通常把超过一定持续时间的主线程任务称为长任务，但用户卡顿并不只来自越过门槛的单个任务：多个连续的中等