北京小程序开发：开发工具实战避坑

做北京的小程序项目这几年，我越来越觉得：开发工具这件事，看起来是最没技术含量的环节，实际上最容易拖慢交付节奏。客户在国贸、在望京、在中关村，需求聊得都挺顺，最后卡住的往往是工具链上的小坑——编译慢、真机调试连不上、上传代码卡在 99%。今天就把我在北京做小程序时踩过的工具坑整理一下，都是能直接上手用的经验。

一、先把开发者工具的基础配置做对

微信开发者工具装完别急着写代码，几个默认设置先改掉，能省下大量等待时间。

• 关闭「自动预览」：项目一多，每次保存都触发预览，机器风扇直接起飞。改成手动预览，按需触发。
• 开启「不校验合法域名」只在开发环境：本地联调接口方便，但上线前一定要在真机上再验一遍，很多北京客户的服务器走的是内网穿透，本地能通不代表线上能通。
• 把项目目录放到 SSD 上：node_modules 和编译缓存体积不小，机械硬盘上编译一次小程序能等出焦虑。

二、真机调试连不上？先排查这三件事

真机调试是北京小程序开发里最高频的求助场景。客户拿着手机说「白屏」，你在工位上干着急。按顺序排查：

1. 手机和电脑是否在同一个局域网。公司 Wi-Fi 常开了 AP 隔离，换成手机热点往往立刻就好。
2. 开发者工具版本和基础库版本是否匹配。基础库选「最新」，但线上发布前要回退到客户实际覆盖的版本区间测一遍。
3. 如果是预览二维码扫不开，检查项目是否开启了「代码保护」，开了之后预览会受限。

一个小习惯：给每个北京本地客户建一个独立的项目分支和独立的小程序体验版，别共用一个 AppID 来回切，切多了缓存串味，排查问题会怀疑人生。

三、编译速度优化：从 40 秒到 8 秒

中大型小程序项目，页面一多，热重载能慢到让人分心去刷手机。几个实测有效的做法：

• 分包加载，主包只留 tabBar 和公共组件，工具的分包编译是增量的，效果立竿见影；
• 关掉「上传时压缩代码」的本地开关，压缩放到 CI 里做；
• 清理工具缓存目录，长期不清理的编译缓存会越滚越大；
• 图片资源走 CDN，别塞进项目目录，工具对大量静态资源的索引很吃力。

// app.json 分包配置示例
{
  "pages": ["pages/index/index"],
  "subpackages": [
    {
      "root": "packageOrder",
      "pages": ["list/list", "detail/detail"]
    }
  ],
  "preloadRule": {
    "pages/index/index": {
      "network": "all",
      "packages": ["packageOrder"]
    }
  }
}

四、上传与提审：工具只是第一步

点「上传」之后才是真正的流程。北京这边的客户不少是连锁门店、本地生活服务类，审核对类目和资质卡得比较细。上传前用工具的「代码质量」面板扫一遍，把未使用的组件、过大的包体、console 残留清掉。提审描述写清楚业务场景，比写一堆技术术语管用。

另外提醒一句：工具里的「体验版」不是测试版，别把带 mock 数据的版本直接给客户看，体验版是可以被转发出去的，这一点在北京做小程序时尤其要注意，客户内部转发一圈，问题就被放大一圈。

五、一点实在话

知码客一直信「知码识途、匠心铸客」，工具再顺手也只是手段。北京小程序开发、北京 APP 开发这个圈子里，真正拉开差距的是对本地业务场景的理解——门店核销、预约排队、会员储值，这些需求背后是具体的运营动作，不是几个页面拼起来就完事。开发工具帮我们把重复劳动压下去，剩下的时间才该花在跟客户把需求抠清楚上。

如果你正在北京做小程序，或者手上有个项目卡在工具链上，欢迎聊聊，很多坑其实一句话就能绕过去。