从 0 到 1 交付一个小程序：我的技术决策清单

很多人第一次做小程序，会下意识把它看成一个小项目。

页面不算多，功能也许只有几块，后台可能也不复杂，于是大家很容易觉得：先做起来再说，边做边定。

我以前也这么干过。后来发现，小程序从 0 到 1 最容易失控的地方，不是开发量，而是决策延迟。

什么叫决策延迟？

就是那些本来应该在早期想清楚的问题，被一路往后拖：

• 第一版到底有没有登录门槛
• 用户数据和业务数据怎么关联
• 文件是私有还是公开
• 权限放前端、接口层还是数据库层
• 要不要给内容上审核状态
• 后端是云开发、Supabase 还是自建服务
• 异常和弱网到底怎么兜

这些问题拖到后面不是“再想一下”那么简单，而是会反过来影响已经写好的页面、接口、数据库和测试。

所以这篇文章不是想给出一个标准答案，而是把我自己做小程序交付时最常用的一套决策顺序整理出来。顺序比答案更重要，因为很多技术问题一旦问晚了，代价会非常高。

第一步不是选技术，而是先判断这到底是什么项目

如果一上来就讨论“用什么技术栈”，大概率会把问题讨论偏。

因为同样是小程序，项目类型差异可能非常大。有的是验证想法的 MVP，有的是要交付给客户的商业项目，有的是公司内部流程工具，有的是准备长期运营的产品。这几种项目对技术的要求并不一样。

比如一个纯 MVP，最重要的可能只是三周内把关键流程跑起来。它容忍一些技术债，也容忍架构不够优雅，因为验证节奏比工程完整度更重要。

但如果是一个要正式交付、还要有人接手维护的小程序，很多决定就不能再这么随意。权限、异常、审核、监控、部署说明、回归清单，这些都不再是“以后补”。

所以我现在接一个小程序项目，脑子里先分的不是技术栈，而是阶段：

• 这是验证型产品，还是交付型产品？
• 它有没有可能继续长成一个长期系统？
• 后续谁来维护？
• 失败成本高不高？

你会发现，很多技术争论其实在这个层面就已经能提前结束了。

如果只是验证想法，就没必要一开始造完整后台；如果是正式交付，就不要把所有逻辑写死在页面里，期待以后再慢慢补。

第二步：第一版到底要成立到什么程度

小程序项目另一个很常见的问题，是第一版目标不清楚。

表面上大家都在说“先做 MVP”，但真正落到功能讨论时，又会忍不住把所有觉得“以后大概会需要”的能力提前塞进来。最后的结果往往是，项目看起来像什么都要做，实际上什么都没有做稳。

我现在会强制把需求分成三层：

1. 没有它，产品就不成立
2. 没有它，体验会差，但还能上线
3. 明显有价值，但当前阶段不该做

这个分类很朴素，但它会直接影响后面的技术决策。

比如一个预约类小程序，如果第一版的核心只是“让用户能查看服务并完成预约”，那登录、列表、提交、记录就是必须项；营销活动、优惠券、会员体系、复杂推送就应该先延后。

为什么这一步这么重要？因为技术设计永远会向需求范围靠拢。

如果你嘴上说第一版很小，实际上又默认后面所有复杂能力都马上要接，那你很容易在最开始就设计一套超出当前阶段的结构。它未必完全错误，但大概率会拖慢交付。

反过来，如果你把第一版范围压得太狠，也会出问题。因为某些看起来“可以以后再说”的能力，实际上会决定核心链路是否成立，比如审核状态、权限隔离、文件归属、登录模型。

所以这里真正要问的不是“第一版要做多少”，而是：第一版最小成立集是什么，哪些能力现在不做以后不会推翻前面设计。

第三步：后端选型不是功能对比，而是看你想把复杂性放在哪

很多小程序项目的后端方案，最后会落在这几类里面：

• 微信云开发
• Supabase
• 自建 Node.js 服务
• 传统云服务 + 数据库

我不会用“哪个最好”这种问法来看它们，因为这种比较基本没有意义。真正值得问的是：这个项目的复杂性，应该被放在哪一层承担。

如果你选云开发，你接受的是更强的微信生态耦合，但换来更顺手的接入和较低的初始门槛。

如果你选 Supabase，你拿到的是更完整的 PostgreSQL 能力、更成熟的 Auth / Storage / Realtime 组合能力，但也要自己处理小程序适配、RLS 和微信登录的映射问题。

如果你自建后端，你的控制力最强，但基础设施建设成本也最高。你会更自由，也会更累。

我自己的经验是，前端主导的小程序项目最怕的，不是某项能力没有，而是每一项能力都要从零搭一遍。因为那会把交付节奏彻底拖散。

所以如果项目本身不是极其复杂，又希望后续有继续演进的空间，我会更偏向选择一个成熟的后端底座，把领域逻辑留给自己，把通用基础设施尽量外包给平台。

但如果业务规则非常重，或者已经明确要深度接企业内部系统、自有权限体系、自定义工作流，那自建服务反而会更稳。

选型不是选酷炫，而是选一条你愿意长期承担其代价的路。

第四步：先把数据模型想清楚，再谈页面和交互

小程序是一个很容易让人从页面出发的项目形态，因为页面看得见，反馈也最快。

但如果你先把大量页面写出来，再回头想数据结构，返工概率会很高。因为页面上的每一个列表、状态、按钮，背后最后都要落回数据模型。

我现在做小程序，会很早就去画最核心的实体关系。哪怕不画正式 ER 图，也至少会把几个问题说清楚：

• 核心对象有哪些
• 谁拥有这些对象
• 状态字段有哪些
• 哪些关系是一对多、多对多
• 哪些字段以后一定会参与筛选、排序或统计
• 哪些删除应该是软删除

例如一个协作型小程序，很可能至少会有这些关系：

这张图并不复杂，但它决定了后面很多事情：

• 权限应该按用户、项目还是组织隔离
• 评论是否需要冗余作者信息
• 任务状态是否应该建成枚举
• 项目删除时评论和附件怎么办

很多所谓“后期功能加不进去”的问题，本质上都不是页面写得不够灵活，而是底层数据模型一开始就没想清楚。

第五步：权限不是功能完成后再补的一层判断

我对很多小程序技术方案最大的警惕，是它们总喜欢把权限说成“后面再加”。

现实里，权限一旦后加，往往意味着两件事：

1. 你前面已经默认了大量“所有人都能看 / 都能改”的实现方式
2. 你后面每补一层权限，都得重新检查一遍原来的行为假设

这几乎注定会返工。

所以我做项目时，会很早写一张简化权限表。不是为了文档漂亮，而是为了强迫自己回答下面这些问题：

• 游客能看到什么
• 登录用户能创建什么
• 用户能不能修改别人数据
• 管理员权限是单独一套，还是建立在角色字段上
• 删除是真删、软删，还是状态流转

例如：

一旦这张表写出来，很多模糊问题就会自己浮出来。

如果你用的是 Supabase，这张表最后会直接映射成 RLS 策略；如果你用自建后端，它会落到中间件、service 层或者数据访问层。不管技术方案怎么变，权限设计本身都不能被省掉。

第六步：前端结构不需要炫技，但一定要给后续改动留门

小程序项目很容易因为“先跑起来”而走向另一种极端：所有东西都直接写进页面。

页面里发请求，页面里管 token，页面里写权限判断，页面里顺手做数据清洗。短期确实很快，长期几乎必然失控。

我后来对小程序前端结构的要求反而很朴素。它不需要有多高级，但必须有边界：

• 页面层只负责渲染和交互
• 请求层统一处理网络行为
• Auth 层统一处理登录态
• Store 只放真正跨页面共享的状态
• Config 集中管理环境和常量
• Utils 放纯函数，不偷塞业务流程

一个简单目录大概是这样：

miniprogram/
  pages/
  components/
  services/
    request.js
    auth.js
    project.js
  store/
  utils/
  config/

这个结构没有什么技术浪漫，但它非常实用。因为一旦你需要改登录模型、替换后端地址、加统一错误处理或者做埋点收口，就会庆幸自己没有把所有事情摊在页面里。

第七步：异常状态必须被当成正式需求

很多小程序项目有一个很常见的问题：成功路径设计得很完整，失败路径全靠用户理解。

页面正常时很好看，网络一抖、登录一掉、请求一慢，整套体验就开始露怯。

所以我现在看一个功能，除了 happy path，脑子里会默认检查这些状态：

• loading
• empty
• error
• retry
• no permission
• offline
• submitting
• submitted

听起来像常识，但真正做项目时最容易被忽略。

比如一个表单提交，至少要回答：

• 正在提交时按钮是否禁用
• 网络超时后用户看到什么
• 服务端校验失败后能否明确提示
• 登录态过期时流程如何恢复
• 成功后页面进入什么稳定状态

这些都不是“以后有时间再补”的细节，而是交付质量本身。

第八步：测试策略应该跟着风险走，不要跟着理想走

小程序从 0 到 1 不一定有很完整的测试体系，这很正常。问题不在于测试多不多，而在于最容易出事故的链路有没有被保护住。

我一般会把测试看成三层：

• 纯逻辑和校验：单元测试
• 核心接口行为：接口层验证
• 关键用户路径：E2E

如果时间有限，我不会平均分配精力，而是优先保护这几类东西：

• 登录态相关链路
• 核心提交链路
• 权限边界
• 文件上传
• 任何带交易或强业务后果的流程

测试策略真正需要回答的是：这次出了问题，哪一类 bug 代价最大？

不是所有功能都值得立刻铺满测试，但代价高的地方一定不能裸奔。

第九步：上线前不是“再看一遍功能”，而是做一次系统级回归

小程序最烦的地方之一，是很多问题开发环境和真机环境表现不一致。

所以我对“上线前回归”这件事看得很重。它不是机械点点页面，而是一次系统级确认：

• 真机行为和开发工具是否一致
• iOS / Android 是否都验证过
• 体验版是否完整走过核心路径
• 域名白名单是否覆盖全部依赖
• 登录、上传、下载、分享、支付这些关键能力是否都在正式环境验证过
• 用户协议、隐私政策、审核账号是否准备齐全

小程序上线前的回归，不应该只是 QA 的任务，它更像一次把前后端、平台约束和审核准备重新串起来的总检查。

很多事故不是技术不会，而是上线前没有任何人从头到尾走完一遍。

第十步：交付不是结束，真正的项目管理从这时才开始

一个小程序正式上线之后，你会很快发现：交付只是第一轮。

用户反馈、业务调整、审核变化、线上故障、性能瓶颈、权限争议、数据异常，这些东西都会在后面继续出现。真正决定这个项目能不能活下去的，往往不是第一版代码本身，而是它有没有留下可接手、可定位、可继续改的空间。

所以我现在做交付时，会刻意把这些内容一起交出去：

• 环境变量说明
• 数据表和权限说明
• 核心接口说明
• 部署与回滚方式
• 测试账号
• 常见问题排查入口

这些东西不直接产生新功能，但它们决定了项目后面是不是还能维护。

最后

从 0 到 1 交付一个小程序，说到底不是把页面都做完，也不是把接口都接上，而是尽早把那些真正会影响后续成本的问题回答掉。

技术决策的价值，从来不在于它听起来多先进，而在于它能不能帮你少走那些本来可以不走的弯路。