6 篇博文 含有标签「Chrome插件」

在浏览器扩展里点击「提取本页」按钮时，控制台抛出 Cannot access 'Hc' before initialization——而 typecheck、build、常规测试全部通过，本地开发时也从未复现。

在为客户开发电商自动化数据采集工具时遇到此问题——批量抓取商品图片、SKU、价格与评价，清洗后导出结构化数据，支撑库存管理与竞品分析。「提取本页」正是该工具链里的采集入口，炸的是它的内容脚本模块。

TL;DR​

第三方经典脚本（vendored classic script）里有一处隐式全局赋值（CandidateElement = function(...)，未声明直接赋值）。经典脚本里这是合法的全局变量创建，但文件被内联进 ESM 模块图后在严格模式下变成 ReferenceError，模块初始化当场中断，下游通过动态 import 拿到的命名空间因此处于暂时性死区（TDZ）。修法：vendor 文件头补一行 var CandidateElement;。

问题现象：构建全绿，点击即炸​

报错发生在用户点击时，不是页面加载时：

TypeError: Cannot access 'Hc' before initialization

三个反直觉的点：

1. typecheck 通过——类型层面没有任何问题；
2. build 通过——打包器只做静态分析，不执行模块代码；
3. 常规测试通过——测试没有把该模块完整 import 一遍。

报错对象是 Hc 这种 2 字母压缩名，不是任何业务符号名。这个特征先记下，后面识别时会用到。

根因：隐式全局赋值如何中断 ESM 模块图​

出问题的是第三方库里的一行代码，位于 reader-finder.js:878：

// 经典脚本语义：未声明就赋值 = 创建全局变量，合法
CandidateElement = function(e, t) { ... }

整个故障链条有 4 步，逐环递进：

第 1 步：经典脚本语义下合法。 这个文件原本以 <script> 方式加载，非严格模式下「未声明直接赋值」会静默创建全局变量，原作者依赖了这一行为。

第 2 步：进入 ESM 后变成雷区。 文件被内联进扩展的 ESM 模块图，而 ESM 代码强制运行在严格模式下——隐式全局赋值直接抛 ReferenceError，模块初始化（module evaluation）当场中断。

第 3 步：中断沿模块图扩散。 内容脚本 content.js 的内联模块图在求值到这个 vendor 模块时停摆：靠前模块的消息监听器已经注册成功，靠后的模块 facade（门面导出）还没执行——模块处于「半初始化」状态。

第 4 步：动态 import 踩进 TDZ。 用户点击按钮时，代码通过动态 import 加载命名空间 facade。由于第 3 步的中断，这个命名空间处于暂时性死区，访问即抛 Cannot access 'Hc' before initialization——压缩名 Hc 正是那个没初始化完的模块内部绑定。

这就解释了所有现象：静态检查不执行模块代码所以全绿；报错在点击时才出现，因为动态 import 发生在点击处理器里；报错名是压缩随机名，因为炸的是被打包器改名过的模块内部绑定。

关于 ESM 动态 import 的另一个高频坑（模块找不到），见这篇：Node.js ESM 动态 import 报模块找不到？检查文件扩展名。

解法：vendor 文件头补一行 var 声明​

不改第三方逻辑，只把隐式全局变成显式声明——在 vendor 文件头部补上：

var ReaderArticleFinder;
var CandidateElement;

赋值从「创建全局变量」变成「给已声明变量赋值」，严格模式下合法，模块初始化不再中断，下游动态 import 拿到的 facade 正常可用。

同文件里的 ReaderArticleFinder 早就是这样处理的——同一个坑，这个库埋了两次，第一次修了，第二次（CandidateElement）漏了。

验证：用 Vitest 让它本地复现​

修复前先要能稳定复现，否则只能等线上验证。常规测试跑不到这条路径，但用 Vitest（jsdom 环境）直接 import 该模块可以：

import { describe, it, expect } from 'vitest';

describe('vendor reader-finder strict-mode', () => {
  it('模块图完整初始化，不抛 ReferenceError', async () => {
    const mod = await import('./lib/vendor/reader-finder');
    expect(mod).toBeDefined();
  });
});

这条测试在修复前能复现报错，且给出真实文件行号堆栈（reader-finder.js:878）——比线上压缩产物的 Hc 可定位得多。修复后转绿。

修完的完整验证是把提取链端到端跑一遍：模块图完整初始化 + 提取功能实际可用，两条都过才算闭环。

防回归​

把这个复现用例固化成冒烟测试（extractor.test.ts），并立一条入库纪律：新的经典脚本 vendor 进项目前，必须先过这个测试或等价的 strict-mode 检查。

如何快速识别这类 TDZ 报错​

下次见到 Cannot access 'xxx' before initialization，按两个特征判断是不是同款问题：

命中左列：优先怀疑 vendor 经典脚本的隐式全局，搜「未声明赋值」+ 用 Vitest 直接 import 复现。ESM 迁移期的另一类经典报错（CJS require ESM）见：Node.js require nanoid 报 ERR_REQUIRE_ESM？v5 改纯 ESM 的替代方案。

常见问题​

为什么 typecheck 和 build 全绿，运行时才报 Cannot access before initialization？​

静态检查和打包不执行模块代码，而隐式全局赋值的 ReferenceError 只在模块真正初始化时抛出。如果出问题的模块位于动态 import 的依赖链上，报错会推迟到用户交互那一刻——本例点击扩展按钮才炸，构建期 0 报错。用 Vitest（jsdom 环境）直接 import 该模块即可本地复现并拿到真实行号。

Cannot access 'xxx' before initialization 和暂时性死区（TDZ）有什么关系？​

动态 import 返回的命名空间对象，在依赖模块初始化中断后处于暂时性死区，访问其任何导出都抛这个错。识别线索是报错名：压缩产物里是 2 个字母的随机短名（如 Hc）而不是业务符号名，说明中断发生在模块图求值阶段，而非业务代码。

怎么修复 vendor 经典脚本的隐式全局赋值？​

在 vendor 文件顶部为每个隐式全局补 var 声明（本例 2 个：ReaderArticleFinder 与 CandidateElement），让赋值落在已声明变量上。一行声明消除整个模块图的初始化中断；新 vendor 文件入库前跑一次 strict-mode 冒烟测试即可提前拦截。

在为客户开发 Chrome 扩展数据采集工具时遇到此问题，记录根因与解法。

TL;DR​

window.postMessage(data, '*') 会把消息广播给页面中所有 frame，包括第三方 iframe。如果你的 Chrome 扩展通过 postMessage 传递用户数据（如 memberId、业务报表），任何嵌入页面的 iframe 都能监听到。把 '*' 改为 window.location.origin 即可精确限定接收方。

问题现象​

Chrome 扩展的采集脚本通过 postMessage 将电商数据传递给 content script：

// ❌ 不安全：消息广播到所有 frame
window.postMessage({
  type: 'CCL_SHOP_REPORT_DAILY',
  memberId: 'b2b-2214126315258ad300',  // 用户 ID
  rows: [{ uv: 403, payAmt: 19478.47 }]  // 业务数据
});
// 等同于 window.postMessage(data, '*')

页面上如果嵌入了第三方 iframe（广告、统计、社交插件），这些 iframe 的 message 事件监听器同样能收到这条消息。

根因​

postMessage 的第二个参数 targetOrigin 决定消息的接收范围：

省略第二个参数时，浏览器默认使用 '*'。这在 Chrome 扩展场景下尤其危险——扩展注入的脚本运行在电商平台页面，页面上可能有多个第三方 iframe。

解决方案​

封装安全的 postMessage 工具函数​

// safePostMessage：强制使用 window.location.origin
function safePostMessage(data) {
  window.postMessage(data, window.location.origin);
}

// 使用
safePostMessage({
  type: 'CCL_SHOP_REPORT_DAILY',
  subType: 'daily',
  memberId: memberId,
  rows: [row]
});

接收端也要验证 origin​

// content script 中监听消息
window.addEventListener('message', (event) => {
  // ✅ 验证来源 origin
  if (event.origin !== window.location.origin) return;

  // ✅ 验证消息结构
  if (!event.data || typeof event.data.type !== 'string') return;

  switch (event.data.type) {
    case 'CCL_SHOP_REPORT_DAILY':
      handleDailyReport(event.data);
      break;
    case 'CCL_ITEM_WEEKLY_REPORT':
      handleWeeklyReport(event.data);
      break;
  }
});

什么时候可以用 '*'​

只有一种场景安全：消息内容完全不含敏感信息，且接收方 origin 不可预知。例如纯 UI 状态通知（"面板已打开"）。即使如此，用 window.location.origin 也更安全。

注意事项​

在为客户构建电商数据采集系统时遇到此问题，记录根因与解法。

TL;DR​

1688 平台 Cookie 中 last_mid 和 unb 都包含用户 ID，但格式不同（b2b-xxx vs 纯数字）。数据库存的是 b2b- 前缀格式。原代码遍历 Cookie 数组时先匹配到了 unb，导致严格等于比较失败，所有采集数据写入时关联不到店铺，结果全是零值。

解法：把 Cookie key 优先级列表放在外层循环，Cookie 数组放在内层循环，确保高优先级的 key 先被查找。

问题现象​

1688 生意参谋日报采集后，数据库里看板数据全是 0，但询盘数据有值：

shop_id | report_date | reveal_cnt | uv | pay_amt | effective_inq_users
       2 | 2026-05-13  |          0 |  0 |    0.00 |                  56
       2 | 2026-05-14  |          0 |  0 |    0.00 |                  41

后端日志报错：No shop found for memberId: 2214126315258

但数据库里存的 platform_account_id 是 b2b-2214126315258ad300。

根因​

同域名下存在两个不同格式的用户 ID Cookie​

unb=2214126315258                          # 纯数字
last_mid=b2b-2214126315258ad300            # b2b- 前缀 + 后缀

数据库映射表 shops.platform_account_id 存的是 b2b- 前缀格式。代码做的是严格等于匹配：

const match = mapping.find(m => m.platform_account_id === memberId);
// "2214126315258" !== "b2b-2214126315258ad300" → 匹配失败

遍历顺序陷阱​

原代码的外层循环是 Cookie 数组、内层是 key 列表：

// ❌ 错误：Cookie 数组在外层，key 优先级无效
var keys = ['last_mid', '__last_memberid__', 'unb'];
for (var i = 0; i < cookies.length; i++) {     // 外层：Cookie
    var pair = cookies[i].trim();
    for (var k = 0; k < keys.length; k++) {    // 内层：key
        if (pair.indexOf(keys[k] + '=') === 0) {
            return pair.substring(keys[k].length + 1);
        }
    }
}

document.cookie 的返回顺序不是固定的。如果 unb 的 Cookie 在数组中排在 last_mid 前面，就会先匹配到 unb，返回纯数字格式的 ID——last_mid 的优先级形同虚设。

解决方案​

交换循环层级：key 优先级列表放在外层，Cookie 数组放在内层：

// ✅ 正确：key 优先级列表在外层
var keys = ['last_mid', '__last_memberid__', 'unb'];
for (var k = 0; k < keys.length; k++) {         // 外层：按优先级遍历 key
    for (var i = 0; i < cookies.length; i++) {   // 内层：在所有 Cookie 中查找
        var pair = cookies[i].trim();
        if (pair.indexOf(keys[k] + '=') === 0) {
            return pair.substring(keys[k].length + 1);
        }
    }
}

key 列表按优先级在外层遍历，无论 document.cookie 返回顺序如何，始终先查找 last_mid，保证拿到和数据库格式一致的用户 ID，映射不会失败。

验证​

// 在浏览器控制台确认两个 Cookie 都存在
document.cookie.split(';')
  .filter(c => /last_mid|unb/.test(c.trim()))
  .map(c => c.trim())
// ['unb=2214126315258', 'last_mid=b2b-2214126315258ad300']

在为客户构建电商数据采集 Chrome 扩展时遇到此问题，记录根因与解法。

TL;DR​

WXT 框架 HMR 热重载时，content script 重新执行但旧的 window.addEventListener('message', ...) 不会被清除。每热重载一次就多一个监听器实例，导致每条 postMessage 被处理 N 次。

解法：注册新监听器前，从 window 变量取出旧监听器引用并 removeEventListener。

问题现象​

浏览器控制台显示同一条消息被两个不同实例捕获：

content.js:114 [CCL] CCL_SHOP_REPORT_DAILY daily caught - 实例: nxctn6
content.js:2   [CCL] CCL_SHOP_REPORT_DAILY daily caught - 实例: t6jce7

每条 postMessage 被处理两次，导致后台发送重复请求。

根因​

WXT (基于 Vite 的 Chrome 扩展框架) 开发模式下，修改 content script 后触发 HMR：

1. 新的 content script 模块被加载执行
2. 新的 window.addEventListener('message', messageListener) 被注册
3. 旧的监听器函数仍然存在于内存中——HMR 不负责清理 DOM 事件监听器

结果：window 上挂载了多个独立的 message 监听器，每条 postMessage 触发所有实例。

解决方案​

在 content script 入口处，注册新监听器前移除旧的：

const instanceId = Math.random().toString(36).slice(2, 8);

// 取出旧监听器引用
const prevListener = (window as any).__cclMessageListener;
if (prevListener) {
  window.removeEventListener('message', prevListener);
}

// 定义新监听器
const messageListener = (event: MessageEvent) => {
  // ... 处理逻辑
};

// 存储当前引用（供下次 HMR 取用）
(window as any).__cclMessageListener = messageListener;

// 注册
window.addEventListener('message', messageListener);

关键点：removeEventListener 必须传入和 addEventListener 相同的函数引用。把函数存到 window 变量上，下次 HMR 时就能取出旧引用并正确移除。这样无论热重载多少次，始终只有一个活跃的 message 监听器。

如果你同时遇到 postMessage 的 targetOrigin 安全问题或Cookie 取值导致数据全零，建议一并排查。

TL;DR​

Chrome 扩展在开发调试时，每次测试采集都会把数据写进生产数据库。用三层 DRY-RUN 开关解决：.env.development 设环境变量 → 客户端读取后给请求加 X-Dry-Run Header → 服务端拦截该 Header 返回数据预览，不执行写入。生产环境不设该变量，完全不受影响。

TL;DR​

Chrome 扩展使用 sidepanel 作为 UI 入口，用户登录后 token 存入 localStorage。但 Service Worker（background script）没有 localStorage，调用直接抛 ReferenceError。解决方案：sidepanel 登录后通过 chrome.runtime.sendMessage 将 token 同步给 Service Worker，由 Service Worker 写入 chrome.storage.local。两边各取所需——sidepanel 读 localStorage，Service Worker 读 chrome.storage.local。