郑州小程序开发规范避坑指南

在郑州做小程序这几年，见过太多项目死在“不规范”三个字上。需求文档一页纸、命名靠拼音、接口返回全靠猜、上线前一天才发现审核被拒——这些坑，几乎每个本地团队都踩过。我是知码客，专注小程序和 APP 开发，今天把我们在郑州本地项目里沉淀下来的开发规范整理成一篇，能直接拿去用的那种。

一、项目结构规范：别让接手的人骂娘

小程序项目最怕的就是“一个人一套目录”。郑州不少外包项目交接时，新接手的开发者打开代码先愣五分钟。我们内部统一的结构大致是这样：

• pages：按业务模块分目录，比如 pages/order、pages/user，不按页面类型堆
• components：公共组件，一个组件一个目录，含 js/json/wxml/wxss 四件套
• utils：工具函数，按功能拆文件，禁止一个 util.js 塞几百行
• api：接口请求统一收口，页面里不直接写 wx.request
• config：环境配置、常量、枚举集中管理

目录定好之后，写进 README，新同事第一天就能上手，这是最省成本的一件事。

二、命名与代码风格：统一比优雅重要

命名规范不需要多高级，关键是全队一致。我们的约定是：

• 页面路径用小写加中划线，如 order-detail，不用拼音缩写
• 变量用驼峰，常量全大写加下划线
• 组件名用大驼峰，事件回调统一 onXxx 前缀
• 禁止在 wxml 里写复杂逻辑，三元嵌套超过两层就抽到 js 里

另外强烈建议接入 ESLint 加 Prettier，提交前自动格式化。郑州本地团队人员流动不算小，规范靠人记不住，靠工具才靠得住。

三、接口与数据层规范

接口是小程序最容易失控的地方。我们要求所有请求走统一封装，处理 loading、错误码、token 刷新、超时重试，页面只关心业务数据。

// api/request.js
const BASE_URL = {
  dev: 'https://dev.api.example.com',
  prod: 'https://api.example.com'
}

function request(options) {
  return new Promise((resolve, reject) => {
    wx.request({
      url: BASE_URL[__ENV__] + options.url,
      method: options.method || 'GET',
      data: options.data || {},
      header: { Authorization: getToken() },
      success(res) {
        if (res.statusCode === 200 && res.data.code === 0) {
          resolve(res.data.data)
        } else {
          handleError(res.data)
          reject(res.data)
        }
      },
      fail: reject
    })
  })
}

接口返回结构也统一：{ code, message, data }，前后端在需求评审时就把这个定死，后面少吵很多架。

四、性能与体验规范

郑州本地客户里，餐饮、零售、本地生活类小程序居多，用户手机型号参差不齐，性能规范必须写死：

• 首屏图片全部走 CDN，单张不超过 200KB，列表图用懒加载
• setData 单次数据量控制在合理范围，禁止整对象回传
• 分包加载，主包控制在 2MB 以内，非核心页面放分包
• 页面 onUnload 里清理定时器和监听，避免内存泄漏

性能不是上线后再优化的事，是写第一行代码时就该有的习惯。

五、上线与审核规范

很多郑州做小程序的团队栽在审核上。我们的检查清单包括：类目和实际功能一致、隐私政策弹窗必须配置、用户信息授权要有拒绝后的降级路径、涉及支付的必须有明确的服务协议。提交前用真机走一遍完整流程，别只信开发者工具。

最后说句实在话：规范这东西，小项目看着像负担，但只要你打算长期维护、打算交给别人接手、打算在郑州本地把口碑做起来，它就是最划算的投入。知码客做项目一直坚持这套流程，代码能改、能扩、能交接，比什么都重要。