背单词小程序「优词记 Pro」技术复盘第六篇。前面几篇偏设计取舍，今天是纯粹的踩坑记录——发布前夜，生产构建的产物里导航栏和 tabbar 直接消失了，全局样式错乱，而开发预览一切正常。排查过程有点意思，写出来给同样用 uni-app 的朋友避坑。

现象：dev 正常，发行产物坏掉

项目是 HBuilderX 目录结构（源码在根目录而非 src/），日常用 HBuilderX「运行」到微信开发者工具，一直没出过问题。准备上线时改用 HBuilderX 的「发行」做生产构建，产物导入微信开发者工具一看：自定义导航栏（uv-navbar）没了，自研 tabbar 没了，页面样式大面积错乱。

诡异的地方有两点：构建全程零报错零警告，组件是被静默丢弃的；而且同一份代码用「运行」（dev 链路）构建就完全正常。

排查：消失的都是 easycom 组件

对比 dev 和发行两份产物，发现规律：消失的组件全部是走 easycom 自动注册的——uni_modules 里的 uv-ui 组件、按 pages.json 里 easycom 规则匹配的自定义组件，一个不剩。手动 import 注册的组件全都活着。

方向就清楚了：不是代码问题，是发行链路上 easycom 的扫描注册环节失效了。

根因：两份编译器实例混用

这个项目虽然是 HBuilderX 目录结构，但为了能脱离 IDE 在命令行构建，node_modules 里装了完整的本地 uni-app CLI 编译器。问题就出在这：HBuilderX「发行」时会把自带的内置编译器和项目本地的编译器两份实例混在一起用，easycom 的解析规则在两份实例间没有共享，扫描结果丢失，组件引用被当成未知标签静默跳过——所以既没有报错，也没有产物。

而「运行」（dev）链路不会触发这种混用，这解释了为什么日常开发几个月都没暴露。

解法：构建链路只保留一条

修复本身很简单——生产构建彻底绕开 HBuilderX，统一走 npm 脚本：

npm run build:mp-weixin     # 生产构建
npm run release:mp-weixin   # 构建 + 自动打开微信开发者工具

npm 脚本通过一个包装器显式指定 UNI_INPUT_DIR 和 UNI_OUTPUT_DIR，从头到尾只用 node_modules 里那一份编译器，easycom 完好，产物和 dev 表现一致。日常开发依然可以用 HBuilderX「运行」，实测不受影响；只有「发行」这条链路被彻底禁用，并把这条规则写进了项目文档。

两条通用教训

• 静默失败比报错可怕得多。easycom 这类「约定优于配置」的机制，失效时往往不会报错——它只是"没匹配上"。依赖这类机制的项目，发布前一定要真机或预览工具里过一遍关键页面，别只看构建是否成功。

• 同一个项目里，同一件事只允许一条链路做。IDE 内置工具链和项目本地工具链并存时，版本和行为的差异迟早会咬你一口。选定一条，另一条明确封死，写进文档。

产品本体是个背单词小程序，微信搜「优词记 Pro」可以体验——你现在看到的那个正常显示的导航栏，背后是一晚上的排查。明天写这个系列的收尾篇：注解式权限与操作日志，怎么做到后台审计零侵入，欢迎关注。