你刚推送完代码，咖啡还没凉，构建就挂了。更诡异的是：代码完全没动，三个月前还能跑。

这是前端开发者最熟悉的噩梦——不是自己的错，却要自己修。而真相藏在一个文件名最不起眼的字符里。

打开网易新闻 查看精彩图片

第一现场：构建失败的诡异现场

三个月前，作者把Qwik站点部署到Netlify，一切正常。某次推送无关内容更新后，构建突然死亡：

Edge Functions bundling阶段抛出ENOENT错误，找不到qwik-city-not-found-paths.js。但作者确认：package.json没升版本，配置没改，本地构建完全正常。

升级所有依赖到最新版，失败。新建一个Qwik hello-world项目推上去，还是失败。

「那时候我就知道，问题在Netlify那边。」

排查深渊：从缓存清理到源码挖掘

常规操作全部失效。作者搜索相关错误信息，只找到一个论坛帖子描述同样问题，零回复，七天后自动关闭。

在Netlify官方论坛发帖求助，响应来了——几小时后。站点已经下线，等不起。

作者开始深挖。注意到失败发生在Edge Functions打包阶段，这是主构建完成后的额外步骤。打开本地输出目录，发现了关键线索：

文件明明存在，叫@qwik-city-not-found-paths.js——前面有个@符号。但错误信息里，@消失了。

「如果打包器知道文件存在，为什么去找一个名字错的文件？」

某个环节正在悄悄剥离这个@。

源码追踪：定位犯罪现场

作者拉下@netlify/build源码，包括负责Edge Functions打包的edge-bundler包。顺着调用链追踪：

edge_functions/index.ts → bundler.ts → formats/tarball.ts

在tarball.ts里，文件列表这样生成：

先递归列出目录，转相对路径，调getUnixPath()，排序，最后打包成tar。问题一定在getUnixPath()里。

找到这个函数：

它用正则表达式把Windows反斜杠换成Unix正斜杠。看起来无害——但等等，正则之前还有一步：path.normalize()。

Node.js的path.normalize()有个鲜为人知的特性：在Windows上，它会特殊处理以@开头的路径，将其视为「当前目录的命名空间限定符」，然后……把它吞掉。

不是Netlify的代码有问题，是Node.js核心API在特定平台上的行为，被Netlify的跨平台路径处理代码触发。

时间线复盘：Bug如何潜伏三个月

三个月前构建成功，现在失败，中间发生了什么？

作者检查Netlify的构建镜像更新日志，发现三周前他们升级了默认Node版本。新版本里，path.normalize()对@符号的处理逻辑有微妙调整——或者更可能的是，Netlify的构建容器从Linux换成了Windows环境，触发了这条代码路径。

一个@符号，在Linux构建机上平安无事，在Windows构建机上被当成命名空间标记抹除。Qwik框架偏偏喜欢用@前缀标记内部模块，完美踩雷。

这不是Netlify独有的问题。任何跨平台处理文件路径的Node.js工具，如果用了path.normalize()再处理含@的文件名，都可能中招。

修复与反思：开源协作的样本

作者向Netlify提交PR，把getUnixPath()里的path.normalize()换成不处理@符号的纯字符串替换方案。合并、发布、验证——构建绿了。

从发现问题到修复上线，全程不到24小时。但之前的排查花了整整三个月，加上一个被迫下线的站点。

这个案例给开发者的启示很直接：

第一，跨平台路径处理是雷区，Node.js核心API的行为差异比文档描述的更隐蔽。第二，构建环境的微小变化（Node版本、操作系统镜像）可能让沉睡的Bug苏醒。第三，当官方论坛的响应速度赶不上业务损失时，自己读源码是唯一出路。

Netlify的构建日志现在会明确标注运行环境。但那个让无数人抓狂的@符号，依然躺在无数Node.js代码库的path.normalize()调用里，等待下一个受害者。