唐山小程序开发实录：从需求到上线

上周把唐山本地一个客户的小程序正式提审上线了，从第一次见面聊需求到最终发布，前后差不多三周。趁着记忆还热乎，把这次「小程序开发实录」写下来，既是给自己留个档，也给唐山这边想做小程序的老板们一个参考——一个真实项目到底是怎么跑起来的，中间会踩哪些坑。

一、需求不是聊出来的，是逼出来的

客户是唐山本地做建材批发的，门店在路南区，之前靠微信群里发报价单接单。老板的原话是：「我就想要个小程序，客户能看货、能下单，别整太花哨。」

听起来简单，但真正坐下来聊，问题就出来了：

• 客户群体年龄偏大，很多人连小程序入口都找不到，得考虑分享卡片和扫码进入的路径；
• 建材有规格、有起订量、有区域运费，价格不能直接挂死；
• 老板自己不会用后台，得把「改价格、上下架」做成傻瓜操作。

所以我一般不建议一上来就报功能清单，而是先跟着客户走一遍他现在的业务流程。这次聊完，需求文档从最初的一页纸变成了四页，但每一项都是真金白银的业务，不是拍脑袋加的。

二、技术选型：够用就好

这个项目没有用太重的架构，微信原生小程序 + 云开发。原因很实际：客户预算有限，也没有专职运维，云开发省掉了服务器和备案的一堆事，后期我远程维护也方便。

// 商品列表按分类分页拉取
async function fetchGoods({ categoryId, page = 1, size = 10 }) {
  const db = wx.cloud.database();
  const res = await db.collection('goods')
    .where({ categoryId, onSale: true })
    .orderBy('sort', 'asc')
    .skip((page - 1) * size)
    .limit(size)
    .get();
  return res.data;
}

这里有个小细节：建材类商品图片多、体积大，直接存云存储再返回临时链接，首屏加载会明显变慢。我的处理是列表页只取缩略图字段，详情页再懒加载大图，配合骨架屏，体验上顺很多。做唐山小程序开发这几年，本地客户对「打开快不快」特别敏感，这一点比什么花哨动画都重要。

三、几个真正花时间的坑

1. 价格体系不能写死

建材价格随行情浮动，客户要求后台能批量改价。我把价格拆成「基础价 + 规格加价」，后台用表格批量导入，避免一条条点。这个功能看着不起眼，却占了整个后台开发时间的三分之一。

2. 下单不等于支付

批发场景很多是「先下单、线下对账」，所以支付做成了可选项：小额在线付，大额走线下确认。这个逻辑如果一开始没和客户对齐，后面改起来非常麻烦。

3. 提审被拒一次

第一次提交因为「类目与内容不符」被驳回，补了营业执照和行业资质才过。这里提醒一句：唐山做小程序的朋友，类目一定要和实际经营内容对得上，别图省事随便选，返工更费时间。

四、上线之后才是开始

小程序上线那天，客户在店里贴了张二维码，当天就有老客户扫码下单。但我知道，真正的考验在后面：

• 数据要看得懂——给老板做了个简单的经营看板，日订单、热销品一目了然；
• 问题要接得住——留了反馈入口，前两周几乎每天都有小调整；
• 迭代要有节奏——先跑通核心流程，再谈会员、营销这些锦上添花的东西。

做本地项目最大的好处是，客户就在身边，出了问题能当面聊，改起来也快。这种信任感是远程单子换不来的。

五、一点总结

这次实录下来，我的感受是：小程序开发从来不是写代码那么简单，更多是把客户的生意逻辑翻译成产品逻辑。唐山这边不少传统行业都在往线上走，需求真实、节奏也快，作为知码客，我挺享受这种「用代码改变生活」的过程——哪怕只是帮一家建材店把报价单搬进手机里。

如果你也在唐山，正琢磨着做个小程序或者 APP，不妨先把现在的业务流程捋一遍，比急着问报价有用得多。