尧图网页设计 
从 route-kind 快照读懂 Next.js Turbopack 树摇Tree Shaking分析器模块切分、依赖图与导出分片【免费下载链接】next.jsThe React Framework项目地址: https://gitcode.com/GitHub_Trending/next/next.js导读本文以 Turbopack 中针对 Next.js 真实编译产物RouteKind模块的树摇分析测试快照为对象逐段拆解 route-kind/output.md 的完整输出含义。你将理解Turbopack 如何把一个带运行时初始化 IIFE 的export var模块切割为不同 Part、为什么带副作用的枚举初始化无法被摇掉、__TURBOPACK_PART__与__TURBOPACK_VAR__是什么以及这份快照背后测试脚手架fixture 驱动的逐阶段分析流水线的工作原理。读完即可独立阅读 Turbopack 其余tree-shaker/analyzer/*快照并用于排查打包行为。快照的前世今生一份「测试输出」文档首先要澄清这份关联文档的定位它不是 Next.js 用户文档而是Turbopack 树摇分析器的快照测试产物snapshot/expected output。它以output.md的形式固定在仓库中与同目录的input.js一一对应供 Rust 单测比对。相关文件都位于 tests/tree-shaker/analyzer/其中每个子目录1、route-kind、nanoid、next-response、node-fetch、otel-core、simple、complex、logger、dce、shared-and-side-effects等数十个场景都是一个独立用例结构统一为input.js待分析的入口模块源码多为真实库编译后的产物output.md由测试框架自动生成的预期分析快照可选config.json配置测试导出的导出名列表见 3/config.json 与 test-config-1/config.json。也就是说本文通篇「解析」的对象正是该测试套件对route-kind这个用例自动生成的可读性报告。输入是什么TypeScript 枚举被编译后的形态先看被分析源码 route-kind/input.jsexport var RouteKind; (function(RouteKind) { RouteKind[PAGES] PAGES; RouteKind[PAGES_API] PAGES_API; RouteKind[APP_PAGE] APP_PAGE; RouteKind[APP_ROUTE] APP_ROUTE; })(RouteKind || (RouteKind {}));这实际是 Next.js 中RouteKind枚举经 TypeScript 编译器降级downlevel后的产物。其「真身」位于 packages/next/src/server/route-kind.tsexport const enum RouteKind { PAGES PAGES, PAGES_API PAGES_API, APP_PAGE APP_PAGE, APP_ROUTE APP_ROUTE, IMAGE IMAGE, }从源码注释与导入点可以确认它在 Next.js 路由体系中的语义注意当前 route-kind.ts 里比本快照 fixture 多出一个IMAGE成员说明 fixture 采集自较早编译版本分析结论不受影响PAGESpages/目录下的 React 页面PAGES_APIpages/api/下的 API 路由APP_PAGEapp/目录下以page.{j,t}s{,x}命名的 React 页面APP_ROUTEapp/目录下以route.{j,t}s{,x}命名的 API/元数据路由。它被 Next.js 的构建入口与模板大量引用例如 build/entries.ts、build/templates/pages.ts、pages-api.ts、app-route.ts 等。因此 Turbopack 打「Next.js 自身包」时几乎必然遇到这段代码route-kind用例的价值就在于验证树摇器对这种「export var 自执行初始化函数」模式的切分正确性。为什么它不能简单当成一个普通变量声明因为RouteKind的成员不是静态初始化而是通过一次带副作用语义的函数调用立即执行表达式在运行时填充的。后文快照的每一节都围绕这条主线展开。快照第一节# Items把模块拆成原子「条目」树摇分析的第一步是把模块顶层语句拆分为若干Item条目。快照开头写道Count: 3随后枚举了两条明细Item 1Stmt 0, VarDeclarator(0)export var RouteKind;Declares: RouteKindWrite: RouteKind它对应export var RouteKind;这一条顶层语句语句 0 的声明符 0。在分析器中该条目被记录为「声明并写入变量RouteKind」——注意此时变量值是undefined真正的赋值发生在下一条语句。Item 2Stmt 1, Normal(function(RouteKind) { ... })(RouteKind || (RouteKind {}));Side effectsReads: RouteKindWrite: RouteKind它是一条「普通」顶层语句Normal。分析器标记它含副作用Side effects同时读取并写入RouteKind既把当前值RouteKind || (RouteKind {})的兜底对象读入又为四个键写入字符串值。为什么总数是 3 却只列出 2 条对照测试脚手架 tests.rs 的实现可以看到Count用全部item_ids长度含 Group 类条目而明细循环里遇到ItemId::Group(_)直接continueGroup 条目不在 Items 明细中单独展示。第 3 个隐藏条目export RouteKind绑定在后面的 mermaid 图中以Item3[export RouteKind]出现。Item 的元数据字段Hoisted/Side effects/Declares/Reads/Write/Reads (eventual)/Write (eventual)正是由 tests.rs 依据每个 Item 的分析结果打印的数据来源是ItemData定义在 module_fragments/graph.rs。四个 Phase 的 mermaid 依赖图依赖边如何逐阶段生长快照用 5 张 mermaid 图展示依赖图的演化过程对应的正是 tests.rs 中测试代码的分析流水线快照小节触发的分析步骤图的状态# Phase 1hoist_vars_and_bindings()提升变量与绑定只有 3 个孤立节点无依赖边# Phase 2evaluate_immediate()立即读写求值出现Item2 -- Item1、Item3 -- Item2、Item3 -- Item1三条边# Phase 3evaluate_eventual()兜底/延迟求值与 Phase 2 相同# Phase 4handle_exports()处理导出与 Phase 3 相同# Finalhandle_explicit_deps()finalize()缩并强连通分量只剩一个合并节点N0对route-kind用例三个节点含义为Item1export var RouteKind变量声明Item2填充成员的 IIFENormalItem3名称为export RouteKind的导出绑定节点。Phase 2 中新增的三条依赖边反映了求值语义IIFE 要读写RouteKind因此必须先于变量声明条目Item2 → Item1导出绑定要拿到最终值因此同时依赖写入者与声明者Item3 → Item2、Item3 → Item1。这些边一旦形成就贯穿 Phase 3、4说明对普通立即求值即可确定依赖无需延迟求值补充新边——这正是「变量声明 立即初始化 导出」这一模式的典型形态。图的渲染逻辑强依赖--与弱依赖-.-的区别、节点标签转义等见 tests.rs。# Final一节展示缩并后的最终依赖图由于export RouteKind需要同时拉入「声明」与「副作用写入」两条路径三者被归并进同一个强连通组N0[Items: [ItemId(0, VarDeclarator(0)), ItemId(1, Normal), ItemId(Export(RouteKind, #2), RouteKind))]]也就是说对RouteKind的任意导入都必须保留整段声明 初始化代码这是后续 Part 切分的最关键输入。Entrypoints哪些「入口点」需要被满足# Entrypoints展示了模块切分后需要提供的入口集合Entrypoints按 Key 排序后打印见 tests.rs{ ModuleEvaluation: 0, Export( RouteKind, ): 0, Exports: 1, }三个 Key 的含义如下ModuleEvaluation模块自评估import 该模块即执行其顶层副作用指向模块索引0Export(RouteKind)具名导出RouteKind同样落在模块索引0Exports代表「把该模块的导出整体暴露」的入口落在模块索引1。注意此处的模块索引是指下一节# Modules (dev/prod)中的Part编号。ModuleEvaluation与具名导出都指向Part 0这解释了为何模块评估module eval的合并产物里IIFE 初始化代码被原样保留——模块只要被执行RouteKind就必须先被赋好值。Modules 与 Part 切分dev / prod 双份产物快照在# Entrypoints之后分别以# Modules (dev)与# Modules (prod)各打印一次切分结果并在每份里给出Part 0、Part 1以及Merged (module eval)三段代码。Part 0真正执行的「主体分片」var RouteKind; (function(RouteKind) { RouteKind[PAGES] PAGES; // ... 四个成员 })(RouteKind || (RouteKind {})); export { RouteKind }; export { RouteKind as a } from __TURBOPACK_VAR__ assert { __turbopack_var__: true }; export { };它几乎原样保留了输入代码额外附带三样 Turbopack 内部机制export { RouteKind }把运行时变量直接作为具名导出export { RouteKind as a } from __TURBOPACK_VAR__通过特殊虚拟模块__TURBOPACK_VAR__把该变量再以内部别名a暴露给其他分片引用该常量对应 module_fragments/mod.rs 附近对分片内部导入源的定义机制export { }空的具名导出占位用于承接可能的命名空间访问。Part 1导出描述性的「薄分片」export { RouteKind } from __TURBOPACK_PART__ assert { __turbopack_part__: export RouteKind };Part 1 本身不包含任何执行代码只通过特殊模块__TURBOPACK_PART__assert { __turbopack_part__: export RouteKind }声明「本分片的作用是重导出export RouteKind那个分片」。这种把导出关系与执行代码解耦的设计使得 Turbopack 能在需要时按需拼接分片、而无需重复执行初始化。Merged (module eval)面向模块评估的最终合并结果var RouteKind; (function(RouteKind) { RouteKind[PAGES] PAGES; RouteKind[PAGES_API] PAGES_API; RouteKind[APP_PAGE] APP_PAGE; RouteKind[APP_ROUTE] APP_ROUTE; })(RouteKind || (RouteKind {})); export { RouteKind }; export { RouteKind as a } from __TURBOPACK_VAR__ assert { __turbopack_var__: true }; export { };这部分是测试框架以ModuleEvaluation为入口把对应Part 0喂给Mergermodule_fragments/merge.rs做递归合并的结果合并流程见 tests.rs即模拟「运行时真正执行这个模块」时看到的代码。dev 与 prod 在本用例中完全一致这不是偶然而是符合预期的正确结果RouteKind 的初始化 IIFE 本身承担了为枚举成员赋值的职责、并带有不可消除的副作用语义无论开发模式Mode::Development对弱依赖如何放宽模块评估都必须执行这段初始化。这也正是本用例的核心结论——含有副作用的运行时初始化逻辑无法被摇树消除树摇只能处理可以被静态证明为无副作用的纯声明。Turbopack 之所以保留整套代码而非把枚举展开成export const RouteKind {...}是因为在编译产物语义里var IIFE 的组合对「先声明后赋值」「读取时必须是已完成初始化的对象」的约束比直接替换更安全。这份快照是如何生成的fixture 驱动的快照测试整套tree-shaker/analyzer测试由一个 fixture 宏驱动tests.rs#[fixture(tests/tree-shaker/analyzer/**/input.js)] fn test_fixture(input: PathBuf) { run(input); }run()对每个用例的执行流程如下读取同目录config.json不存在则视为{}解析exports配置VecVecString支持一次性测试多个导出用 SWC 将input.js按最新 ES 版本 jsx: true解析为 Module并运行 resolver 生成unresolved/top_level标记用DepGraph::init把模块拆为 Item 集合打印# Items依次执行hoist_vars_and_bindings→evaluate_immediate→evaluate_eventual→handle_exports→handle_explicit_deps分别在 Phase 1–4 与 Final 之间渲染依赖图对describe(dev/prod)分别进行弱依赖处理handle_weakMode::Development/Mode::Production、split_module得到 Part 列表与 Entrypoints打印# Modules (dev/prod)用Merger合并模块评估入口打印Merged (module eval)最后通过NormalizedOutput::compare_to_file将生成的文本与该目录下的output.md逐字节归一化比对不一致即测试失败。因此当你修改 Turbopack 树摇分析器后运行该测试若output.md发生预期变更需要先人工核对差异合理性再更新快照而本文分析的 route-kind/output.md 就是这套流水线在RouteKind输入上稳定产出的「标准答案」。如何把这份快照当作日常排查工具掌握上面这些字段含义后tree-shaker/analyzer下任何output.md都可以当作树摇行为的「可视化报告」来读看# Items快速确认模块被拆成几条顶层条目、各自的声明/读写/副作用属性判断变量初始化是否属于「纯声明」看 Phase 依赖图确认依赖边在哪一阶段出现帮助定位「该被合并的代码没有被合并」或「不该出现的边提前出现」这类回归看# Final强连通缩并后的节点数就是不可再分割的最小保留单元看 Entrypoints Part判断「模块评估」「具名导出」「整体导出」分别会触发哪些分片能直接解释某个看似无用的模块为何没被摇掉如本用例的ModuleEvaluation: 0强制保留初始化 IIFE对比 dev / prod弱依赖只在开发模式放行Mode::Developmentprod 下更激进差异本身即反映摇树策略在不同模式的取舍。小结route-kind快照是「Next.js 真实枚举产物 × Turbopack 树摇分析器」交汇处的一份精炼样本入口export var RouteKind与带副作用的初始化 IIFE 决定了其依赖图最终收缩为单一强连通组Entrypoints 又通过ModuleEvaluation强制模块评估保留完整初始化最终 dev/prod 下都只能得到一个「主体 Part 0 导出薄 Part 1」的稳定切分。理解这份输出就掌握了阅读整个tree-shaker/analyzer快照体系与 Turbopack 模块切分语义的钥匙如果再结合 module_fragments 目录graph.rs依赖图、merge.rs分片合并、mod.rs分析器主循环、tests.rs 快照驱动与 route-kind.ts 的真实枚举定义对照阅读即可从「看输出」进阶到「理解机制」。【免费下载链接】next.jsThe React Framework项目地址: https://gitcode.com/GitHub_Trending/next/next.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 从 route-kind 快照读懂 Next.js Turbopack 树摇（Tree Shaking）分析器：模块切分、依赖图与导出分片
从 route-kind 快照读懂 Next.js Turbopack 树摇Tree Shaking分析器模块切分、依赖图与导出分片【免费下载链接】next.jsThe React Framework项目地址: https://gitcode.com/GitHub_Trending/next/next.js导读本文以 Turbopack 中针对 Next.js 真实编译产物RouteKind模块的树摇分析测试快照为对象逐段拆解 route-kind/output.md 的完整输出含义。你将理解Turbopack 如何把一个带运行时初始化 IIFE 的export var模块切割为不同 Part、为什么带副作用的枚举初始化无法被摇掉、__TURBOPACK_PART__与__TURBOPACK_VAR__是什么以及这份快照背后测试脚手架fixture 驱动的逐阶段分析流水线的工作原理。读完即可独立阅读 Turbopack 其余tree-shaker/analyzer/*快照并用于排查打包行为。快照的前世今生一份「测试输出」文档首先要澄清这份关联文档的定位它不是 Next.js 用户文档而是Turbopack 树摇分析器的快照测试产物snapshot/expected output。它以output.md的形式固定在仓库中与同目录的input.js一一对应供 Rust 单测比对。相关文件都位于 tests/tree-shaker/analyzer/其中每个子目录1、route-kind、nanoid、next-response、node-fetch、otel-core、simple、complex、logger、dce、shared-and-side-effects等数十个场景都是一个独立用例结构统一为input.js待分析的入口模块源码多为真实库编译后的产物output.md由测试框架自动生成的预期分析快照可选config.json配置测试导出的导出名列表见 3/config.json 与 test-config-1/config.json。也就是说本文通篇「解析」的对象正是该测试套件对route-kind这个用例自动生成的可读性报告。输入是什么TypeScript 枚举被编译后的形态先看被分析源码 route-kind/input.jsexport var RouteKind; (function(RouteKind) { RouteKind[PAGES] PAGES; RouteKind[PAGES_API] PAGES_API; RouteKind[APP_PAGE] APP_PAGE; RouteKind[APP_ROUTE] APP_ROUTE; })(RouteKind || (RouteKind {}));这实际是 Next.js 中RouteKind枚举经 TypeScript 编译器降级downlevel后的产物。其「真身」位于 packages/next/src/server/route-kind.tsexport const enum RouteKind { PAGES PAGES, PAGES_API PAGES_API, APP_PAGE APP_PAGE, APP_ROUTE APP_ROUTE, IMAGE IMAGE, }从源码注释与导入点可以确认它在 Next.js 路由体系中的语义注意当前 route-kind.ts 里比本快照 fixture 多出一个IMAGE成员说明 fixture 采集自较早编译版本分析结论不受影响PAGESpages/目录下的 React 页面PAGES_APIpages/api/下的 API 路由APP_PAGEapp/目录下以page.{j,t}s{,x}命名的 React 页面APP_ROUTEapp/目录下以route.{j,t}s{,x}命名的 API/元数据路由。它被 Next.js 的构建入口与模板大量引用例如 build/entries.ts、build/templates/pages.ts、pages-api.ts、app-route.ts 等。因此 Turbopack 打「Next.js 自身包」时几乎必然遇到这段代码route-kind用例的价值就在于验证树摇器对这种「export var 自执行初始化函数」模式的切分正确性。为什么它不能简单当成一个普通变量声明因为RouteKind的成员不是静态初始化而是通过一次带副作用语义的函数调用立即执行表达式在运行时填充的。后文快照的每一节都围绕这条主线展开。快照第一节# Items把模块拆成原子「条目」树摇分析的第一步是把模块顶层语句拆分为若干Item条目。快照开头写道Count: 3随后枚举了两条明细Item 1Stmt 0, VarDeclarator(0)export var RouteKind;Declares: RouteKindWrite: RouteKind它对应export var RouteKind;这一条顶层语句语句 0 的声明符 0。在分析器中该条目被记录为「声明并写入变量RouteKind」——注意此时变量值是undefined真正的赋值发生在下一条语句。Item 2Stmt 1, Normal(function(RouteKind) { ... })(RouteKind || (RouteKind {}));Side effectsReads: RouteKindWrite: RouteKind它是一条「普通」顶层语句Normal。分析器标记它含副作用Side effects同时读取并写入RouteKind既把当前值RouteKind || (RouteKind {})的兜底对象读入又为四个键写入字符串值。为什么总数是 3 却只列出 2 条对照测试脚手架 tests.rs 的实现可以看到Count用全部item_ids长度含 Group 类条目而明细循环里遇到ItemId::Group(_)直接continueGroup 条目不在 Items 明细中单独展示。第 3 个隐藏条目export RouteKind绑定在后面的 mermaid 图中以Item3[export RouteKind]出现。Item 的元数据字段Hoisted/Side effects/Declares/Reads/Write/Reads (eventual)/Write (eventual)正是由 tests.rs 依据每个 Item 的分析结果打印的数据来源是ItemData定义在 module_fragments/graph.rs。四个 Phase 的 mermaid 依赖图依赖边如何逐阶段生长快照用 5 张 mermaid 图展示依赖图的演化过程对应的正是 tests.rs 中测试代码的分析流水线快照小节触发的分析步骤图的状态# Phase 1hoist_vars_and_bindings()提升变量与绑定只有 3 个孤立节点无依赖边# Phase 2evaluate_immediate()立即读写求值出现Item2 -- Item1、Item3 -- Item2、Item3 -- Item1三条边# Phase 3evaluate_eventual()兜底/延迟求值与 Phase 2 相同# Phase 4handle_exports()处理导出与 Phase 3 相同# Finalhandle_explicit_deps()finalize()缩并强连通分量只剩一个合并节点N0对route-kind用例三个节点含义为Item1export var RouteKind变量声明Item2填充成员的 IIFENormalItem3名称为export RouteKind的导出绑定节点。Phase 2 中新增的三条依赖边反映了求值语义IIFE 要读写RouteKind因此必须先于变量声明条目Item2 → Item1导出绑定要拿到最终值因此同时依赖写入者与声明者Item3 → Item2、Item3 → Item1。这些边一旦形成就贯穿 Phase 3、4说明对普通立即求值即可确定依赖无需延迟求值补充新边——这正是「变量声明 立即初始化 导出」这一模式的典型形态。图的渲染逻辑强依赖--与弱依赖-.-的区别、节点标签转义等见 tests.rs。# Final一节展示缩并后的最终依赖图由于export RouteKind需要同时拉入「声明」与「副作用写入」两条路径三者被归并进同一个强连通组N0[Items: [ItemId(0, VarDeclarator(0)), ItemId(1, Normal), ItemId(Export(RouteKind, #2), RouteKind))]]也就是说对RouteKind的任意导入都必须保留整段声明 初始化代码这是后续 Part 切分的最关键输入。Entrypoints哪些「入口点」需要被满足# Entrypoints展示了模块切分后需要提供的入口集合Entrypoints按 Key 排序后打印见 tests.rs{ ModuleEvaluation: 0, Export( RouteKind, ): 0, Exports: 1, }三个 Key 的含义如下ModuleEvaluation模块自评估import 该模块即执行其顶层副作用指向模块索引0Export(RouteKind)具名导出RouteKind同样落在模块索引0Exports代表「把该模块的导出整体暴露」的入口落在模块索引1。注意此处的模块索引是指下一节# Modules (dev/prod)中的Part编号。ModuleEvaluation与具名导出都指向Part 0这解释了为何模块评估module eval的合并产物里IIFE 初始化代码被原样保留——模块只要被执行RouteKind就必须先被赋好值。Modules 与 Part 切分dev / prod 双份产物快照在# Entrypoints之后分别以# Modules (dev)与# Modules (prod)各打印一次切分结果并在每份里给出Part 0、Part 1以及Merged (module eval)三段代码。Part 0真正执行的「主体分片」var RouteKind; (function(RouteKind) { RouteKind[PAGES] PAGES; // ... 四个成员 })(RouteKind || (RouteKind {})); export { RouteKind }; export { RouteKind as a } from __TURBOPACK_VAR__ assert { __turbopack_var__: true }; export { };它几乎原样保留了输入代码额外附带三样 Turbopack 内部机制export { RouteKind }把运行时变量直接作为具名导出export { RouteKind as a } from __TURBOPACK_VAR__通过特殊虚拟模块__TURBOPACK_VAR__把该变量再以内部别名a暴露给其他分片引用该常量对应 module_fragments/mod.rs 附近对分片内部导入源的定义机制export { }空的具名导出占位用于承接可能的命名空间访问。Part 1导出描述性的「薄分片」export { RouteKind } from __TURBOPACK_PART__ assert { __turbopack_part__: export RouteKind };Part 1 本身不包含任何执行代码只通过特殊模块__TURBOPACK_PART__assert { __turbopack_part__: export RouteKind }声明「本分片的作用是重导出export RouteKind那个分片」。这种把导出关系与执行代码解耦的设计使得 Turbopack 能在需要时按需拼接分片、而无需重复执行初始化。Merged (module eval)面向模块评估的最终合并结果var RouteKind; (function(RouteKind) { RouteKind[PAGES] PAGES; RouteKind[PAGES_API] PAGES_API; RouteKind[APP_PAGE] APP_PAGE; RouteKind[APP_ROUTE] APP_ROUTE; })(RouteKind || (RouteKind {})); export { RouteKind }; export { RouteKind as a } from __TURBOPACK_VAR__ assert { __turbopack_var__: true }; export { };这部分是测试框架以ModuleEvaluation为入口把对应Part 0喂给Mergermodule_fragments/merge.rs做递归合并的结果合并流程见 tests.rs即模拟「运行时真正执行这个模块」时看到的代码。dev 与 prod 在本用例中完全一致这不是偶然而是符合预期的正确结果RouteKind 的初始化 IIFE 本身承担了为枚举成员赋值的职责、并带有不可消除的副作用语义无论开发模式Mode::Development对弱依赖如何放宽模块评估都必须执行这段初始化。这也正是本用例的核心结论——含有副作用的运行时初始化逻辑无法被摇树消除树摇只能处理可以被静态证明为无副作用的纯声明。Turbopack 之所以保留整套代码而非把枚举展开成export const RouteKind {...}是因为在编译产物语义里var IIFE 的组合对「先声明后赋值」「读取时必须是已完成初始化的对象」的约束比直接替换更安全。这份快照是如何生成的fixture 驱动的快照测试整套tree-shaker/analyzer测试由一个 fixture 宏驱动tests.rs#[fixture(tests/tree-shaker/analyzer/**/input.js)] fn test_fixture(input: PathBuf) { run(input); }run()对每个用例的执行流程如下读取同目录config.json不存在则视为{}解析exports配置VecVecString支持一次性测试多个导出用 SWC 将input.js按最新 ES 版本 jsx: true解析为 Module并运行 resolver 生成unresolved/top_level标记用DepGraph::init把模块拆为 Item 集合打印# Items依次执行hoist_vars_and_bindings→evaluate_immediate→evaluate_eventual→handle_exports→handle_explicit_deps分别在 Phase 1–4 与 Final 之间渲染依赖图对describe(dev/prod)分别进行弱依赖处理handle_weakMode::Development/Mode::Production、split_module得到 Part 列表与 Entrypoints打印# Modules (dev/prod)用Merger合并模块评估入口打印Merged (module eval)最后通过NormalizedOutput::compare_to_file将生成的文本与该目录下的output.md逐字节归一化比对不一致即测试失败。因此当你修改 Turbopack 树摇分析器后运行该测试若output.md发生预期变更需要先人工核对差异合理性再更新快照而本文分析的 route-kind/output.md 就是这套流水线在RouteKind输入上稳定产出的「标准答案」。如何把这份快照当作日常排查工具掌握上面这些字段含义后tree-shaker/analyzer下任何output.md都可以当作树摇行为的「可视化报告」来读看# Items快速确认模块被拆成几条顶层条目、各自的声明/读写/副作用属性判断变量初始化是否属于「纯声明」看 Phase 依赖图确认依赖边在哪一阶段出现帮助定位「该被合并的代码没有被合并」或「不该出现的边提前出现」这类回归看# Final强连通缩并后的节点数就是不可再分割的最小保留单元看 Entrypoints Part判断「模块评估」「具名导出」「整体导出」分别会触发哪些分片能直接解释某个看似无用的模块为何没被摇掉如本用例的ModuleEvaluation: 0强制保留初始化 IIFE对比 dev / prod弱依赖只在开发模式放行Mode::Developmentprod 下更激进差异本身即反映摇树策略在不同模式的取舍。小结route-kind快照是「Next.js 真实枚举产物 × Turbopack 树摇分析器」交汇处的一份精炼样本入口export var RouteKind与带副作用的初始化 IIFE 决定了其依赖图最终收缩为单一强连通组Entrypoints 又通过ModuleEvaluation强制模块评估保留完整初始化最终 dev/prod 下都只能得到一个「主体 Part 0 导出薄 Part 1」的稳定切分。理解这份输出就掌握了阅读整个tree-shaker/analyzer快照体系与 Turbopack 模块切分语义的钥匙如果再结合 module_fragments 目录graph.rs依赖图、merge.rs分片合并、mod.rs分析器主循环、tests.rs 快照驱动与 route-kind.ts 的真实枚举定义对照阅读即可从「看输出」进阶到「理解机制」。【免费下载链接】next.jsThe React Framework项目地址: https://gitcode.com/GitHub_Trending/next/next.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考