Next.js Turbopack 生产 Chunk 合并的成本收益模型chunk_merging_cost_benefit.md数学推导与production.rs实现解析【免费下载链接】next.jsThe React Framework项目地址: https://gitcode.com/GitHub_Trending/next/next.jsTurbopack 在生产构建next build使用 Turbopack 时需要自动决定哪些 chunk 应该合并、哪些不应该合并。turbopack/crates/turbopack-core/src/chunk/chunking/chunk_merging_cost_benefit.md是这一决策的数学设计文档它定义了一个以期望请求次数 × 单次请求成本 期望传输字节数为核心的代价函数用概率模型对比合并前UNMERGED与合并后MERGED两种形态的期望代价并给出了可配置的集群cluster导航概率扩展。读完本文你可以完整复现这套推导知道它如何逐行落地在 production.rs 中以及如何通过next.config.js的experimental.turbopackChunking调整其中的每一个参数。1. 问题定义合并两个 chunk 前要先回答的问题设待评估的合并对象是两个原子chunkA 与 B。文档首先给出全局统计量总共有groups个 chunk group未合并UNMERGED状态下有 $a_{\text{groups}}$ 个 chunk group 请求 AA 的大小为 $a_{\text{size}}$有 $b_{\text{groups}}$ 个 chunk group 请求 BB 的大小为 $b_{\text{size}}$其中 $o_{\text{groups}}$ 个 chunk group 同时请求 A 和 B即两者的重叠集。合并MERGED状态下$a_{\text{rem}}$ 个 chunk group 请求 A大小 $a_{\text{size}}$$b_{\text{rem}}$ 个 chunk group 请求 B大小 $b_{\text{size}}$$o_{\text{groups}}$ 个重叠 chunk group 转而请求合并后的 chunk大小为 $(a_{\text{size}} b_{\text{size}})$。三个集合 X / Y / Z 是后文反复使用的记号$$ X \text{只加载 chunk A 的 } a_{\text{rem}} \text{ 个组},\quad Y \text{只加载 chunk B 的 } b_{\text{rem}} \text{ 个组},\quad Z \text{同时加载两者的 } o_{\text{groups}} \text{ 个组} $$合并的核心权衡在重叠集 Z合并前 Z 里的每个组要发2 个请求合并后只需1 个请求——这就是合并的收益来源但合并后若用户从 Z 导航到 X或从 X 导航到 Z原本已经缓存的 A 反而要随合并 chunk 重新下载——这是合并的代价来源。整套模型就是对这两类效应的期望值做差。2. 用户访问概率假设$P(N1) 2/3$$P(N2) 1/3$文档的默认假设是一次会话恰好请求 1 个 chunk group$N1$的概率为 2/3请求 2 个 chunk group$N2$的概率为 1/3。这是一个刻意保留的简化原文This is a simplification, but it should be good enough for our purposes and it is configurable using the chunking heuristics.这个假设不是硬编码的P(N1)可以通过first_page_load_priority配置。在 production.rs 中// Default P(N 1): the probability that we request exactly 1 chunk group. // firstPageLoadPriority (a config percentage) maps to it; the default is 0.67 // (~2/3). let default_p1 first_page_load_priority.map_or(0.67, |percent| percent as f64 / 100.0);即默认0.67约 2/3配置值按百分数映射。文档中所有期望量都按这两个分支加权$$ \begin{aligned} e_{\text{size}} P(N1)\cdot e_{\text{size}}(N1) P(N2)\cdot e_{\text{size}}(N2)\ e_{\text{req}} P(N1)\cdot e_{\text{req}}(N1) P(N2)\cdot e_{\text{req}}(N2) \end{aligned} $$3. 代价函数$e_{\text{cost}} e_{\text{req}} \cdot c_{\text{req}} e_{\text{size}}$将期望请求数与期望字节数合并成一个标量代价$$ e_{\text{cost}} e_{\text{req}} \cdot c_{\text{req}} e_{\text{size}} $$其中 $c_{\text{req}}$ 是以传输字节为单位的单次请求成本。文档明确承认这个常数没有客观真值只能取一个合理的经验值实现侧的取值production.rs/// Default estimated cost of an additional request, in bytes (200 KB). const DEFAULT_ESTIMATED_REQUEST_COST_BYTES: u64 200_000; /// Probability that a navigation stays within a cluster. const CLUSTER_NAVIGATION_PROBABILITY: f64 0.6;$c_{\text{req}}$ 默认200 KB可通过request_cost配置覆盖CLUSTER_NAVIGATION_PROBABILITY硬编码为0.6第 4 节的集群导航概率当前版本不可配置。由此对未合并代价 $e_{\text{unmerged cost}}$ 与合并代价 $e_{\text{merged cost}}$ 分别建模合并收益定义为$$ d e_{\text{unmerged cost}} - e_{\text{merged cost}} $$$d 0$ 说明合并有净收益。进一步按分量拆开$$ d d_{\text{req}} \cdot c_{\text{req}} d_{\text{size}} $$$$ d_{\text{size}} e_{\text{unmerged size}} - e_{\text{merged size}},\qquad d_{\text{req}} e_{\text{unmerged req}} - e_{\text{merged req}} $$再对 $N$ 分支拆开$$ \begin{aligned} d_{\text{size}} P(N1)\cdot d_{\text{size}}(N1) P(N2)\cdot d_{\text{size}}(N2)\ d_{\text{req}} P(N1)\cdot d_{\text{req}}(N1) P(N2)\cdot d_{\text{req}}(N2) \end{aligned} $$4. 单页加载$N1$分支的推导4.1 逐情况枚举$N1$ 时随机命中一个 chunk group三个 case 的概率、大小与请求数如下。UNMERGEDN 1case概率 $p$传输大小请求数X命中只加载 A 的组$a_{\text{rem}}/\text{groups}$$a_{\text{size}}$1Y命中只加载 B 的组$b_{\text{rem}}/\text{groups}$$b_{\text{size}}$1Z命中同时加载两者的组$o_{\text{groups}}/\text{groups}$$a_{\text{size}} b_{\text{size}}$2MERGEDN 1case概率 $p$传输大小请求数X$a_{\text{rem}}/\text{groups}$$a_{\text{size}}$1Y$b_{\text{rem}}/\text{groups}$$b_{\text{size}}$1Z$o_{\text{groups}}/\text{groups}$$a_{\text{size}} b_{\text{size}}$1对比两表传输大小逐 case 完全相同因此$$ d_{\text{size}}(N1) 0 $$唯一的差异在 case Z 的请求数2 → 1其发生概率为 $p o_{\text{groups}}/\text{groups}$$$ \begin{aligned} d_{\text{req}}(N1) (o_{\text{groups}}/\text{groups})\cdot(2-1) o_{\text{groups}}/\text{groups}\ d(N1) d_{\text{req}}(N1)\cdot c_{\text{req}} d_{\text{size}}(N1) (o_{\text{groups}}\cdot c_{\text{req}})/\text{groups} \end{aligned} $$结论很直接只要 A、B 存在重叠组单页加载场景下合并永远有正收益且收益与重叠组数成正比。实现中对应的一行production.rslet d1 o / groups * c_req;5. 双页会话$N2$分支转移概率模型$N2$ 描述的是先落在第一个组、再从该页导航到第二个组的两次访问会话。第二个 case 的概率 $p$ 落在第一组集合的概率 × 从第一组导航到第二组集合的概率后者记为转移概率 $\text{trans}(1 \to 2)$。5.1 未配置集群时均匀转移没有任何集群信息时从某组出发的下一次导航在其余groups - 1个组上均匀分布$$ \begin{aligned} \text{trans}(X \to X) (a_{\text{rem}}-1)/(\text{groups}-1) \text{trans}(X \to Y) b_{\text{rem}}/(\text{groups}-1) \text{trans}(X \to Z) o_{\text{groups}}/(\text{groups}-1)\ \text{trans}(Y \to X) a_{\text{rem}}/(\text{groups}-1) \text{trans}(Y \to Y) (b_{\text{rem}}-1)/(\text{groups}-1) \text{trans}(Y \to Z) o_{\text{groups}}/(\text{groups}-1)\ \text{trans}(Z \to X) a_{\text{rem}}/(\text{groups}-1) \text{trans}(Z \to Y) b_{\text{rem}}/(\text{groups}-1) \text{trans}(Z \to Z) (o_{\text{groups}}-1)/(\text{groups}-1) \end{aligned} $$此时六个 case 的概率退化为文档给出的形式例如$$ \begin{aligned} \text{case } X!!X : p (a_{\text{rem}}/\text{groups})\cdot((a_{\text{rem}}-1)/(\text{groups}-1))\ \text{case } X!!Y : p (a_{\text{rem}}/\text{groups})\cdot(b_{\text{rem}}/(\text{groups}-1)) (b_{\text{rem}}/\text{groups})\cdot(a_{\text{rem}}/(\text{groups}-1))\ \text{case } X!!Z : p (a_{\text{rem}}/\text{groups})\cdot(o_{\text{groups}}/(\text{groups}-1)) (o_{\text{groups}}/\text{groups})\cdot(a_{\text{rem}}/(\text{groups}-1))\ \text{case } Y!!Z : p (b_{\text{rem}}/\text{groups})\cdot(o_{\text{groups}}/(\text{groups}-1)) (o_{\text{groups}}/\text{groups})\cdot(b_{\text{rem}}/(\text{groups}-1)) \end{aligned} $$$Y!!Y$、$Z!!Z$ 同 $X!!X$ 结构。5.2 配置集群时成对计数与概率树集群cluster用于表达用户更可能在同一集群内的页面之间互相导航。两个同集群的组构成一个pair。设 $c_{ij}$ 为跨集合 $i$、$j$ 的 pair 数对角项 $c_{xx}$、$c_{yy}$、$c_{zz}$ 表示两组成员同属一个集合的 pair构成对称表$$ \begin{array}{c|ccc} X,(a_{\text{rem}}) Y,(b_{\text{rem}}) Z,(\text{overlap})\ \hline X,(a_{\text{rem}}) c_{xx} c_{xy} c_{xz}\ Y,(b_{\text{rem}}) c_{xy} c_{yy} c_{yz}\ Z,(\text{overlap}) c_{xz} c_{yz} c_{zz} \end{array} $$每行之和是该集合发出的全部 cluster 内 pair 数$$ \begin{aligned} \text{paired}x c{xx} c_{xy} c_{xz}\ \text{paired}y c{xy} c_{yy} c_{yz}\ \text{paired}z c{xz} c_{yz} c_{zz} \end{aligned} $$CLUSTER_NAVIGATION_PROBABILITY记作 $\text{cnp}$ 0.6是一次导航停留在集群内的概率。对起点在集合 1、终点在集合 2的 $\text{trans}(1 \to 2)$文档给出概率树Will the navigation stay within a cluster? / \ yes (cnp) no (1 - cnp) / \ Does it go to set 2? Does it go to set 2? | | c_12 / paired_1 non_paired_12 / non_paired_1其中 $\text{non_paired}_{12}$ 是从集合 1 进入集合 2 的集群外导航数$\text{non_paired}_1$ 是离开集合 1 的全部集群外导航数$$ \begin{aligned} \text{non_paired}{12} |S_1|\cdot|S_2| - c{12}\ \text{non_paired}_1 (\text{groups}-1)\cdot|S_1| - \text{paired}_1 \end{aligned} $$注意一个细节当集合 1 与集合 2 是同一个集合时$\text{non_paired}_{12}$ 中的 $|S_1|$ 要换成 $|S_1|-1$因为组不能导航到自己而 $\text{non_paired}_1$ 里的 $|S_1|$ 保持不变因为每个组都仍是合法起点。最终$$ \text{trans}(1 \to 2) \text{cnp}\cdot(c_{12}/\text{paired}1) (1-\text{cnp})\cdot(\text{non_paired}{12}/\text{non_paired}_1) $$两个防除零的回退$\text{paired}_1 0$ 时取 $\text{trans}(1\to 2) |S_2|/(\text{groups}-1)$$\text{non_paired}1 0$ 时取 $\text{trans}(1\to 2) c{12}/\text{paired}_1$。这套逻辑在 production.rs 中是一个闭包transition_probability与文档逐项对应let transition_probability |pairs_to_dest: f64, source_pairs: f64, source_groups: f64, dest_groups: f64| { if source_pairs 0.0 { // Source has no pairs: navigate uniformly. return dest_groups / rem_g; // paired_1 0 回退 } let non_paired_from_source rem_g * source_groups - source_pairs; if non_paired_from_source 0.0 { // Every other group is paired: all weight on the pairs. return pairs_to_dest / source_pairs; // non_paired_1 0 回退 } let non_paired_from_source_to_dest dest_groups * source_groups - pairs_to_dest; CLUSTER_NAVIGATION_PROBABILITY * (pairs_to_dest / source_pairs) (1.0 - CLUSTER_NAVIGATION_PROBABILITY) * (non_paired_from_source_to_dest / non_paired_from_source) }; let p_zz transition_probability(c_zz, paired_z, o, o - 1.0); // Z→Zdest 减 1同集合 let p_zx transition_probability(c_xz, paired_z, o, a_rem); // Z→X let p_zy transition_probability(c_yz, paired_z, o, b_rem); // Z→Y let p_xz transition_probability(c_xz, paired_x, a_rem, o); // X→Z let p_yz transition_probability(c_yz, paired_y, b_rem, o); // Y→Z其中dest_groups传o - 1.0而不是o正是 5.2 节同集合时 $|S_1|-1$的实现。pair 计数本身c_xx … c_zz在 production.rs 中用 RoaringBitmap 集合运算完成先把每个 cluster ID 映射到它包含的候选组再对 X/Y/Z 中每个组用pairs_with(index)取与它同 cluster 的其他组与三个集合求交并累加。从源码结构看当某组没有任何集群内 pair 时source_pairs 0代码走的是均匀回退分支dest_groups / rem_g与文档未配置集群时均匀跳变的公式一致。5.3 $N2$ 全部 case 枚举UNMERGEDN 2case概率 $p$传输大小请求数X X$(a_{\text{rem}}/\text{groups})\cdot\text{trans}(X!\to!X)$$a_{\text{size}}$1Y Y$(b_{\text{rem}}/\text{groups})\cdot\text{trans}(Y!\to!Y)$$b_{\text{size}}$1Z Z$(o_{\text{groups}}/\text{groups})\cdot\text{trans}(Z!\to!Z)$$a_{\text{size}}b_{\text{size}}$2X Y$(a_{\text{rem}}/\text{groups})\cdot\text{trans}(X!\to!Y) (b_{\text{rem}}/\text{groups})\cdot\text{trans}(Y!\to!X)$$a_{\text{size}}b_{\text{size}}$2X Z$(a_{\text{rem}}/\text{groups})\cdot\text{trans}(X!\to!Z) (o_{\text{groups}}/\text{groups})\cdot\text{trans}(Z!\to!X)$$a_{\text{size}}b_{\text{size}}$2Y Z$(b_{\text{rem}}/\text{groups})\cdot\text{trans}(Y!\to!Z) (o_{\text{groups}}/\text{groups})\cdot\text{trans}(Z!\to!Y)$$a_{\text{size}}b_{\text{size}}$2MERGEDN 2概率与 XX、YY、ZZ 的传输大小不变差异只在三处case传输大小请求数Z Z$a_{\text{size}}b_{\text{size}}$1变好X Z$a_{\text{size}} (a_{\text{size}}b_{\text{size}})$2大小变差Y Z$b_{\text{size}} (a_{\text{size}}b_{\text{size}})$2大小变差即请求数在 $Z!!Z$ 上更优传输大小在 $X!!Z$、$Y!!Z$ 上更差原本只缓存了单边导航后却要整包重下。5.4 收益差公式的闭式化请求数分量只有 $Z!!Z$ 一项有差$$ d_{\text{req } ZZ} ((o_{\text{groups}}/\text{groups})\cdot\text{trans}(Z!\to!Z))\cdot(2-1) (o_{\text{groups}}/\text{groups})\cdot\text{trans}(Z!\to!Z) $$即$$ d_{\text{req}}(N2) (o_{\text{groups}}/\text{groups})\cdot\text{trans}(Z!\to!Z) $$大小分量只有 $X!!Z$ 与 $Y!!Z$ 有差且均为负合并让传输变大$$ \begin{aligned} d_{\text{size } XZ} -a_{\text{size}}\cdot(a_{\text{rem}}\cdot\text{trans}(X!\to!Z) o_{\text{groups}}\cdot\text{trans}(Z!\to!X))/\text{groups}\ d_{\text{size } YZ} -b_{\text{size}}\cdot(b_{\text{rem}}\cdot\text{trans}(Y!\to!Z) o_{\text{groups}}\cdot\text{trans}(Z!\to!Y))/\text{groups} \end{aligned} $$合起来$$ d_{\text{size}}(N2) -\Big(a_{\text{size}}\cdot(a_{\text{rem}}\cdot\text{trans}(X!\to!Z) o_{\text{groups}}\cdot\text{trans}(Z!\to!X)) b_{\text{size}}\cdot(b_{\text{rem}}\cdot\text{trans}(Y!\to!Z) o_{\text{groups}}\cdot\text{trans}(Z!\to!Y))\Big)/\text{groups} $$于是$$ \begin{aligned} d(N2) d_{\text{req}}(N2)\cdot c_{\text{req}} d_{\text{size}}(N2)\ (o_{\text{groups}}\cdot\text{trans}(Z!\to!Z)\cdot c_{\text{req}}a_{\text{size}}\cdot(a_{\text{rem}}\cdot\text{trans}(X!\to!Z) o_{\text{groups}}\cdot\text{trans}(Z!\to!X))\ \quad - b_{\text{size}}\cdot(b_{\text{rem}}\cdot\text{trans}(Y!\to!Z) o_{\text{groups}}\cdot\text{trans}(Z!\to!Y)))/\text{groups} \end{aligned} $$直觉解读$d(N2)$ 第一项是双页会话落在 Z→Z 上省下的那一次请求正收益后两项是跨集合导航时被迫重复传输 A / B负代价。$Z$ 越大、$c_{\text{req}}$ 越高正项越强$X!\to!Z$、$Y!\to!Z$ 的转移概率越高例如集群把 X/Y 与 Z 绑在一起负项越强。5.5 最终决策式$$ d P(N1)\cdot d(N1) P(N2)\cdot d(N2) $$只有 $d 0$ 才值得合并。6. 实现落地production.rs中的逐行对应推导部分结束后看模型如何嵌入真实的合并算法。入口是make_production_chunksproduction.rs整体流程按 chunk group 集合分组把全部 chunk items 按其所属 chunk group 集合RoaringBitmap分组相同 group 集合的 items 先聚成一个ChunkCandidate初始即一个原子 chunk。选出待合并候选优先队列BinaryHeap按 size 降序维护所有候选。低于min_chunk_size的候选、或会使组内 chunk 数超过max_chunk_count_per_group的候选被弹出放入chunks_to_mergemax_merge_chunk_size以上的候选永不参与合并。贪心两两合并while chunks_to_merge.len() 1循环中每轮对新弹出的候选与已选候选两两组合计算重叠overlap套用第 25 节的公式得value选重叠最大、收益最高的一对合并对应 production.rs 的变量映射let a_groups candidate.chunk_groups_len() as i64; let a_size candidate.size as i64; let b_groups other.chunk_groups_len() as i64; let b_size other.size as i64; let o_groups overlap as i64; let groups a_groups b_groups - o_groups; let a_rem a_groups - o_groups; let b_rem b_groups - o_groups; // See ./chunk_merging_cost_benefit.md for a description of how this works. if o_groups 0 || groups 2 { continue; }overlap 1直接跳过无重叠则合并无收益对应文档前置条件MAX_COMBINATIONAL_COMPLEXITY 32限制组合搜索规模使每轮复杂度从 $O(N^3)$ 压到近似 $O(N)$已足够大的候选size merge_threshold只允许与其全部重叠组合并避免缩小共享范围。优先级路由加权若重叠集 Z 与priority_routes有交集is_priority_route$P(N1)$ 乘以priority_boost默认 1.5 倍后截断到 1$P(N2)$ 相应减小从而更激进地合并被首页/关键路由引用的 chunklet p1 if is_priority_route { (default_p1 * priority_boost).min(1.0) } else { default_p1 }; let p2 1.0 - p1;决策与合并let d1 o / groups * c_req; let d2 (o * p_zz * c_req - a_size * (a_rem * p_xz o * p_zx) - b_size * (b_rem * p_yz o * p_zy)) / groups; let value p1 * d1 p2 * d2; // It need to have some runtime benefit of merging the chunks if value 0.0 { continue; }d1即 $d(N1) (o\cdot c_{\text{req}})/\text{groups}$d2即 $d(N2)$把 5.4 的 $d_{\text{req}}(N2)\cdot c_{\text{req}}$ 与 $d_{\text{size}}(N2)$ 合并同分母value即最终 $d P(N1)\cdot d(N1) P(N2)\cdot d(N2)$。value 0的组合被丢弃正收益的最大组合先比重叠数、再比 value被执行合并items、batch groups、components 并入候选chunk group 集合取并集merge_chunk_groups用位图l r…此处为位集合并合并后的候选重新压回chunks_to_merge继续参与下一轮。收尾循环结束后达到merge_threshold的候选回到主堆其余残留合并成一个remained chunk承载所有不可共享的模块。若启用了generate_component_chunks合并后的 chunk 还会通过split_into_component_chunks把每个原始组成部分≥min_component_chunk_size的单独成块更小的并入 remainder 块作为component chunk一并发出供运行时按需加载已缓存的部分而不是整包合并 chunk。以上流程说明文档中的期望代价模型不是孤立纸面推导它就是合并循环里选哪对合并的打分函数且每一枚符号都能与源码变量一一对应。7. 配置入口experimental.turbopackChunking模型的可调参数通过next.config.js的experimental.turbopackChunking暴露配置结构定义在 crates/next-core/src/next_config.rsTurbopackChunkingConfig/** type {import(next).NextConfig} */ const nextConfig { experimental: { turbopackChunking: { // 常一起访问的页面分组每簇由一组匹配路由路径的正则组成 // 簇 ID 即列表下标用于修正 N2 的转移概率第 5.2 节 clusters: [ [/products/.*], [/cart, /checkout], ], // 0.0..1.0即 P(N1)调高表示用户更可能只加载一个页面就走 // 站点跳出率是不错的近似值 first_page_load_priority: 0.7, // 高优先级路由如首页的正则其 chunk 会被更积极地合并 priority_routes: [/], // 对 priority_routes 的 P(N1) 的倍率默认 1.5 priority_boost: 1.5, // 单次请求的估计成本字节未压缩未压缩前的大小默认 200000200 KB request_cost: 200000, // 最多允许一个小于该字节数的 chunk默认 50000更小的会被合并 min_chunk_size: 50000, // 每个 chunk group 的 chunk 数量上限默认 40 max_chunk_count_per_group: 40, // 大于该字节数的 chunk默认 200000永不参与合并 // 避免大 chunk 代码被复制到多个 chunk max_merge_chunk_size: 200000, // 是否把合并 chunk 的组成部分作为 component chunk 一并产出默认 false generate_component_chunks: false, // component chunk 独立产出的最小字节数默认 20000 min_component_chunk_size: 20000, }, }, };参数与实现的映射关系均可见于 next_config.rs 的字段注释与entry_heuristics_for配置项进入模型的位置默认值first_page_load_priority$P(N1)$$P(N2)1-P(N1)$0.67priority_boost优先级路由的 $P(N1)$ 倍率1.5request_cost$c_{\text{req}}$200 KBclusters$\text{trans}(i\to j)$ 的成对计数无均匀转移priority_routesZ ∩ priority 时提升 $P(N1)$空min_chunk_size/max_chunk_count_per_group/max_merge_chunk_size候选筛选与合并阈值非期望模型内部但决定哪些候选进入打分50 KB / 40 / 200 KBgenerate_component_chunks/min_component_chunk_size合并产物侧的 component chunk 拆分false / 20 KB路由到组信息的转化TurbopackChunking::entry_heuristics_fornext_config.rs对每条路由做正则匹配产出 EntryHeuristics所属 cluster 索引列表 是否高优先级随构建聚合为 ChunkingHeuristicsInfo——clusters: VecVecu16每个 chunk group 索引 → 所属 cluster ID 集合与priority_routes: RoaringBitmapWrapper高优先级路由及其拉入的组——这正是第 5.2 节 pair 计数与is_priority_route判定的数据来源。适用前提与限制该模型只在生产构建路径make_production_chunks生效dev 与 CSS chunk 走 chunking 目录 下的其他策略dev.rs、style_production.rsCLUSTER_NAVIGATION_PROBABILITY 0.6目前是源码常量clusters配置只能改变 pair 计数而无法改变该常数概率模型本身也是对真实导航分布的近似文档自己也称之为 simplification它给出的是值得不值得合并的相对判断而非精确的流量预测。8. 小结决策规则一句话合并当且仅当 $d P(N1)\cdot d(N1) P(N2)\cdot d(N2) 0$$N1$ 分支恒有正收益 $d(N1) (o_{\text{groups}}\cdot c_{\text{req}})/\text{groups}$$N2$ 分支的收益Z→Z 省一次请求与代价X↔Z、Y↔Z 重复传输由转移概率加权集群配置通过成对计数 0.6 的簇内停留概率修正转移概率文档 chunk_merging_cost_benefit.md 中每个符号都在 production.rs 有精确对应的变量o/groups*c_req、p_zz/p_xz/p_zx/p_yz、value p1*d1 p2*d2实现还包括组合复杂度上限32、优先级路由 boost、合并后 component chunk 拆分等工程化补充所有可调项经experimental.turbopackChunking暴露默认值为P(N1)0.67、c_req200 KB、priority_boost1.5、min_chunk_size50 KB、max_chunk_count_per_group40、max_merge_chunk_size200 KB可按站点实际的跳出率与请求开销画像调优。【免费下载链接】next.jsThe React Framework项目地址: https://gitcode.com/GitHub_Trending/next/next.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考