背单词小程序「优词记 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 内置工具链和项目本地工具链并存时版本和行为的差异迟早会咬你一口。选定一条另一条明确封死写进文档。产品本体是个背单词小程序你现在看到的那个正常显示的导航栏背后是一晚上的排查。明天写这个系列的收尾篇注解式权限与操作日志怎么做到后台审计零侵入欢迎关注。
