北京小程序开发规范：别让代码替你得罪客户

上周帮一位做连锁烘焙的客户做代码审计，项目是之前找外包做的，跑是能跑，但打开商品详情页要等三秒多。翻完代码我基本明白了——不是技术难，是没人立规矩。北京这边做小程序的需求量大，团队水平参差不齐，很多项目从第一行代码起就埋了雷。今天这篇不聊虚的，就说说我们知码客在项目里死磕的那几条开发规范，以及为什么值得磕。

目录结构先定死，别让后人猜谜

见过最离谱的一个项目，pages 下面混着 components、utils、还有一堆叫 test1、test2 的文件夹。半年后原开发者联系不上了，接手的人光理清文件关系就花了两天。

我们的规矩很简单：

• pages 只放页面，一个页面一个文件夹，四件套齐全
• components 放公共组件，按业务域再分子目录
• utils 只放纯函数，不许在里面发请求
• api 统一收口所有网络请求，页面里禁止直接调 wx.request

这条规范看着笨，但它决定了项目能不能活过第二个开发者。北京做小程序的外包团队流动性大，代码交接是常态，结构清晰就是给客户省钱。

命名别玩花样，拼音缩写是灾难

有次接手一个项目，变量名叫 spxx、ddd、tmp2。问了一圈才知道 spxx 是"商品信息"。这种代码，作者自己一周后都未必认得。

我们内部约定：变量和函数用驼峰，语义完整；组件名大驼峰；常量全大写加下划线；事件处理函数统一 on 开头，比如 onSubmitOrder。听着像教科书，但真到了排查线上问题的时候，一个能自解释的名字能省半小时。

请求层必须收口，错误处理不能靠运气

小程序里最常见的坑是：每个页面各写各的请求，loading 状态、错误提示、token 过期处理各搞一套。用户看到的现象就是——这个页面转圈圈，那个页面直接白屏。

我们的做法是封装一层 request，统一处理：

export function request(options) {
  return new Promise((resolve, reject) => {
    wx.request({
      ...options,
      header: { Authorization: getToken(), ...options.header },
      success(res) {
        if (res.statusCode === 401) {
          redirectToLogin()
          return reject(new Error('unauthorized'))
        }
        if (res.data.code !== 0) {
          wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' })
          return reject(res.data)
        }
        resolve(res.data.data)
      },
      fail(err) {
        wx.showToast({ title: '网络开小差了', icon: 'none' })
        reject(err)
      }
    })
  })
}

所有页面只调这个封装，token 过期、业务错误、网络异常各走各的分支。这套东西在北京做小程序的交付里属于基本功，但真做到的团队没想象中多。

性能规范：别等用户骂了才优化

北京用户对加载速度的容忍度很低，地铁里信号一抖，页面再卡一下，直接退出。我们定的硬指标：

• 首屏包体积控制在 1.5MB 以内，图片全部走 CDN 并按需压缩
• 列表页必须分页，禁止一次性拉全量数据
• setData 单次数据量不超过 64KB，长列表用虚拟列表
• 非首屏页面用分包加载，主包只留核心链路

之前给朝阳一家做社区团购的客户重构，光是分包和图片压缩两项，首屏时间从 3.2 秒降到 1.1 秒，下单转化肉眼可见地涨了。规范不是洁癖，是直接跟生意挂钩的。

提审前自查，别把审核当抽奖

微信审核驳回的理由翻来覆去就那几类：类目不对、诱导分享、隐私协议缺失、支付资质不全。我们内部有一张提审 checklist，每次上线前逐项过。北京这边做小程序，尤其是涉及本地生活、电商的，类目和资质一定要提前确认，别等代码写完才发现方向错了。

知码客的信条是"知码识途、匠心铸客"。代码是跟用户沟通的语言，规范就是语法——语法乱了，话说得再漂亮对方也听不懂。

规范这东西，写的时候嫌烦，维护的时候真香。如果你正在北京找团队做小程序，或者手头项目已经有点失控，不妨先翻翻代码目录，看看它是不是还讲得清人话。