onMessage 回调中存在无法退出的同步阻塞（如 while(true)、busy-wait）会导致 content script 或 background 页面卡死、CPU 拉满；await 异步等待安全，而轮询式“sleep”会引发高 CPU。
查 onMessage 里有没有死循环或 sleep
Chrome 扩展的 onMessage 回调如果写错，确实会卡死整个 content script 或 background 页面，导致 CPU 拉满。重点不是“有没有循环”，而是“有没有无法退出的同步阻塞”。
常见错误现象：chrome.runtime.onMessage.addListener 回调里用了 while(true)、for(;;)，或者调了 Node.js 风格的 sleep(1000)（浏览器没这函数，但有人用 performance.now() 手搓 busy-wait）。
- 浏览器里没有真正的
sleep，任何“等 1 秒”的尝试如果靠轮询 + 时间判断，就是典型 CPU 100% 根源 -
await不等于阻塞：用await new Promise(r => setTimeout(r, 1000))是安全的；但while (Date.now() 就是灾难 - 检查所有
onMessage回调是否在最后显式调用了sendResponse（如果用了异步）——漏掉会导致 Chrome 等超时，反复重试也可能推高 CPU
确认是哪个 onMessage 在捣鬼
多个扩展、多个脚本可能同时监听 onMessage，得先定位到具体位置。别一上来就翻代码，先看运行时行为。
使用场景：你在 DevTools 的 Performance 面板录制一段 CPU 飙高的过程，然后看 Flame Chart 里密集执行的是哪个文件哪一行；或者直接打开 chrome://extensions → 启用“Developer mode” → 点击你的扩展的 “background page” 或 “inspect views” 查看控制台。
- 在 background script 或 content script 的开头加
console.time('onMessage-start')，结尾加console.timeEnd('onMessage-start')，看哪个耗时异常长或根本不结束 - 临时注释掉所有
onMessage监听器，再逐个放开，配合刷新页面或发消息测试，快速隔离问题监听器 - 注意：content script 的
onMessage和 background 的onMessage是两套独立逻辑，别只盯一边
setTimeout 和 setInterval 在 onMessage 里乱用也会拖垮 CPU
不是只有死循环才危险。onMessage 里启动一个没清理的 setInterval，或者嵌套调用 setTimeout 却没设终止条件，几秒后就会生成成百上千个定时器。
参数差异：setInterval(fn, 0) 比 setInterval(fn, 16) 更危险——它尽可能高频触发，尤其在主线程空闲时，极易形成隐式忙等。
- 每次注册
setInterval前，先clearInterval对应的旧句柄（如果存在），避免重复叠加 - 在
onMessage回调里启动定时器，必须配套设计关闭路径（比如收到另一个 message 触发clearInterval） - 用
requestIdleCallback替代高频setTimeout做低优先级轮询，能明显缓解压力
扩展通信链路本身引发的循环调用
比单个 onMessage 更隐蔽的问题：A 发消息给 B，B 处理完又发消息给 A，A 再发回来……没有跳出条件，就成了消息版死循环。
性能影响：每次 chrome.runtime.sendMessage 都要序列化、跨上下文传递、事件分发，开销不小；连续几十次就能让 UI 线程卡住。
- 在每条发送前加日志，比如
console.log('[send]', { from: 'content', to: 'bg', type: 'sync-data' })，观察控制台是否出现规律性重复 log - 给消息加唯一
id字段，接收方缓存最近处理过的 id，遇到重复 id 直接丢弃（防重入） - 避免在
onMessage里无条件调用sendMessage—— 至少加个状态判断或节流
真正难排查的，是那种带状态分支的循环：比如只有当某个 flag 为 true 且数据未加载完成时才回发消息。这种逻辑一旦状态没及时更新，CPU 就默默烧起来了。
