唐山小程序开发：前后端实战避坑

去年冬天接了个唐山本地的活儿，一家做建材批发的老板找我，说想给老客户做个下单小程序，别再天天微信里发图片报价了。聊完需求我发现，这类项目最典型的痛点不在前端页面多花哨，而在前后端怎么配合、怎么让老板自己能维护。今天就把这个项目里踩过的坑和做法整理一下，写给正在考虑唐山小程序开发的朋友。

先想清楚：前后端边界划在哪

很多第一次做小程序的人以为「前端画页面、后端存数据」就完了，真做起来会发现边界模糊。我的习惯是按「谁改得频繁」来划：

• 商品价格、库存、活动文案——放后端，老板随时能改；
• 页面结构、按钮位置、交互流程——放前端，改一次发一次版；
• 用户登录态、订单状态机——后端说了算，前端只负责展示。

这个建材项目里，老板一开始想让我把价格写死在页面里，说「反正不常变」。我劝住了：批发价按客户等级走，写死等于每次调价都要重新提审，微信审核周期摆在那，耽误生意。后来改成后端配置，他在管理后台点几下就生效了。

后端选型：别一上来就上重架构

唐山不少做实体生意的客户，预算和运维能力都有限。我的建议是：日均订单几百单以内，直接用微信云开发或者一台轻量云服务器跑 Node/Java 都够。这个项目我用了云开发，原因很实在——

• 不用单独买数据库、配域名备案，省掉一周时间；
• 云函数天然带鉴权，openid 直接拿，登录逻辑少写一大截；
• 客户后期想自己看数据，云开发控制台能直接查。

当然云开发也有短板，复杂查询和事务能力弱。如果后面订单量上来、要做分账和报表，我会建议迁到自建后端。技术选型要看阶段，不是越先进越好。

前后端联调，这几个细节最耗时间

1. 接口字段命名提前对齐

前端习惯驼峰，后端数据库喜欢下划线，不提前约定，联调时满屏 undefined。我的做法是写一份简单的字段表，前后端各留一份，改字段必须同步。

2. 登录态别只靠本地缓存

小程序里很多人把 token 存 storage 就一直用，过期了才报错。正确做法是请求拦截里统一处理 401，静默重新登录再重放请求。这段代码不长，但能省掉大量「用户说打不开」的售后。

// 请求封装示意
async function request(options) {
  const res = await wx.cloud.callFunction({
    name: 'api',
    data: { path: options.path, payload: options.data }
  });
  if (res.result.code === 401) {
    await reLogin();
    return request(options);
  }
  return res.result.data;
}

3. 图片和文件走云存储

建材客户要传产品图，直接 base64 塞数据库是灾难。统一走云存储拿 fileID，数据库只存 ID，前端用临时链接展示，加载速度和费用都好看很多。

本地场景带来的额外要求

做唐山app开发和小程序这几年，我发现本地客户有几个共性需求：一是要能对接线下门店的收银或进销存，二是老板年纪偏大，后台必须做得「傻瓜化」。这个项目最后给老板做了个手机端管理页，他躺沙发上就能改价格、看当天订单，比电脑后台用得还勤。类似的需求在唐山做小程序的项目里很常见，方案要贴着人走，不能只贴技术。

给同行一句提醒：本地项目交付时多留半天做培训，录两段操作视频发群里，后期维护成本能降一大半。

上线前别漏的检查项

1. 隐私协议和用户信息授权弹窗是否合规；
2. 支付回调是否做了幂等，防止重复发货；
3. 云函数超时时间是否够用，批量操作要拆；
4. 真机测一遍弱网，别只在开发者工具里点。

我是知码客，专注小程序和 APP 开发，平时在唐山及周边接项目，也写点踩坑记录。前后端这件事，说到底不是技术堆砌，而是把业务流程想明白再落代码。有类似需求的朋友，欢迎一起聊聊你的场景。