拓冰网站定制 
civitai 构建排障实战Turbopack 服务端 chunk 哈希生日碰撞的根因定位与处置决策【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本文基于 civitai 仓库中的事故复盘文档 turbopack-chunk-hash-collision-2026-08-18.md完整还原一次 Next.js 16Turbopack生产镜像构建失败事件从next build报错的误读陷阱、7 字符服务端 chunk 命名哈希的生日碰撞根因测量到区分性实验排除共享构建缓存假设、以及唯一能攻击机制的开关为何最终被内存上限关闭的完整证据链。读完后你将掌握一套可迁移的构建排障方法论——如何正确解读打包器报错、如何用受控实验证伪竞争假设以及如何为修不了的上游缺陷做出有数据支撑的处置决策。一、事故背景与适用前提civitai 的 Web 主应用是一个 pnpm monorepo 中的 Next.js 应用构建入口是根 package.json 中的build: next build第 67 行Turbopack 自 Next 16 起成为默认打包器。生产镜像由仓库根 Dockerfile 构建其中 builder 阶段执行生产构建的那一步第 55–56 行是RUN --mounttypecache,target/app/.next/cache \ SKIP_ENV_VALIDATION1 IS_BUILDtrue NODE_OPTIONS--max_old_space_size${NODE_BUILD_MEM} pnpm run build注意--mounttypecache,target/app/.next/cache这一共享构建缓存挂载——它在后文中扮演竞争假设的关键角色。截至文档更新时2026-08-30仓库状态为诊断完成但未修复next版本为^16.3.1见 package.json 第 284 行。文档开篇特别澄清16.3.1 只是重新掷了一次骰子re-roll并没有修复碰撞机制本身。二、症状一个极易误读的构建报错镜像构建失败发生在上面RUN步骤执行的next buildTurbopack中报错原文如下Error: Turbopack build failed with 2 errors: [output]/.next/server/chunks/ssr/[root-of-the-server]__0gduaxh._.js Error: Two or more assets with different content were emitted to the same output path file content differs, written to: [output]/.next/abf442f9b482f9c2.js [output]/.next/5e217de9956f5326.js这段报错有两个经典的误读陷阱必须讲清楚底部的两个哈希文件名不是碰撞体。abf442f9b482f9c2.js和5e217de9956f5326.js是 Turbopack 为你 dump 出来的调试文件方便你对比两份不同内容。真正发生碰撞的输出路径是Error:行的上一行——即[root-of-the-server]__0gduaxh._.js。如果你看到两个.map文件碰撞了这样的报告说明报告者读的是 dump 文件名而非碰撞路径。2 errors 实际是一次碰撞不是两次。chunk 本身和它配套的 sourcemap 会被分别上报所以只要开启 sourcemap本仓库确实开着productionBrowserSourceMaps: true一个发生碰撞的 chunk 就会产生两条错误.js和.js.map各一条。这两点直接决定了后续排查方向碰撞发生在.next/server/chunks/下的单个服务端 chunk而不是构建缓存里成对的文件。三、根因7 字符哈希空间里的生日碰撞根因是一个上游 Turbopack 缺陷服务端 chunk 命名哈希7 个字符发生了生日碰撞birthday collision。Turbopack 的服务端 chunk 命名为namespace_hash._.js。文档中对一次构建的全部输出 chunk 做了实测统计测量项数值输出的服务端 chunk 总数24,552哈希宽度其中 21,543 个为 7 字符哈希字母表38 个字符0-9 a-z - _首字符分布0占 43.7%1占 43.2%2占 1.9%最大 namespace[root-of-the-server]_— 11,730 个 chunk关键在最后一行数据首字符在实践中被限制在{0, 1, 2}内因此实际可用哈希空间约为2 × 38^6≈ 6.0×10⁹只是标称38^7空间的约 5%。而单个 namespace 里有约 1.17 万个 chunk——这是一个再标准不过的生日问题。发生碰撞的两个 chunk 彼此毫无关系一个是 14,266 字节、另一个是 17,606 字节模块集合不相交却都被映射到了[root-of-the-server]__0gduaxh._.js。这解释了事故观察到的全部诡异现象对给定模块图是确定性的。同一个 commit 重建必然再次失败。重试失败的构建、或者推一个空 commit都无法清除它。只要模块图发生任何变化碰撞对就会换一组。所以 git bisect 能找到坏 commit但永远找不到肇事文件回滚一个毫不相关的文件也能修好问题——因为它扰动了图。肇事者不是最近改动的任何代码。只命中部分分支且与分支新旧无关——取决于该分支恰好是否包含一对碰撞 chunk。上游报告是 vercel/next.js 仓库的 issue #96976。它被机器人因缺少公开复现链接而自动关闭从未真正 triage因此没有上游修复也没有可升级到的版本。文档中的测量数据是对该 issue 的独立复现。这一点很重要对 Next.js 这类超大规模项目issue 被机器人关掉意味着缺陷长期存在的现实路径工程侧必须自己规划兜底。四、区分性实验排除共享构建缓存假设竞争假设是共享构建缓存碰撞上面的构建步骤挂载了共享 cache--mounttypecache,target/app/.next/cache不同分支的构建可能重叠两次构建可能把相互碰撞的产物写进同一个缓存。该假设预测失败需要并发 热共享缓存两个条件而哈希碰撞假设预测失败在隔离环境下即可确定性复现。实验设计在本地直接构建同一个失败代码树——不用 Docker、不用 BuildKit、不挂缓存、无并发构建先rm -rf .next从结构上彻底排除共享缓存与重叠写入者。结果失败了且两次失败完全一致——相同的碰撞路径、相同的 chunk 数、相同的 2 条错误。这是一个可靠复现因此共享缓存假设被证伪refuted而不仅仅是没有证据支持在缓存与并发都被移除的情况下故障依然发生。另有两条独立证据不利于缓存假设缓存挂载指向.next/cache是输出目录的严格子目录而碰撞资产输出在.next/server/chunks/...位于其外部。Turbopack 的构建文件系统缓存在本仓库本来就是关闭的next.config.mjs 第 315 行turbopackFileSystemCacheForBuild: false。源码注释第 312–314 行还补充了一个易错细节显式写false与省略该键不等价——Next 16.3.0 的默认值是true且 turbopack-build 的dependencyTracking由它派生所以该开关不仅决定磁盘缓存还决定 turbo-tasks 在内存中保留什么。实验结果汇总全部在同一代码树、冷.next、一次一个构建的条件下执行#配置碰撞错误数是否编译通过服务端 chunk 数1Next 16.3.0配置原样基线2否24,5512Next 16.3.0配置原样重复2否24,5513Next 16.3.0nestedAsyncChunking: true0否— 19 条 PostCSS 错误7,1164Next 16.3.1配置原样0是24,5525Next 16.3.1nestedAsyncChunking: true0是7,122五、16.3.1 是重新掷骰子不是修复Run 4 变绿了但不能解读为 16.3.1 修复了这个问题。在 16.3.1 上机制在测量层面完全没变哈希仍是 7 字符24,552 个中 21,543 个、首字符仍被限制043.7% /143.2% /21.9%、最大 namespace 仍约 1.17 万、总 chunk 数几乎相同24,552 对 24,551。决定碰撞概率的任何量都没有移动。真正变化的是模块图的内容它重新决定了哪一对 chunk 会碰撞——正是上游 issue 所描述的扰动一下图它就消失的行为。因此升级 16.3.1 只是解除了当前失败分支的阻塞失败率保持原位。这一点在工程沟通上很关键Next 16.3.1 的升级当时因无关原因civitai#4075正在落地。一旦当前失败随之停止表面上看就像是那次升级的功劳。但它不是失败还会回来。文档在此处明确打预防针防止团队把相关性误认为因果。六、处置选项与各自的证据选项 1削减服务端 chunk 数——唯一攻击机制的杠杆已关闭experimental.turbopackServerSideNestedAsyncChunking: true把上表中的服务端 chunk 从 24,552 降到 7,122-71%。由于 P(碰撞) 随 chunk 数的平方增长这大致把期望碰撞次数削减 9 倍后文 A/B 测得更精确的结论是约 11.7 倍。该 flag 在 next.config.mjs 第 311 行当前被显式设为false其上附带了一大段注释第 270–310 行把本文全部结论浓缩进了代码库——包括碰撞机制、{0,1,2}首字符限制、2 × 38^6 可用空间、以及禁止翻转此 flag的红色警告。文档原样保留了这个 flag 的完整决策史值得完整继承阻塞一已清除该 flag 在 Next 16.3.0 上是坏的——19 条__turbopack_context__.a is not a functionPostCSS 错误对应上表 Run 3因此它依赖 16.3.1 升级先落地16.3.1 落地后该阻塞清除Run 5 证明可编译。阻塞二关闭了该选项该 flag 带来的峰值构建器 RSS 超过强制执行的 40 GiB 构建容器内存上限。该门禁在文档初版时还是待验证项2026-08-30 在 16.3.1 上实测后确认装不下。文档标注禁止翻转此 flag。选项 2带公开最小复现重新提交上游唯一真修复路径真正修复只能是上游的更宽或可配置哈希。现有 issue 死于缺复现机器人所以这是一份待办工作而不是等待。选项 3什么都不做重试失败构建明确无效文档特意把这一点写明以免有人浪费时间失败对代码树是确定性的重试没有意义。七、选项 1 的关闭证据flag 装不下 40 GiB 内存上限这是 2026-08-30 增补、并取代了早期未验证表述的核心章节。门禁问题是flag 的峰值构建器 RSS 能否装进强制执行的 40 GiB 构建容器上限结论是不能三条独立证据相互印证其中两条在初版文档写作时已存在于仓库历史中证据 1本仓库自身生产史。civitai#3458commit08010713702026-07-30开启过该 flagcivitai#3807commitc7715130112026-08-11将其关闭原因写得明白release build 在 37–39 GiB 处被 OOMKill 了三次对照当时新执行的 40 GiB builder 上限。也就是说该 flag 早已在生产中被试过一次且已经失败过一次。当时唯一未决的问题是16.3.1 是否改变了这一局面。证据 2同一 commit 在 Next 16.3.1 上的 A/B 对照2026-08-18冷.next每组两个臂都是rc0的完整构建每臂两次运行外部以 4 Hz 采样指标base2 次均值serverchunk2 次均值Δnext-build峰值 RSS15.53 GiB22.20 GiB43.0%构建容器峰值22.18 GiB28.91 GiB30.3%服务端 chunk 数.js24,5967,177−70.8%服务端 chunk 总字节530,006,443297,943,127−43.8%墙钟时间155 s218 s41.0%基线两次运行方差 1.4%、serverchunk臂 0.5%因此 43% 效应约是噪声底的 30 倍两次基线运行产出的字节完全一致是独立的确定性对照。−70.8% 的 chunk 削减复现了上表 Run 5 且是真实的(7177/24596)² 0.085即期望碰撞减少约 11.7 倍。收益无可疑处是成本关闭了该选项。证据 3当前 builder 内存分布2026-08-30 重测近 7 天 n67 个main构建中位24.11 GiBp9027.72 GiB最差观测28.59 GiB对照 40 GiB 上限。把实测乘子套到最差的观测构建上得到37.3–39.8 GiB——恰好落在上次开启该 flag 时 release build 被 OOMKill 三次的 37–39 GiB 区间内。没有余量可花。附带关闭用关 sourcemap来支付这笔费用把 flag 与turbopackSourceMaps: false组合可以在几乎噪声级的构建内存代价下保住全部 −70.8% 的 chunk 削减——看起来像一条出路。但不是服务端.js.map在本仓库有三个消费者其中一个是硬门禁scripts/assert-compiled-branches.mjs — 硬 CI 门禁自 civitai#4075 起变硬在 server 目录下找不到任何.js.map时直接报错退出。该脚本头部注释第 39–48 行说明了它为什么必须读 sourcemap直接 grep 产物 JS 是陷阱——minified 符号按 chunk 命名、同一源模块被内联进约 200 个 chunk、闭集字面量在 server 构建中出现约 481 次而.js.map的sources/mappings让被监控行是否有映射成为一个无诱饵、免疫重命名、免疫 minifier 折叠if (a) return x; return y;判定。src/server/utils/errorHandling.ts — 运行时对生产环境服务端错误栈做 de-minify第 12 行import { SourceMapConsumer } from source-map第 660 行applySourceMaps(stack)逐帧解析并还原源码位置。scripts/resolve-cpuprofile.mjs — CPU profile 的 de-minify 路径。它按镜像 tag 从独立的 maps 工件镜像civitai-web-maps:tag由 Dockerfile 第 143–154 行的FROM scratch AS maps目标发布按需拉取服务端 map保持运行镜像精简约 761 MB。且这个开关不可拆分在 Turbopack 下experimental.serverSourceMaps是惰性的webpack 专用见 next.config.mjs 第 133–140 行的注释turbopackSourceMaps是覆盖客户端和服务端的单一开关。不存在保留 server map、砍掉内存的配置。八、最终处置与遗留问题综上剩下的路是选项 2向上游提交哈希空间缺陷——唯一真修复加围堵把这个错误签名从构建重试中豁免因为碰撞对代码树是确定性的重试只会把第二、第三个完整构建烧在同样的失败上。文档还点了一个值得注意的反直觉结论内存上限才是最近的险点而不是碰撞。今天 flag 关闭状态下构建最差观测 28.59 GiB对照 40 GiB 上限而模块图每周都在增长。普通的图增长先撞顶的概率高于碰撞先撞顶的概率。文档同时诚实地列出了未验证项not verifiednestedAsyncChunking: true下产物能编译通过之外是否行为正确——至今未被验证上面的运行、08-18 A/B只断言rc0完整构建即编译 页面数据 静态生成从未运行过产出的 server、以及 2026-08-30 关闭选项 1 的评审都没覆盖。因为 flag 最终没有开启这从未成为承重问题但若将来再试必须先回答它。碰撞的绝对发生率按实测 chunk 数做 per-namespace 生日模型单次构建约 1%但不同分支的实际失败率肉眼可见地高于该值。要么 CI 输出的 chunk 比本地构建多要么有效哈希空间比建模的更小。选项 1 的相对改进随 chunk 数平方不依赖解决这个矛盾但任何引用模型得出的绝对率都必须带上这个保留。Run 4 与 Run 5 在Compiled successfully之后以非零码退出源于一个无关的本地Invalid environment variables错误——碰撞发生的编译阶段本身是完成的。九、方法论提炼这起事故从报错到决策归档沉淀出几条可迁移的构建排障经验先精读报错的语义再行动。本例中碰撞路径在Error:行的上一行底部哈希文件只是 diff 用的 dump2 errors 是 1 次碰撞的双面上报。误读报错方向会把排查引向缓存或 map 文件。用结构上排除条件的实验做证伪。本地冷构建无 Docker、无 cache mount、无并发复现失败使共享缓存假设从没有证据升级为被证伪配合缓存目录是输出目录严格子目录与文件缓存本已关闭两条独立证据结论稳固。区分修好与重新掷骰子。16.3.1 变绿只是图内容变化碰巧错开了碰撞对所有机制量哈希宽度、首字符分布、namespace 规模均未移动失败率不变。在升级与其他变更重叠落地时这一点是防止归因错误的疫苗。攻击机制而不是重试。chunk 数平方律让削减 chunk 数成为唯一杠杆重试对确定性失败是纯浪费。每个选项的关闭都要留证据。内存上限用生产史 同 commit A/B 分布外推三线印证sourcemap 折衷用三个消费者 开关不可拆分关闭。决策文档的长期价值正在于此。附关键文件索引内容路径事故复盘原文claudedocs/turbopack-chunk-hash-collision-2026-08-18.md构建配置flag、sourcemap、文件缓存开关及大段决策注释next.config.mjs第 133–156、264–333 行镜像构建与共享 cache mount、maps 工件目标Dockerfile第 55–56、123–154 行构建脚本定义与 next 版本package.json第 67、284 行服务端 sourcemap 硬门禁scripts/assert-compiled-branches.mjs运行时错误栈 de-minifysrc/server/utils/errorHandling.tsCPU profile de-minify 与 maps 工件拉取scripts/resolve-cpuprofile.mjs以上结论均以当前仓库next^16.3.1、Turbopack 默认打包器为准若升级 Next 版本或修改 chunk 相关配置文中测量值chunk 数、哈希宽度、内存乘子需要重新验证。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 civitai 构建排障实战：Turbopack 服务端 chunk 哈希生日碰撞的根因定位与处置决策
civitai 构建排障实战Turbopack 服务端 chunk 哈希生日碰撞的根因定位与处置决策【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本文基于 civitai 仓库中的事故复盘文档 turbopack-chunk-hash-collision-2026-08-18.md完整还原一次 Next.js 16Turbopack生产镜像构建失败事件从next build报错的误读陷阱、7 字符服务端 chunk 命名哈希的生日碰撞根因测量到区分性实验排除共享构建缓存假设、以及唯一能攻击机制的开关为何最终被内存上限关闭的完整证据链。读完后你将掌握一套可迁移的构建排障方法论——如何正确解读打包器报错、如何用受控实验证伪竞争假设以及如何为修不了的上游缺陷做出有数据支撑的处置决策。一、事故背景与适用前提civitai 的 Web 主应用是一个 pnpm monorepo 中的 Next.js 应用构建入口是根 package.json 中的build: next build第 67 行Turbopack 自 Next 16 起成为默认打包器。生产镜像由仓库根 Dockerfile 构建其中 builder 阶段执行生产构建的那一步第 55–56 行是RUN --mounttypecache,target/app/.next/cache \ SKIP_ENV_VALIDATION1 IS_BUILDtrue NODE_OPTIONS--max_old_space_size${NODE_BUILD_MEM} pnpm run build注意--mounttypecache,target/app/.next/cache这一共享构建缓存挂载——它在后文中扮演竞争假设的关键角色。截至文档更新时2026-08-30仓库状态为诊断完成但未修复next版本为^16.3.1见 package.json 第 284 行。文档开篇特别澄清16.3.1 只是重新掷了一次骰子re-roll并没有修复碰撞机制本身。二、症状一个极易误读的构建报错镜像构建失败发生在上面RUN步骤执行的next buildTurbopack中报错原文如下Error: Turbopack build failed with 2 errors: [output]/.next/server/chunks/ssr/[root-of-the-server]__0gduaxh._.js Error: Two or more assets with different content were emitted to the same output path file content differs, written to: [output]/.next/abf442f9b482f9c2.js [output]/.next/5e217de9956f5326.js这段报错有两个经典的误读陷阱必须讲清楚底部的两个哈希文件名不是碰撞体。abf442f9b482f9c2.js和5e217de9956f5326.js是 Turbopack 为你 dump 出来的调试文件方便你对比两份不同内容。真正发生碰撞的输出路径是Error:行的上一行——即[root-of-the-server]__0gduaxh._.js。如果你看到两个.map文件碰撞了这样的报告说明报告者读的是 dump 文件名而非碰撞路径。2 errors 实际是一次碰撞不是两次。chunk 本身和它配套的 sourcemap 会被分别上报所以只要开启 sourcemap本仓库确实开着productionBrowserSourceMaps: true一个发生碰撞的 chunk 就会产生两条错误.js和.js.map各一条。这两点直接决定了后续排查方向碰撞发生在.next/server/chunks/下的单个服务端 chunk而不是构建缓存里成对的文件。三、根因7 字符哈希空间里的生日碰撞根因是一个上游 Turbopack 缺陷服务端 chunk 命名哈希7 个字符发生了生日碰撞birthday collision。Turbopack 的服务端 chunk 命名为namespace_hash._.js。文档中对一次构建的全部输出 chunk 做了实测统计测量项数值输出的服务端 chunk 总数24,552哈希宽度其中 21,543 个为 7 字符哈希字母表38 个字符0-9 a-z - _首字符分布0占 43.7%1占 43.2%2占 1.9%最大 namespace[root-of-the-server]_— 11,730 个 chunk关键在最后一行数据首字符在实践中被限制在{0, 1, 2}内因此实际可用哈希空间约为2 × 38^6≈ 6.0×10⁹只是标称38^7空间的约 5%。而单个 namespace 里有约 1.17 万个 chunk——这是一个再标准不过的生日问题。发生碰撞的两个 chunk 彼此毫无关系一个是 14,266 字节、另一个是 17,606 字节模块集合不相交却都被映射到了[root-of-the-server]__0gduaxh._.js。这解释了事故观察到的全部诡异现象对给定模块图是确定性的。同一个 commit 重建必然再次失败。重试失败的构建、或者推一个空 commit都无法清除它。只要模块图发生任何变化碰撞对就会换一组。所以 git bisect 能找到坏 commit但永远找不到肇事文件回滚一个毫不相关的文件也能修好问题——因为它扰动了图。肇事者不是最近改动的任何代码。只命中部分分支且与分支新旧无关——取决于该分支恰好是否包含一对碰撞 chunk。上游报告是 vercel/next.js 仓库的 issue #96976。它被机器人因缺少公开复现链接而自动关闭从未真正 triage因此没有上游修复也没有可升级到的版本。文档中的测量数据是对该 issue 的独立复现。这一点很重要对 Next.js 这类超大规模项目issue 被机器人关掉意味着缺陷长期存在的现实路径工程侧必须自己规划兜底。四、区分性实验排除共享构建缓存假设竞争假设是共享构建缓存碰撞上面的构建步骤挂载了共享 cache--mounttypecache,target/app/.next/cache不同分支的构建可能重叠两次构建可能把相互碰撞的产物写进同一个缓存。该假设预测失败需要并发 热共享缓存两个条件而哈希碰撞假设预测失败在隔离环境下即可确定性复现。实验设计在本地直接构建同一个失败代码树——不用 Docker、不用 BuildKit、不挂缓存、无并发构建先rm -rf .next从结构上彻底排除共享缓存与重叠写入者。结果失败了且两次失败完全一致——相同的碰撞路径、相同的 chunk 数、相同的 2 条错误。这是一个可靠复现因此共享缓存假设被证伪refuted而不仅仅是没有证据支持在缓存与并发都被移除的情况下故障依然发生。另有两条独立证据不利于缓存假设缓存挂载指向.next/cache是输出目录的严格子目录而碰撞资产输出在.next/server/chunks/...位于其外部。Turbopack 的构建文件系统缓存在本仓库本来就是关闭的next.config.mjs 第 315 行turbopackFileSystemCacheForBuild: false。源码注释第 312–314 行还补充了一个易错细节显式写false与省略该键不等价——Next 16.3.0 的默认值是true且 turbopack-build 的dependencyTracking由它派生所以该开关不仅决定磁盘缓存还决定 turbo-tasks 在内存中保留什么。实验结果汇总全部在同一代码树、冷.next、一次一个构建的条件下执行#配置碰撞错误数是否编译通过服务端 chunk 数1Next 16.3.0配置原样基线2否24,5512Next 16.3.0配置原样重复2否24,5513Next 16.3.0nestedAsyncChunking: true0否— 19 条 PostCSS 错误7,1164Next 16.3.1配置原样0是24,5525Next 16.3.1nestedAsyncChunking: true0是7,122五、16.3.1 是重新掷骰子不是修复Run 4 变绿了但不能解读为 16.3.1 修复了这个问题。在 16.3.1 上机制在测量层面完全没变哈希仍是 7 字符24,552 个中 21,543 个、首字符仍被限制043.7% /143.2% /21.9%、最大 namespace 仍约 1.17 万、总 chunk 数几乎相同24,552 对 24,551。决定碰撞概率的任何量都没有移动。真正变化的是模块图的内容它重新决定了哪一对 chunk 会碰撞——正是上游 issue 所描述的扰动一下图它就消失的行为。因此升级 16.3.1 只是解除了当前失败分支的阻塞失败率保持原位。这一点在工程沟通上很关键Next 16.3.1 的升级当时因无关原因civitai#4075正在落地。一旦当前失败随之停止表面上看就像是那次升级的功劳。但它不是失败还会回来。文档在此处明确打预防针防止团队把相关性误认为因果。六、处置选项与各自的证据选项 1削减服务端 chunk 数——唯一攻击机制的杠杆已关闭experimental.turbopackServerSideNestedAsyncChunking: true把上表中的服务端 chunk 从 24,552 降到 7,122-71%。由于 P(碰撞) 随 chunk 数的平方增长这大致把期望碰撞次数削减 9 倍后文 A/B 测得更精确的结论是约 11.7 倍。该 flag 在 next.config.mjs 第 311 行当前被显式设为false其上附带了一大段注释第 270–310 行把本文全部结论浓缩进了代码库——包括碰撞机制、{0,1,2}首字符限制、2 × 38^6 可用空间、以及禁止翻转此 flag的红色警告。文档原样保留了这个 flag 的完整决策史值得完整继承阻塞一已清除该 flag 在 Next 16.3.0 上是坏的——19 条__turbopack_context__.a is not a functionPostCSS 错误对应上表 Run 3因此它依赖 16.3.1 升级先落地16.3.1 落地后该阻塞清除Run 5 证明可编译。阻塞二关闭了该选项该 flag 带来的峰值构建器 RSS 超过强制执行的 40 GiB 构建容器内存上限。该门禁在文档初版时还是待验证项2026-08-30 在 16.3.1 上实测后确认装不下。文档标注禁止翻转此 flag。选项 2带公开最小复现重新提交上游唯一真修复路径真正修复只能是上游的更宽或可配置哈希。现有 issue 死于缺复现机器人所以这是一份待办工作而不是等待。选项 3什么都不做重试失败构建明确无效文档特意把这一点写明以免有人浪费时间失败对代码树是确定性的重试没有意义。七、选项 1 的关闭证据flag 装不下 40 GiB 内存上限这是 2026-08-30 增补、并取代了早期未验证表述的核心章节。门禁问题是flag 的峰值构建器 RSS 能否装进强制执行的 40 GiB 构建容器上限结论是不能三条独立证据相互印证其中两条在初版文档写作时已存在于仓库历史中证据 1本仓库自身生产史。civitai#3458commit08010713702026-07-30开启过该 flagcivitai#3807commitc7715130112026-08-11将其关闭原因写得明白release build 在 37–39 GiB 处被 OOMKill 了三次对照当时新执行的 40 GiB builder 上限。也就是说该 flag 早已在生产中被试过一次且已经失败过一次。当时唯一未决的问题是16.3.1 是否改变了这一局面。证据 2同一 commit 在 Next 16.3.1 上的 A/B 对照2026-08-18冷.next每组两个臂都是rc0的完整构建每臂两次运行外部以 4 Hz 采样指标base2 次均值serverchunk2 次均值Δnext-build峰值 RSS15.53 GiB22.20 GiB43.0%构建容器峰值22.18 GiB28.91 GiB30.3%服务端 chunk 数.js24,5967,177−70.8%服务端 chunk 总字节530,006,443297,943,127−43.8%墙钟时间155 s218 s41.0%基线两次运行方差 1.4%、serverchunk臂 0.5%因此 43% 效应约是噪声底的 30 倍两次基线运行产出的字节完全一致是独立的确定性对照。−70.8% 的 chunk 削减复现了上表 Run 5 且是真实的(7177/24596)² 0.085即期望碰撞减少约 11.7 倍。收益无可疑处是成本关闭了该选项。证据 3当前 builder 内存分布2026-08-30 重测近 7 天 n67 个main构建中位24.11 GiBp9027.72 GiB最差观测28.59 GiB对照 40 GiB 上限。把实测乘子套到最差的观测构建上得到37.3–39.8 GiB——恰好落在上次开启该 flag 时 release build 被 OOMKill 三次的 37–39 GiB 区间内。没有余量可花。附带关闭用关 sourcemap来支付这笔费用把 flag 与turbopackSourceMaps: false组合可以在几乎噪声级的构建内存代价下保住全部 −70.8% 的 chunk 削减——看起来像一条出路。但不是服务端.js.map在本仓库有三个消费者其中一个是硬门禁scripts/assert-compiled-branches.mjs — 硬 CI 门禁自 civitai#4075 起变硬在 server 目录下找不到任何.js.map时直接报错退出。该脚本头部注释第 39–48 行说明了它为什么必须读 sourcemap直接 grep 产物 JS 是陷阱——minified 符号按 chunk 命名、同一源模块被内联进约 200 个 chunk、闭集字面量在 server 构建中出现约 481 次而.js.map的sources/mappings让被监控行是否有映射成为一个无诱饵、免疫重命名、免疫 minifier 折叠if (a) return x; return y;判定。src/server/utils/errorHandling.ts — 运行时对生产环境服务端错误栈做 de-minify第 12 行import { SourceMapConsumer } from source-map第 660 行applySourceMaps(stack)逐帧解析并还原源码位置。scripts/resolve-cpuprofile.mjs — CPU profile 的 de-minify 路径。它按镜像 tag 从独立的 maps 工件镜像civitai-web-maps:tag由 Dockerfile 第 143–154 行的FROM scratch AS maps目标发布按需拉取服务端 map保持运行镜像精简约 761 MB。且这个开关不可拆分在 Turbopack 下experimental.serverSourceMaps是惰性的webpack 专用见 next.config.mjs 第 133–140 行的注释turbopackSourceMaps是覆盖客户端和服务端的单一开关。不存在保留 server map、砍掉内存的配置。八、最终处置与遗留问题综上剩下的路是选项 2向上游提交哈希空间缺陷——唯一真修复加围堵把这个错误签名从构建重试中豁免因为碰撞对代码树是确定性的重试只会把第二、第三个完整构建烧在同样的失败上。文档还点了一个值得注意的反直觉结论内存上限才是最近的险点而不是碰撞。今天 flag 关闭状态下构建最差观测 28.59 GiB对照 40 GiB 上限而模块图每周都在增长。普通的图增长先撞顶的概率高于碰撞先撞顶的概率。文档同时诚实地列出了未验证项not verifiednestedAsyncChunking: true下产物能编译通过之外是否行为正确——至今未被验证上面的运行、08-18 A/B只断言rc0完整构建即编译 页面数据 静态生成从未运行过产出的 server、以及 2026-08-30 关闭选项 1 的评审都没覆盖。因为 flag 最终没有开启这从未成为承重问题但若将来再试必须先回答它。碰撞的绝对发生率按实测 chunk 数做 per-namespace 生日模型单次构建约 1%但不同分支的实际失败率肉眼可见地高于该值。要么 CI 输出的 chunk 比本地构建多要么有效哈希空间比建模的更小。选项 1 的相对改进随 chunk 数平方不依赖解决这个矛盾但任何引用模型得出的绝对率都必须带上这个保留。Run 4 与 Run 5 在Compiled successfully之后以非零码退出源于一个无关的本地Invalid environment variables错误——碰撞发生的编译阶段本身是完成的。九、方法论提炼这起事故从报错到决策归档沉淀出几条可迁移的构建排障经验先精读报错的语义再行动。本例中碰撞路径在Error:行的上一行底部哈希文件只是 diff 用的 dump2 errors 是 1 次碰撞的双面上报。误读报错方向会把排查引向缓存或 map 文件。用结构上排除条件的实验做证伪。本地冷构建无 Docker、无 cache mount、无并发复现失败使共享缓存假设从没有证据升级为被证伪配合缓存目录是输出目录严格子目录与文件缓存本已关闭两条独立证据结论稳固。区分修好与重新掷骰子。16.3.1 变绿只是图内容变化碰巧错开了碰撞对所有机制量哈希宽度、首字符分布、namespace 规模均未移动失败率不变。在升级与其他变更重叠落地时这一点是防止归因错误的疫苗。攻击机制而不是重试。chunk 数平方律让削减 chunk 数成为唯一杠杆重试对确定性失败是纯浪费。每个选项的关闭都要留证据。内存上限用生产史 同 commit A/B 分布外推三线印证sourcemap 折衷用三个消费者 开关不可拆分关闭。决策文档的长期价值正在于此。附关键文件索引内容路径事故复盘原文claudedocs/turbopack-chunk-hash-collision-2026-08-18.md构建配置flag、sourcemap、文件缓存开关及大段决策注释next.config.mjs第 133–156、264–333 行镜像构建与共享 cache mount、maps 工件目标Dockerfile第 55–56、123–154 行构建脚本定义与 next 版本package.json第 67、284 行服务端 sourcemap 硬门禁scripts/assert-compiled-branches.mjs运行时错误栈 de-minifysrc/server/utils/errorHandling.tsCPU profile de-minify 与 maps 工件拉取scripts/resolve-cpuprofile.mjs以上结论均以当前仓库next^16.3.1、Turbopack 默认打包器为准若升级 Next 版本或修改 chunk 相关配置文中测量值chunk 数、哈希宽度、内存乘子需要重新验证。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考