小程序开发规范：那些年我踩过的坑

做独立开发这些年，接手过不少别人半途而废的小程序项目，也把自己写的代码交给过别人维护。每次打开一个没有规范的代码库，那种感觉就像走进一间从没收拾过的出租屋——能住，但每找一个东西都得翻半天。

今天不聊虚的，就说几个我在真实项目里反复验证过的规范，都是踩坑踩出来的。

目录结构别学大厂，够用就行

很多教程一上来就给你画一棵三层嵌套的目录树，什么 services、utils、components、pages 分得明明白白。结果实际开发时，一个页面要改五个文件，来回跳转能把人逼疯。

我的做法是按业务模块分，而不是按文件类型分：

pages/
  order/
    index.js
    index.wxml
    index.wxss
    api.js      // 这个模块的接口
    utils.js    // 这个模块专用的工具
  user/
    ...
components/
  common/       // 全局复用的组件
utils/          // 真正全局的工具

好处很直接：改订单相关的东西，只在一个文件夹里转，不用满项目找。模块之间耦合低了，删代码也敢下手。

命名这件事，统一比优雅重要

团队里有人喜欢 getUserInfo，有人写 fetch_user_info，还有人直接 getuser。规范的第一原则不是选哪个风格，而是所有人选同一个。

• 变量和函数用驼峰：orderList、submitOrder
• 常量全大写加下划线：MAX_RETRY_COUNT
• 布尔值带前缀：isLoading、hasPayed、canSubmit
• 事件处理函数以 on 开头：onTapSubmit、onInputChange

尤其是布尔值那个前缀，写条件判断的时候 if (isLoading) 比 if (loading) 少想半秒钟，一天下来省不少脑力。

setData 是性能命门，别乱用

小程序和普通网页最大的区别就是逻辑层和视图层分离，每次 setData 都要跨线程通信。我见过一个列表页，每渲染一条数据调一次 setData，五十条数据卡得跟幻灯片似的。

记住几条：

• 能合并的 setData 一次传完，别放在循环里
• 只传变化的部分，用路径写法：this.setData({ 'list[0].status': 1 })
• 列表数据量大时用 scroll-view 分页，别一次性全塞进去
• 纯展示、不参与逻辑的数据，考虑放 data 之外，用 this.xxx 挂载

// 反例：循环里 setData
list.forEach((item, i) => {
  this.setData({ [`list[${i}].checked`]: true })
})

// 正例：一次搞定
const patch = {}
list.forEach((item, i) => {
  patch[`list[${i}].checked`] = true
})
this.setData(patch)

接口请求统一收口

最怕看到页面里到处是 wx.request，每个地方自己拼 url、自己处理错误、自己加 loading。等接口域名换了或者要加 token，改到你怀疑人生。

我的习惯是封装一个 request，统一处理：

• baseURL 和公共 header
• token 失效自动跳登录
• 统一的错误提示
• 请求超时和重试

页面里只关心业务数据，const res = await request({ url: '/order/list' })，干净利落。这个封装在项目初期花半小时，后期能省几十个小时。

提交前跑一遍 lint，别靠自觉

规范写在文档里没人看，写进工具里才有效。配好 ESLint 和 stylelint，在 package.json 里加个 lint-staged，提交前自动检查改动的文件。

另外几个小习惯值得坚持：

• 每个页面在 onUnload 里清理定时器和事件监听，不然内存泄漏查起来很痛苦
• 图片资源走 CDN，别往包里塞大图，主包 2M 的限制说超就超
• 公共组件抽出来之前先想清楚，复用三次以上再抽，过早抽象也是负担

写在最后

规范这东西，不是为了让代码好看，是为了让三个月后的自己、让接手的人少骂几句。小团队和独立开发者尤其要注意，你没有专门的 code review 环节，规范就是你的安全网。

不用一次全上，先从目录结构和 setData 这两条开始，养成习惯之后再慢慢加。规范是长出来的，不是抄出来的。