MoWorld 里的一次操作，从按下到看到画面变化，中间至少经过两段：输入事件有没有被接收，接收之后画面有没有被生成并推到屏幕上。卡顿出现时，这两段混在一句「很卡」里，只能靠猜。把交互输入和画面生成拆成两条独立记录，改动才有方向。

判断依据其实很朴素：如果一次操作在界面上没有任何可见反馈，比如没有按压态、没有焦点框、控制台也没有事件打印，问题更可能落在输入段；如果输入反馈每次准时出现，画面却分批出来或者长时间停在旧状态，那要看的是生成段。建议固定一种输入方式，重复同一步操作，把两次观察分开记录，再决定查哪里。

区分卡点的做法是两条独立记录：一条记输入被接收的可见反馈及其出现时刻，一条记画面从首帧到稳定的变化过程。操作上固定一种输入方式反复触发，用录屏回看取时间点，分别写下输入段间隔和生成段的变化次数。适用于同一操作有时响应有时不响应、画面分批出现的情况；边界是录屏和秒表只能给出观察到的区间，不代表内部处理耗时，具体归因还要结合环境日志与配置确认。

先找出输入被接收的可见反馈

先记录输入方式：鼠标点击、键盘按键、触摸、手柄或界面上的按钮，每次只变一项。然后盯住界面上能证明输入被接收的现象，这些现象通常比画面变化更早出现：按钮的按压态、焦点框、光标形状变化、状态栏的「处理中」提示、计数器或选中项的变化、控制台里打印出的输入事件。

如果上面这些都没有出现，先按输入段排查：事件是否绑定在正确的元素上、有没有被上层元素挡住、元素是否处于禁用或未聚焦状态、事件监听是否只绑在会随画面重建而被替换的节点上。可以用一段最小探针代码确认事件是否到达页面，事件名和选择器按实际环境替换，挂在捕获阶段执行，避免被下层拦截后看不到：

// 用途：确认输入事件是否到达页面，并记下到达时刻
// 位置：页面加载后执行；事件名与选择器按实际环境替换
const inputLog = [];
document.addEventListener('pointerdown', function (e) {
  const t = performance.now();
  inputLog.push({ type: 'pointerdown', t: t, target: e.target.tagName });
  console.log('[input]', 'pointerdown', 't=', t.toFixed(1), 'target=', e.target.tagName);
}, true);

验证方式是操作一次，控制台应新增一条记录；没有新增，说明输入段本身没有被接收，画面生成一侧的排查可以先放一放。需要留意的是，捕获阶段的探针只能证明事件到达页面，不能证明业务逻辑处理了这次输入，这两件事要分开看。

记录输入到首个可见变化之间的间隔

这一步只量输入段：从输入发生，到界面上出现第一个可见变化为止，不把后续画面生成算进来。

1. 用系统录屏或浏览器录屏，并留意帧率。常见录屏按 30 帧或 60 帧保存，帧率决定回看时能分辨的最小刻度，具体按手头工具确认。
2. 连续做 5 到 10 次相同操作，每次之间留一两秒空白画面，方便回看时切分。
3. 回看时找两帧：出现按压态或控制台打印的那一帧记作输入帧，界面出现第一个可见变化（状态提示、光标变化、画面第一处改动）的那一帧记作反馈帧。
4. 记下两帧之间跨过的帧数或秒表读数，重复多次，把观察到的范围写下来。手动点秒表的误差通常较大，只适合区分「大概很快」和「明显到了秒级」，不适合做精细归因。

如果输入帧和反馈帧之间总是隔着一段稳定间隔，且间隔随操作类型变化，那输入段本身可能是通的，问题往生成段找；如果间隔忽长忽短甚至完全没有反馈帧，先回到上一步确认输入有没有走通。这里只写观察到的区间，不推测内部处理耗时。

记录画面从首帧到稳定的过程

这一步只看生成段：输入反馈已经出现、画面开始变化之后，到画面停止明显变化为止。

• 先描述画面出现方式：是逐块出现、逐区域出现，还是整体替换。逐块出现时记下先出的是哪一块、后出的是哪一块。
• 记稳定需要的观察次数：用等间隔截帧，例如每半秒截一张，或者直接录屏回看，数清楚画面明显变化了几次。有些场景一次就稳定，有些会连续变化多次才停下。
• 记明显中断或长时间不变化的位置：某块区域一直空着、某个位置反复重绘、几次变化之后画面又回到旧状态，这些都值得单独记一笔。

录屏回看时建议同一段操作重复两次以上再下判断，单次现象可能只是加载顺序的差异，需要结合环境确认。生成段的变化次数和停顿位置是后续对照的主要依据，不要只写一句「画面很慢」。

把现象分别归到两段里

观察记录分开之后，归类只需要看输入反馈有没有出现、出现之后画面是否跟进，可以分三类：

• 只在输入段出现：按下没有按压态，控制台没有事件打印，光标或焦点不变。可复述描述——「点了没反应，输入没被接收。」
• 只在生成段出现：输入反馈准时出现，画面逐块出现很慢，或长时间停在旧状态。可复述描述——「操作收到了，画面没跟上。」
• 两段都有：输入反馈本身就延迟出现，画面随后又分批生成。可复述描述——「输入和画面都慢，需要分别计时，再决定先处理哪一段。」

两段式记录表可以按下面的列来建，每列都对应前面某一步观察到的事实，某列没看清就写「未观察到」，不要用推测填数：

表的用法是前后对照：同一操作重复几次后，如果输入段间隔稳定而生成段变化次数忽多忽少，调整方向通常应放在画面生成一侧；反过来，输入段间隔本身就不稳定甚至没有反馈，则先查输入事件的接收路径。记录里出现哪一段的现象，就处理哪一段，不要两段一起换配置，否则下一次卡顿还是分不清来源。