4 篇博文 含有标签「JavaScript」

在浏览器扩展里点击「提取本页」按钮时，控制台抛出 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 冒烟测试即可提前拦截。

浏览器扩展的「人群资产」采集功能升级后，客服收到反馈：部分用户月中点开人群资产提示「已是最新」，数据却停留在月初——没升级的旧版扩展不再采集了，要到下个月 1 日才自己恢复。

在开发 电商数据采集工具 时遇到此问题——一站式电商运营解决方案，从数据采集到智能分析；采集判定标志由服务端下发，新旧版本扩展共用同一张服务端表。

TL;DR​

新版本给服务端已有的布尔标志 is_current_month 赋了新语义（当月采集窗口已覆盖），未升级的旧版本按旧含义把它读成「数据已是最新」，幂等判断被短路 → 月中停止采集。这不是要修的 bug，而是 version skew（版本偏差）：同一字段、两种解读。影响有自然自愈边界（次月标志翻 false）；处置 = 提醒升级 + 服务端 upsert 幂等免回滚；预防 = 语义变更必须换新字段。

问题现象​

新版扩展采集：写入当月行，is_current_month = true

旧版扩展续采：读到当月行 → 命中「up-to-date」判定 → 中止采集
用户视角：月中点「人群资产」→ 提示已是最新，数据停在月初
次月 1 日：is_current_month 翻 false → 旧版恢复采集（自愈）

诡异之处在于：服务端数据完全正确、新版扩展工作正常、旧版扩展代码一行没改——出问题的只是「旧版读到新版写的行」。

根因​

经典的 version skew。标志的名字没变，含义变了：新版本的语义是「当月窗口已覆盖」，旧版本按它自己的历史语义把同一行解读成「数据已最新」，于是按设计正确的幂等判断（已最新 → 不重复采集）短路了整个采集。判断逻辑双方都没错，错的是让两种语义共用一个字段。

浏览器扩展（以及一切客户端）的版本分布不受服务端控制：发布新版后，新旧版本并存是以周计的常态。任何「服务端字段含义」的调整，读方都包括所有历史版本——这和 feature flag 的经典教训同构：复用旧 flag 承载新含义，读方按旧含义行动。

解决方案​

当期处置：提醒升级 + 幂等免回滚​

发布含新采集逻辑的版本时，明确提醒用户升级——旧版本在当月内不会自己恢复。服务端与数据无需回滚：采集写入是 upsert 幂等，新旧版本交错写入不产生脏数据，次月标志翻转后自动对齐。

长期预防：语义变更换新字段​

把「窗口语义」从布尔标志迁移到带明确窗口的新字段，旧客户端不认识新字段就不会误读：

// 反例：复用旧标志承载新语义
{ "is_current_month": true }

// 正解：新语义用新字段，窗口显式、可比较
{ "collected_window": "2026-08", "source_version": "2.3.0" }

幂等判断键与业务语义从此解耦：旧版按旧字段判断、新版按新字段判断，互不越界。

设计原则：给每个标志找自愈边界​

标志优先绑定自然时间边界（月、天）而不是「最新」这种绝对语义。本例月翻边界把最坏影响锁定在一个月内；如果没有这种边界，skew 的影响是永久的，只能靠发版修复。

常见问题​

feature flag 的最佳实践有哪些？​

一个标志只承载一种语义；需要新语义时新增字段而不是复用旧标志；标志绑定明确的时间窗口或版本号；改语义前枚举所有读方（尤其未升级的旧客户端），确认它们不会把新值按旧含义解读。本例的停采就是复用旧标志的直接后果。

服务端字段如何做到向后兼容？​

只增不改：已有字段的含义、类型、判定行为保持稳定，新语义用新字段表达，旧客户端读到不认识的字段应当安全忽略。字段名字没变但含义变了，对所有存量读方来说就是一次破坏性变更。

旧版本客户端读到新语义数据怎么办？​

三步：把影响限定在有自愈边界的时间窗口内（如自然月翻转后自动恢复）；发布新版本时主动提醒升级，缩短并存期；服务端写入保持 upsert 幂等，让新旧版本的交错写入可以安全混合，不回滚、不清洗。

在 catch 块里想"把异常原样往上抛"，顺手写了 throw;——习惯了 C# 的 bare rethrow 写法——结果 tsx/esbuild 直接转换失败：Unexpected ";"。

在开发 AI运营 时遇到此问题——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。

TL;DR​

JavaScript 没有 bare rethrow 语法。throw;（裸 throw）在 Node、tsc、esbuild 三个工具链里都是编译期 SyntaxError。要重新抛出捕获到的异常，必须 throw e（catch 块得带绑定参数）；想换成新异常就 throw new Error(...)。

问题现象​

同一个 throw;，在不同工具链里的报错措辞不同，但全是语法错误（不是运行时错误）：

try {
  something();
} catch {
  throw;   // ← 裸重抛
}

最迷惑的是 esbuild 那条 Unexpected ";"——很容易让人以为是 "esbuild/tsx 不支持某种新语法"。但把同一段代码丢进 Node 原生跑，报的是一模一样的 SyntaxError。这不是工具的局限，是语言本身就没有这种写法。

根因​

ECMAScript 的 throw 语句语法强制要求一个表达式：

ThrowStatement : throw Expression ;

也就是说 throw 后面必须跟一个值（throw err、throw new Error()、throw "fail"），分号前不能为空。JavaScript 没有"裸 throw = 重新抛出当前异常"的语义——这是它和 C# / Java / Python 的关键区别：

一个常见的混淆点：ES2019 引入了 optional catch binding（catch {} 可以省略参数），但这和 bare throw 是两回事。即使 catch 带了绑定，写 throw; 依然报错——

try { f(); } catch (e) { throw; }   // 仍是 SyntaxError，参数 e 不会自动喂给 throw

实测在 tsx 里同样是 Unexpected ";"。throw 后面的表达式不能省，没有例外。

解决方案​

按"想干什么"对号入座：

// 1. 重新抛出原异常（rethrow）—— 最常见诉求
try {
  doWork();
} catch (e) {
  log(e);
  throw e;            // ✅ 带上 e
}

// 2. 换成新异常（wrap）
try {
  doWork();
} catch (e) {
  throw new Error(`处理失败: ${e.message}`);   // ✅ throw + 表达式
}

// 3. 用 ES2019 的 catch {} 时，省略了参数就没法 rethrow，只能抛新异常
try {
  doWork();
} catch {
  throw new Error("doWork 失败");   // ✅ 这里写 throw; 是错的
}

最小可运行复现 + 修复，直接用 tsx 跑：

function risky(): void {
  throw new Error("origin");
}

function rethrowOptional(): void {
  try {
    risky();
  } catch (e) {          // ← 必须接收 e
    console.log("caught, rethrowing");
    throw e;             // ← 而不是 throw;
  }
}

try {
  rethrowOptional();
} catch (e) {
  console.log("recovered:", (e as Error).message);   // origin
}

关于调用栈：throw e 复用的是同一个 error 对象，它的 .stack 在 new Error 时就已经捕获，rethrow 不会覆盖；只有 throw new Error(...) 才会从当前抛出点重新生成栈。所以"rethrow 会不会丢栈"的答案是——不会，只要你不 new 一个新的。

异常处理的另一个常见坑，是 catch 块干脆把异常吞掉、对外表现为静默失败，见 Python 任务全标 failed 却不报错？try/except 吞掉了异常——跨语言都值得警惕。

注意事项​

常见问题​

JavaScript 怎么重新抛出（rethrow）捕获到的异常？​

用 throw e，且 catch 必须带绑定参数：catch (e) { ...; throw e; }。JavaScript 没有 bare rethrow，单独写 throw; 是 SyntaxError，Node、tsc、esbuild 三个工具链都会在编译期拒绝，这不是任何一个工具的局限。

JavaScript 重新抛出异常会保留原始调用栈吗？​

会。throw e 复用的是同一个 error 对象，它的 .stack 在 new Error 构造时就已经捕获，rethrow 不会覆盖或重置。只有 throw new Error(...) 才会从当前抛出点重新生成调用栈——所以排查时要看最早抛出位置，就用 throw e。

JavaScript try/catch 里怎么正确 rethrow？​

catch 必须先接收参数，再把它抛回：try { ... } catch (e) { log(e); throw e; }。如果用了 ES2019 的 catch {}（省略参数），就没有变量可抛，只能 throw new Error(...) 抛一个新异常。无论哪种，throw 后都必须跟表达式，throw; 永远非法。

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

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']