企业官网建设流程全解析

Parcel Scope Hoisting Packager 原理深度解析：从 import 替换到符号解析的完整打包流程

【免费下载链接】parcelThe zero configuration build tool for the web. 📦🚀项目地址: https://gitcode.com/gh_mirrors/pa/parcel

本文以 Parcel 仓库中 docs/Scopehoisting Packager.md 为核心骨架，结合 ScopeHoistingPackager.js、BundleGraph.js 等源码实现，系统讲解 Parcel 生产构建模式下 JS Packager 的打包流程：资产如何被加载、判断是否包装（wrap）、通过正则一次性完成依赖内联与符号替换，以及getSymbolResolution如何递归穿透 re-export 找到真正导出该符号的资产。读完本文，你将理解 Parcel Scope Hoisting 打包器从package()入口到最终产物生成的完整调用链，掌握 wrapped/unwrapped 资产的判别逻辑、符号解析的四种返回形态与 interop 处理，并能据此定位构建产物中各种标识符（如$id$export$foo、parcelRequire("id").bar）的来源。

注：关于单个资产（single asset）为何可以被跳过（skip）而不进入产物，属于 Scope Hoisting 的整体概念范畴，本文不展开，详见 docs/Scopehoisting.md 中的 "Skipping assets (deferring and skipping during bundling)" 一节。本文聚焦于Scope Hoisting Packager（作用域提升打包器）本身的打包实现。

一、Scope Hoisting Packager 在 Parcel 中的位置

在 Parcel 中，JS 打包器位于 packages/packagers/js/src/index.js，它根据环境配置在两种打包器之间二选一：

• DevPackager：开发构建使用，采用类似 browserify 的运行时注册表（module registry）方式，每个模块都通过parcelRequire.register包裹，依赖通过require调用解析；
• ScopeHoistingPackager：生产构建（shouldScopeHoist为真）使用，将多个资产直接拼接进同一作用域，用普通变量访问替换parcelRequire("id").foo式的注册表调用，从而缩小体积、提升压缩器（minifier）的效果。

源码中可见二者的选择逻辑（index.js#L93-L107）：

let packager = bundle.env.shouldScopeHoist ? new ScopeHoistingPackager(options, bundleGraph, bundle, config.parcelRequireName, config.unstable_asyncBundleRuntime) : new DevPackager(options, bundleGraph, bundle, config.parcelRequireName);

ScopeHoistingPackager 的核心类定义在 packages/packagers/js/src/ScopeHoistingPackager.js（共 1500+ 行），构造函数接收bundleGraph、bundle、parcelRequireName、useAsyncBundleRuntime等参数，并根据bundle.env.outputFormat选择对应的输出格式实现：

• esmodule→ESMOutputFormat
• commonjs→CJSOutputFormat
• global→GlobalOutputFormat

其中parcelRequireName的生成逻辑在 index.js#L53-L65：读取项目 package.json 的name字段并取哈希后 4 位拼接，形如parcelRequirexxxx，目的是让同一页面上的多个 Parcel 构建产物可以共存而不冲突。

此外，JS 打包器还支持一个配置项unstable_asyncBundleRuntime（布尔值，index.js#L22-L30 中的 schema 校验），用于启用实验性的异步 bundle 运行时（bundle queue），本文后面会涉及它在shouldBundleQueue/runWhenReady中的使用。

二、打包入口package()：三步主流程

package()是打包的起点（ScopeHoistingPackager.js#L130-L273），整个流程可以概括为文档中描述的三步：

1. loadAssets()：从缓存中加载所有资产的代码内容，并判断哪些资产需要被包装（wrapped）。
2. processAsset()/visitAsset()→buildAsset()：递归解析依赖的 specifier、内联依赖，并把结果拼接到顶层res字符串上。
3. 启动过程：对每个资产调用processAsset()，并对已在其他位置被内联过的资产跳过，保证每个资产只处理一次。

2.1 加载资产与判定 wrapped：loadAssets()

loadAssets()（ScopeHoistingPackager.js#L310-L362）使用PromiseQueue（最大并发 32）并行读取每个资产的代码与 source map，并同时判断资产是否需要被parcelRequire.register包装。判定条件（满足其一即 wrapped）：

asset.meta.shouldWrap || this.bundle.env.sourceType === 'script' || this.bundleGraph.isAssetReferenced(this.bundle, asset) || this.bundleGraph .getIncomingDependencies(asset) .some(dep => dep.meta.shouldWrap && dep.specifierType !== 'url')

即：转换器标记了shouldWrap、环境是 script 类型、资产被其他 bundle 引用、或存在标记为 wrap 的非 URL 类型依赖。同时还有一个特例：常量模块（constant module）即使满足条件也不会被包装，除非它被某个 lazy 依赖引用：

if (!asset.meta.isConstantModule || this.bundleGraph.getIncomingDependencies(asset).some(dep => dep.priority === 'lazy')) { this.wrappedAssets.add(asset.id); wrapped.push(asset); }

此外，一旦某个资产被包装，其依赖子树中的所有非常量模块也会被连带包装（第二个遍历循环，L343-L358），因为被包装资产的内部代码无法再引用顶层提升变量，必须整体走注册表路径。

2.2 主循环：wrapped 优先、逐资产拼接

package()中有一个内部函数processAsset，它调用visitAsset得到[content, map, lines]三元组，将其追加到顶层res字符串并累计行数（用于 source map 偏移）。

拼接顺序非常讲究：

1. 先处理所有 wrapped 资产，把它们提升到 bundle 顶部（注释原文："Hoist wrapped asset to the top of the bundle to ensure that they are registered before they are used"），保证parcelRequire.register先于使用被调用；
2. 再遍历与 bundle 直接相连的资产（bundle.traverseAssets），每个资产处理完后skipChildren，因为依赖会通过代码中的import语句替换被处理，而不是通过图遍历继续深入。

2.3 收尾：prelude、entry 执行与 postlude

所有资产拼接完毕后，package()按顺序完成收尾：

• 调用buildBundlePrelude()生成头部（interpreter/hashbang、输出格式专属 prelude、按需引入的 helpers、parcelRequire运行时 prelude、worker 的importScripts），并将其前置到res；
• 对于 wrapped 的 entry 资产，追加parcelRequire("<publicId>");调用以触发执行；若是主 entry 且有导出符号，则追加var ${entryExports} = parcelRequire(...)；
• 调用输出格式的buildBundlePostlude()生成尾部；
• 对于outputFormat === 'global'且sourceType === 'script'的 bundle，主 entry 会被提升到 bundle 包装之外（使其顶层变量成为真实浏览器脚本的全局变量），并用replaceScriptDependencies把 runtimes 的依赖引用替换为parcelRequire调用。

其中 prelude 的实际代码定义在 packages/packagers/js/src/helpers.js：它维护$parcel$modules与$parcel$inits两个对象，parcelRequire优先从$parcel$global上取（兼容多 bundle 共享同一注册表），取不到则现场创建并注册到全局。

三、核心构建函数buildAsset()：五步内联与替换

buildAsset()（ScopeHoistingPackager.js#L466-L703）是每个资产的处理核心，文档将其拆解为五步：

1. 跳过判断：若资产应被跳过，则不输出资产本身内容，仅递归拼接其依赖资产；
2. buildReplacements()：生成文本替换用的两张 Map；
3. buildAssetPrelude()：按需生成 interop flag 调用与合成的 exports 对象；
4. REPLACEMENT_RE正则替换：一次性完成 import 内联、符号替换与行数统计；
5. 按需用parcelRequire.register("id", ...)包装结果。

3.1 第一步：跳过资产（shouldSkipAsset）

shouldSkipAsset（L1491-L1501）返回 true 的条件是：

• 该资产是 script entry（outputFormat === 'global'且sourceType === 'script'的主 entry，会被提升到 bundle 外），或
• 资产无副作用（sideEffects === false）且getUsedSymbols(asset).size == 0且未被其他 bundle 引用。

被跳过的资产，其内容不输出，但它的依赖仍会被处理（对应文档第 1 条："ignore the current asset, callbuildAsset()for dependency assets and concatenate only them together"）。

3.2 第二步：构建替换 Map（buildReplacements）

buildReplacements()（L705-L810）产出两张表：

依赖表depMap：键形如`${assetId}:${specifier}${specifiertype}`（specifierType 仅当为esm时追加:esm后缀），值为该 import 对应的Dependency数组。之所以是数组，是因为单个 import 语句可能因 re-export 被解析到多个资产（源码注释："A single${id}:${specifier}:esmmight have been resolved to multiple assets due to reexports"）。这张表用于解析转换器（transformer）插入的import "id";声明。

符号替换表replacements：键是依赖符号的本地部分（形如`$id$import$foo`），值是getSymbolResolution的解析结果（如`$id$export$bar`或parcelRequire("id").bar）。

在构建replacements时还处理了几种特殊情况：

• 异步依赖（lazy）：优先取bundleGraph.resolveAsyncDependency返回的底层资产（若直接解析为资产，则替换为Promise.resolve(${symbol})）；即使所有使用的符号都被静态分析，异步依赖仍需要 namespace 对象，这是通过转换器写入的dep.meta.promiseSymbol记录并在此处处理的；
• wrapped 资产的 exports 命名空间：若资产被包装（或 commonjs 输出下的主 entry），则把`$${assetId}$exports`替换回module.exports（对应文档第 3 条中"for wrapped assets, this has to be replaced back tomodule.exports"）；
• 外部模块（external）：无法解析且非 optional 的依赖调用addExternal()处理（详见第七节）。

3.3 第三步：合成资产前导（buildAssetPrelude）

buildAssetPrelude()（L1151-L1363）返回[prepend, prependLineCount, append]三元组，其职责是：

生成 exports namespace 对象。当资产不满足静态导出（staticExports === false）、被包装、namespace 被使用、或需要 default interop 时，会生成：

var $${assetId}$exports = {};

若被包装或为 commonjs 主 entry，则省略该声明（直接使用包装器提供的module.exports）。

生成__esModuleinterop flag。当资产有default导出且*符号被使用时：

$parcel$defineInteropFlag($${assetId}$exports);

仅为被使用的 re/export 生成$parcel$export/$parcel$exportWildcard调用（对应文档："including generation of the$parcel$exportand$parcel$exportWildcardcalls only for used re/exports"）：

• 对export * from "..."：若目标资产被包装或导出不静态，追加$parcel$exportWildcard($$assetId$exports, obj);；否则逐个对getUsedSymbols(dep)中除default/__esModule外的符号追加$parcel$export(...)；
• 对当前资产自身被使用的导出：基于getIncomingDependencies的 used symbols（而非资产自身的 used exports，以便覆盖 re-export 的符号）生成 getter/setter：

$parcel$export($${assetId}$exports, "foo", () => $id$export$foo);

为什么用 getter/setter 而非直接赋值？源码注释给出了答案：这是为了模拟 ESM 的 live bindings——当原绑定被修改时，exports 对象上的属性同步更新，比在每个赋值点插入额外语句更简单。这也是文档在 docs/Scopehoisting.md 中强调"/*#__PURE__*/注释重要"的原因：被移除的export语句对应的变量成为死代码，纯注释让 minifier 可以安全删除右侧表达式。

3.4 第四步：单趟正则替换（REPLACEMENT_RE）

这是buildAsset中最精巧的部分。REPLACEMENT_RE定义在 ScopeHoistingPackager.js#L39-L40：

const REPLACEMENT_RE = /\n|import\s+"([0-9a-f]{16}:.+?)";|(?:\$[0-9a-f]{16}\$exports)|(?:\$[0-9a-f]{16}\$(?:import|importAsync|require)\$[0-9a-f]+(?:\$[0-9a-f]+)?)/g;

它在一个正则中同时匹配三类内容（源码注释："This is all done in a single regex so that we only do one pass over the whole code"），并同步统计换行数以维护 source map：

1. 换行符\n：不做替换，仅推进行计数（lineCount++）与列起点；
2. import "id";：用依赖资产的源码替换（递归调用buildAsset()）。若被引用资产是 wrapped，则不内联，而是放进depContent数组、在当前资产之后输出（保证循环依赖时模块已注册）；同时调用getHoistedParcelRequires读取hoistedRequires列表并把需要的parcelRequire调用前置。若当前资产不包装，则依赖代码会被拼接到res顶部（res = depCode + '\n' + res;）；
3. $id$exports：在替换表中查找。对于 wrapped 资产，前面buildReplacements已把它映射回module.exports；
4. $id$import|importAsync|require$foo：在replacements表中查找并替换为解析后的标识符，若未命中则原样保留（replacements.get(m) ?? m）。

替换过程中还同步维护 source map：当替换文本与原文长度不一致时，调用sourceMap.offsetColumns修正列偏移；依赖被内联时用sourceMap.addSourceMap叠加依赖的 map 并按行数偏移。若整个资产既无依赖也无替换，则走countLines(code)的简单路径，避免不必要的正则开销。

3.5 第五步：parcelRequire.register 包装

如果资产被判定为 wrapped（L668-L692），最终代码会被包装为：

parcelRegister("${publicId}", function(module, exports) { ${code} });

随后把depContent中收集的依赖代码追加在包装之后（注释："Dependencies must be inserted AFTER the asset is registered so that circular dependencies work"——循环依赖要求先注册再执行依赖的副作用）。此时needsPrelude被置为 true，保证parcelRequire运行时 prelude 会被包含进产物。

四、符号解析：Packager 包装层getSymbolResolution()

ScopeHoistingPackager.getSymbolResolution()（L983-L1109）是围绕bundleGraph.getSymbolResolution()的包装（对应文档第 30-45 行）。它多接收一个dep参数，用于判断两件事：

• 是否需要 CJS interop（当依赖是 ESM import 时）；
• 是否是非条件 import（此时需要生成提升的parcelRequire调用）。

parentAsset参数的用途是：让被包装的资产在引用自身的 namespace 对象时，使用module.exports而非`$id$exports`（对应文档第 36 行）。

它返回的解析表达式有五种形态（文档第 38-43 行）：

核心逻辑分支如下：

• namespace 请求（imported === '*'、exportSymbol === '*'、或 default interop）：返回 namespace 对象。若资产被包装且引用自身，直接返回module.exports；
• 属性访问（目标被包装、导出非静态、symbol为空、或外部 CJS 库依赖）：用getPropertyAccess生成obj.exportSymbol或obj["exportSymbol"]成员访问；若 import 的是default且目标资产有*导出且需要 interop，则返回(/*@__PURE__*/$parcel$interopDefault(${obj}))；
• 直接引用（静态导出且已解析出顶层变量symbol）：返回replacements?.get(symbol) || symbol。

getPropertyAccess（L450-L456）会判断属性名是否为合法标识符，合法用.foo，否则用["foo"]。

此外，文档还强调该方法会通过变更hoistedRequires列表来跟踪 wrapped 资产的 import（第 45 行）。当解析结果指向一个 wrapped 资产，而该依赖是顶层（非条件）导入时，会记录：

hoisted.set(resolvedAsset.id, `var $${publicId} = parcelRequire(${JSON.stringify(publicId)});`);

这些提升的变量声明随后由getHoistedParcelRequires（L1111-L1149）在 import 替换处输出，其顺序保证被包装依赖的副作用按源码顺序执行：如果解析资产不是hoistedRequires中的第一个，还会先插入一个直接的parcelRequire("id");调用确保它先运行。

五、BundleGraph 层的递归符号解析

bundleGraph.getSymbolResolution()的实现在 packages/core/core/src/BundleGraph.js#L1658。它传递性地/递归地遍历资产的 re-export 链，找到指定导出真正被定义的地方（对应文档第 47-53 行）。这使得解析到的可以是实际的值，而不只是某个 re-export 绑定。

5.1 解析流程与boundary参数

算法核心（对应源码 L1658-L1809）：

1. symbol === '*'时直接返回 namespace（exportSymbol: '*'）；
2. 否则取asset.symbols.get(symbol).local作为identifier，逆序遍历资产的依赖；
3. 对每个依赖，通过symbolLookup（local -> imported反查表）判断identifier是否由该依赖 re-export 而来；若是，递归解析被解析资产上的对应符号；
4. 对export *情况（depSymbols.get('*')?.local === '*'且非default导出），递归到被解析资产继续查找；
5. 若在多个 re-export 中都找到了符号（如两个export *冲突），则收集potentialResults，最终只有一个候选时返回它，多个候选时视为 bailout（见下文）。

boundary参数（即当前 bundle）用于限制递归深度（文档第 53 行）：一旦递归离开当前 bundle，解析就停止。原因是：资产 A 使用资产 B 的值，通常建模为 A→B 的依赖，依赖还被用来判断"资产是否被其他 bundle 需要从而必须parcelRequire注册"。这种"跨资产使用但不一定有依赖"的不一致（discrepancy）在单 bundle 内可以处理，跨 bundle 则不行，所以用boundary截断。源码中assetOutside = boundary && !this.bundleHasAsset(boundary, asset)正是这一判断。

5.2 三种解析结果与 bailout

文档第 55-63 行总结了三种可能的解析结果（symbol字段）：

1. 找到导出：symbol为顶层变量名。返回值包含asset、exportSymbol字符串、symbol，值可通过`$asset.id$exports[exportSymbol]`访问，通常也可通过顶层变量symbol直接访问。文档给出的示例：对getSymbolResolution(math.js, "add")返回{asset: "math.js", exportSymbol: "add", symbol: "$fa6943ce8a6b29$export$add"}；
2. 未找到导出：symbol === undefined。理论上这种情况应已被 symbol propagation（符号传播）提前捕获；
3. 导出存在但未使用：symbol === false（对应源码中依赖被 skip 的分支，isDependencySkipped(dep)为真时置为 false）；
4. bailout（有多个可能性）：symbol === null，调用方应回退到`$resolvedAsset$exports[exportsSymbol]`的运行时属性访问。

文档给出了两个典型的 bailout 场景：

• 多个冲突的 re-export：export * from "./nonstatic-cjs1.js"; export * from "./nonstatic-cjs1.js";（原文如此，即两个export *的候选无法在构建期静态决定，只能留到运行时决定跟随哪个 re-export）；
• 目标资产本身是非静态 CJS：此时无论如何都应使用module.exports[exportsSymbol]。

源码中potentialResults.length == 1时返回唯一候选，否则进入 bailout 路径（found/skipped/identifier的组合），与文档描述完全对应。

六、prelude、helpers 与输出格式

Scope Hoisting 的产物头部（prelude）在buildBundlePrelude()（L1365-L1472）中生成，内容依次为：

1. hashbang：主 entry 若记录了 interpreter（如#!/usr/bin/env node），且不是 async bundle、目标非浏览器，则原样输出；
2. 输出格式专属 prelude：由ESMOutputFormat/CJSOutputFormat/GlobalOutputFormat的buildBundlePrelude()生成（例如 ESM 格式可能输出import语句）——三种输出格式类定义在同目录的 ESMOutputFormat.js、CJSOutputFormat.js、GlobalOutputFormat.js；
3. 按需 helper：根据usedHelpers集合输出对应函数。这些 helper 包括$parcel$global、$parcel$defineInteropFlag、$parcel$export、$parcel$exportWildcard、$parcel$interopDefault、$parcel$import、$parcel$resolve等，定义在 helpers.js。helper 的使用情况由转换器写入asset.meta.usedHelpers（位掩码，见 buildAsset 中 L519-L542）以及打包器运行时的按需收集（如usedHelpers.add('$parcel$interopDefault')）；
4. 运行时 prelude：当needsPrelude为真时，判断当前 bundle 是否"可能是第一个加载的 JS bundle"（mightBeFirstJS，依据父 bundle 类型、是否 entry bundle group、是否 isolated 等），若是则输出完整 prelude（prelude(parcelRequireName)，定义见 helpers.js#L6-L38）；否则只取现有全局注册表：var parcelRequire = $parcel$global[...]；
5. worker/worklet 的 importScripts：为 sibling bundle 输出importScripts("...")或import "..."（ESM worker 中不允许importScripts）。

这里可以看到文档反复提到的"module registry (prelude)"开销来源：只有确实需要运行时注册表（如跨 bundle 复用、条件 require）时，prelude 才被包含；完全静态的 bundle 可以省掉它。

七、边界情况：库模式 externals、async bundle 与条件执行

7.1 库模式（library）下的外部依赖

在package()开头（L139-L151），如果目标是 library 构建（env.isLibrary）或输出格式为 commonjs、或 ESM 但非 async bundle，则对每个被引用的 sibling bundle 建立externals映射（key 为相对 bundle 路径）。库构建的加载器运行时被排除，改为在 entry bundle 中为每个 bundle group 添加指向 sibling bundle 的 import，供其他打包器（如 webpack/rollup）后续处理。

addExternal()（L812-L960）负责把未解析的依赖转成外部引用：

• 浏览器global输出格式下不支持外部模块，直接抛出ThrowableDiagnostic（"External modules are not supported when building for browser"）；
• commonjs 输出下，为保持导出 live，始终使用属性访问：default 导入需要 interop 时生成($parcel$interopDefault(${renamed}))，否则renamed.default；
• ESM 输出下使用命名导入（同样保持 live），通过getTopLevelName生成以 bundle publicId 和 specifier 为前缀的去重顶层变量名，避免本地变量遮蔽。

7.2 async bundle 与 bundle queue 运行时

isAsyncBundle在构造函数中判定：存在 JS 类型的父 bundle、环境未隔离且 bundleBehavior 不是 isolated。对 async bundle，主 entry 不会被立即执行（可能要等 sibling bundle 加载完成），因此entries会过滤掉主 entry。

shouldBundleQueue()（L275-L288）判断是否需要实验性的 bundle queue 运行时（要求useAsyncBundleRuntime、被 HTML 引用、ESM 输出等）；若需要，runWhenReady()会把 entry 的执行代码包装为$parcel$global.rwr(bundlePublicId, fn, [依赖bundle列表]);，对应的bundleQueuePrelude定义在 helpers.js#L54 起，实现"等待依赖 bundle 全部加载后再执行"的队列语义。

7.3 条件 require 与运行时去重

文档在 docs/Scopehoisting.md 中说明了"为什么还需要 registry"：跨 bundle 复用的资产、以及if/函数内出现的条件require无法用纯 ESM 声明表达。因此，拥有至少一个条件 incoming 依赖或被其他 bundle 使用的资产必须被parcelRequire.register包装；包装子图内，import 不能再替换为顶层变量，而是替换为 CJS 等价形式（var $id = parcelRequire("id");然后$id.foo），这样条件分支内的副作用才按运行时语义执行。

同时，registry 的另一个价值是运行时去重（runtime deduplication）：当一个资产被包含进多个 bundle 时（如两个 async bundle 各自内联了同一份lib），通过共享$parcel$global上的注册表，保证该资产最多只求值一次，副作用不重复执行，且instanceof/constructor等身份判断保持成立。

八、Interop：ESM 导入 CJS 的默认导出处理

Parcel 对"ESM 默认导入 CommonJS"遵循社区惯例（文档 docs/Scopehoisting.md 的 Interop 一节）：

• 同步 ESM 默认导入 CJS 时，import v from './other'中v应等于该 CJS 模块的 exports namespace 对象（如{ x: 2, y: 3 }）；
• 但若该模块实际上是"由 ESM 转译来的 CJS"（如 Babel/tsc 转译后发布到 npm），转译器会写入exports.__esModule = true;，此时默认导入应指向转译后的exports.default；
• 传统的解决方式是运行时 helper：interopRequireDefault(obj)检查__esModule标志。

借助静态分析（symbol propagation 提供的符号信息），Scope Hoisting 打包器可以在很多情况下省略这个运行时调用：当导入方被静态判定为 ESM 或 ESM 转 CJS 时，直接生成renamed.default或($parcel$interopDefault(...))。interop 相关的判断分散在getSymbolResolution（isDefaultInterop分支，L1047-L1054）、needsDefaultInterop()（L1474-L1489）与addExternal中：需要满足*符号存在、无default符号但存在 default 导入依赖等条件。

九、从文档到源码：关键文件速查

十、总结

Parcel 的 Scope Hoisting Packager 是生产构建中"零配置"高性能输出的核心引擎。本文沿着 docs/Scopehoisting Packager.md 的脉络，完整还原了它的工作方式：

• 入口package()：先loadAssets加载代码并判定 wrapped 集合，再对每个资产执行processAsset→visitAsset→buildAsset，wrapped 资产优先置于 bundle 顶部，依赖通过import语句替换而非图遍历处理；
• buildAsset()五步：跳过判断 →buildReplacements构建依赖表与符号替换表 →buildAssetPrelude合成 exports 对象与$parcel$export/$parcel$exportWildcard/interop flag → 单趟REPLACEMENT_RE正则完成 import 内联、符号替换与 source map 行/列维护 → 按需parcelRequire.register包装；
• 两级符号解析：Packager 层的getSymbolResolution在bundleGraph.getSymbolResolution之上叠加了 interop 判定、hoistedRequires收集与 wrapped 资产语义修正；BundleGraph 层则递归穿透 re-export 链，返回"找到（顶层变量）／未找到（undefined）／未使用（false）／bailout（null）"四种结果，boundary参数保证解析在离开 bundle 时停止。

理解这套机制，你就能读懂 Parcel 构建产物中各种$id$export$foo、parcelRequire("id")、$parcel$interopDefault(...)标识符的来源，也就能在排查产物异常、评估 bundle 体积、或为 Parcel 贡献代码时快速定位到对应实现位置。

【免费下载链接】parcelThe zero configuration build tool for the web. 📦🚀项目地址: https://gitcode.com/gh_mirrors/pa/parcel