【经验分享】从0到1做一款知识学习小程序：日历跨度、实操工时与上线复盘

⏱ 预计阅读：15 分钟

之前文章里的“20 天”，只计算了服务器重新处理到小程序提交审核这一段，不是整个产品从 0 到 1 的总开发时间。这次补充完整口径后，项目资料可追溯的时间跨度是 2026 年 3 月 17 日到 8 月 7 日，约 144 个日历日；但这绝不等于 144 天全职开发。

这里需要把三种时间分开：文档或代码记录到的日历跨度、备案与审核等等待时间，以及实际坐在电脑前的投入工时。前两种可以从项目资料核对；数据整理、图片制作、UI 设计和各轮开发的真实投入工时没有留下完整工时记录，因此我明确留出待补项，后续由自己补充，避免把推测写成事实。

这次复盘的是一款知识学习小程序，包含资料查询、学习任务、自由复习和个人笔记等功能。为保护项目隐私，文中的产品名称、界面细节、域名和基础设施信息均已做匿名化处理。

图注：匿名化产品场景示意图，用于说明从产品开发到线上服务的衔接。

最大的感受是：从 0 到 1 不是只有“写代码”和“点发布”，数据、内容图片、UI、功能、测试、合规和上线缺一不可。本文记录的是实际过程和遇到的问题，不是通用教程；价格和平台规则会变化，但拆解方式可以复用。

1、先算清楚：完整 0 到 1 到底花了多久

先给出结论：我能从现有资料确认的，是一条从需求文档到审核提交的时间线；我不能确认的，是每个阶段究竟投入了多少小时。因此下面同时保留事实与空白项。

阶段	可核对的时间或产物	实际投入工时	说明
需求定义	2026-03-17 至 03-19 有版本记录	待补充：__ 小时	需求、场景与验收标准
架构与数据方案	2026-06-22 有高层、数据层、前端方案	待补充：__ 小时	数据模型、接口、页面改造方案
数据与内容图片	7 月测试快照：527 个知识条目 + 561 个配方条目；另有题库导入记录	待补充：__ 小时	来源筛选、清洗、分类、字段补齐、图文关联
UI 设计与资产整理	27 个正式页面、67 个状态分组、97 张设计稿；设计验收于 07-18 完成	待补充：__ 小时	用户路径、页面状态、视觉规范、设计资产
前后端与小程序开发	07-18 至 08-07 有连续代码记录	待补充：__ 小时	功能闭环、管理端、正式接口与兼容性
测试与修复	06-26、07-15、07-18 均有测试/设计验收记录	待补充：__ 小时	接口、页面、构建、真机及问题修复
服务器上线链路	日历跨度约 20 天	约 8-12 小时	部署、备案、HTTPS、联调与审核提交

可以确认的关键节点是：3 月已有需求版本记录；6 月完成技术与数据方案并跑过第一轮自动化测试；7 月完成 UI 设计验收与较大范围联调；8 月提交小程序审核。完整 0 到 1 的资料跨度约 144 天，真正的投入工时要等补齐个人时间账后才能计算。

建议以后每次做项目都用同一张表记账：日期、任务、投入小时、等待时间、产出物。这样复盘时不会把“备案等了两周”和“我开发了两周”混在一起。

2、数据与图片不是附件，而是产品本身

知识学习产品的第一版价值，不来自页面有多炫，而来自用户查到的内容是否足够、是否结构化、是否可持续维护。现有资料能确认的阶段性数据快照是：527 个核心知识条目、561 个配方条目；题库导入记录也显示，原始资料经过解析、筛选和去重后，才进入可用题目集。

这一段真正需要记的，不只是“导入了多少条”，还包括：

数据/素材任务	本次可确认的工作内容	实际投入工时
数据来源与授权核对	收集来源、明确可使用边界	待补充：__ 小时
字段清洗与标准化	名称去重、分类校验、字段补全、别名归一	待补充：__ 小时
结构化入库	将内容写入可查询、可关联、可维护的数据表	待补充：__ 小时
图片准备	图片筛选/生成、命名、压缩、与条目关联	待补充：__ 小时
题库处理	原始题目解析、过滤不安全或无效内容、去重和导入	待补充：__ 小时
上线前抽检	随机检查内容、图片、分类与详情页展示	待补充：__ 小时

这里有一个很现实的教训：“有数据”不等于“数据可用”。只有条目、分类、图片、来源与后台维护方式一起设计，内容才能从一次性演示资产变成持续可迭代的产品资产。

3、研发 S 系列 Skill：让 0 到 1 不靠临场发挥

这次开发过程中，我把 haonan 研发 S 系列 skill 作为研发流水线的骨架，而不是把它当作“帮我写一段代码”的孤立工具。它的意义是：每一阶段都明确输入、产出与验证方式，减少遗漏和返工。

研发阶段	本次对应的工作	关键产出
S000 项目编排	判断当前阶段、拆解依赖与并行关系	0 到 1 的任务链路与发布账本
S002 需求定义	明确目标用户、功能范围与验收条件	PRD、用户路径、验收标准
S003 原型/UI	组织信息架构、交互、页面与状态	页面设计、状态设计、素材规范
S004/S005 架构与详细设计	确定服务边界、数据模型、接口与前端状态	HLD、数据/后端/前端 LLD
S007/S008 任务与实现	将方案拆成可验证的原子任务并完成开发	可运行代码、接口与页面功能
S009/S011 测试与上线	测试、构建、部署、真机验证和审核提交	测试记录、正式服务与小程序审核版本

真正节省时间的不是“用了多少个 skill”，而是每一环都能知道下一步依赖什么、交付什么、怎么判断完成。数据、后端和前端在详细设计阶段可以并行；测试计划也不用等代码全写完才开始准备；上线时则按服务端与客户端两条发布面分别验证。

3.1 UI 设计和开发：先把体验定义清楚

UI 侧现有资料记录了 27 个正式页面、67 个状态分组和 97 张设计稿；设计验收记录还覆盖了 27 条路由、资源引用与 H5/小程序构建。它们说明这不是只画几个主页面，而是把加载、空状态、异常、答题反馈和真机路径一并设计和验证。

UI/开发任务	本次可确认的工作内容	实际投入工时
用户路径与信息架构	把资料查询、学习、复习、笔记等主路径串起来	待补充：__ 小时
页面与状态设计	27 个页面、67 个状态分组、97 张设计稿	待补充：__ 小时
视觉与图片资产	设计规范、素材映射、不同端资源适配	待补充：__ 小时
前后端功能开发	页面、接口、数据库、管理能力与正式请求链路	待补充：__ 小时
测试与修复	接口、11 个核心页面、构建和真机验证	待补充：__ 小时

设计稿不是开发前的“美化步骤”，而是把用户路径、异常状态和组件复用提前讲清楚。对独立开发尤其重要：越早固定关键体验，后面返工越少。

4、上线阶段：20 天到底花在哪里

为了不把“等待”误认为“开发很慢”，我把上线阶段再拆成两类。

环节	实操时间	等待/生效时间	本次结果
服务器部署与排错	约 3-4 小时	无固定等待	API、数据库、网页恢复可用
域名注册与解析	约 20-40 分钟	DNS 数分钟到数小时	www 和 api 子域名生效
ICP 备案	填写约 1-2 小时	本次约 2-3 周	网站备案完成
HTTPS 证书	约 1-2 小时	证书签发通常数分钟	API 可通过 HTTPS 访问
小程序联调	约 2-3 小时	无固定等待	真机请求正式 API
上传、提交审核	约 15-30 分钟	微信审核通常 1-7 天	已提交审核，待审核通过后发布

因此，这个“20 天”是项目从服务器处理开始，到提交微信审核的日历跨度；其中备案是最大的不可控变量。如果只看可控实操，第一次走通一条小程序上线链路，大约预留一个完整工作日会更现实。

5、第一步：部署服务，先确认程序真的活着

实操约 3-4 小时。我原来已经有一台云服务器，但服务器显示“运行中”，不代表项目已经能用。实际检查顺序是：SSH 登录服务器、启动 MySQL/Redis/API 容器、配置 Nginx（网页服务器）、再用 curl 验证接口。

curl https://api.your-app.example.com/api/herbs?pageSize=1

能返回中药数据，才说明“域名 -> Nginx -> API -> 数据库”真正走通。期间遇到的第一个坑是 Docker 拉取 node:22-alpine 失败，根因不是镜像名，而是镜像加速地址不可用；另一个坑是 80 端口已被宿主机 Nginx 占用。

一台服务器可以跑多个服务，但 80 和 443 端口只能有一个对外入口。最后保留宿主机 Nginx 做统一入口，再把请求转发给 Docker 内的 API。

6、第二步：注册域名与解析，给不同用途留入口

实操约 20-40 分钟，DNS 生效通常数分钟到数小时。注册域名后，建议把网页和接口提前分开：

用途	地址
H5 网页	www.your-app.example.com
后端 API	api.your-app.example.com
后续管理后台	可预留 admin.your-app.example.com

这些地址可以先指向同一台 ECS。这样做的价值不是形式，而是前端、接口、后台以后可以独立迁移或调整。解析完成后，先通过 ping 或 curl 验证，再进入下一步。

7、第三步：ICP备案，把最长等待放到最前面

填写约 1-2 小时，本次等待约 2-3 周。这是整条链路最慢的一环。提交前要准备主体资料，按平台提示填写网站信息，完成短信核验，再等待管局审核。

这里最容易搞混：小程序备案和网站 ICP 备案是两条流程，不能相互替代。网站备案用于将网站和接口按国内正式方式提供服务；小程序备案则是小程序账号的合规要求。

备案等待并不意味着停止开发。我的做法是并行完成小程序调试、真机测试、审核资料准备和 H5 小范围体验。尽早提交备案，等于给后续上线提前开时钟。

8、第四步：配置 HTTPS，小程序正式接口的硬门槛

实操约 1-2 小时。微信小程序正式请求线上接口时，不能使用 HTTP 或裸 IP，必须使用 HTTPS 域名。我最终使用：

https://api.your-app.example.com

服务器通过 Let's Encrypt 申请免费证书，再用 Certbot 自动写入 Nginx 配置。这里发生过一个很典型的系统环境问题：之前全局 pip 安装的 urllib3 覆盖了系统依赖，导致 Certbot 不能启动。卸载冲突的全局依赖、确认 certbot --version 正常后，证书才成功签发。

certbot --nginx -d api.your-app.example.com
curl https://api.your-app.example.com/api/herbs?pageSize=1

免费证书不等于永远不用管，而是证书免费、需要按有效期自动续签。本次已由 Certbot 设置自动续期，仍建议以后定期检查。

9、第五步：小程序联调，把正式地址带进真机

实操约 2-3 小时。这一步要在微信公众平台配置 https://api.your-app.example.com 为 request 合法域名，然后用正式 API 地址重新构建小程序，再在微信开发者工具和真机上测试。

VITE_API_BASE_URL=https://api.your-app.example.com npm run build:mp-weixin

重点不是只看首页能不能打开，而是按真实用户路径走一遍：首页、资料查询、学习任务、复习、笔记，以及网络异常时的提示。H5 内测可以临时使用 HTTP/IP，但小程序正式联调必须回到 HTTPS 域名。

10、第六步：上传、审核与发布，三个状态不要混淆

提交实操约 15-30 分钟，微信审核通常等待 1-7 天。微信开发者工具提示“代码上传成功”，只表示代码已进入微信后台；接下来还要在公众平台填写版本描述、测试说明、隐私设置等资料，提交审核。

正确顺序是：

上传代码 -> 提交审核 -> 审核通过 -> 手动发布

上传成功不等于已经上线；审核通过后手动点击“发布”，用户才可以正式使用线上版本。本文撰写时，版本已经处于审核阶段。

11、给第一次上线的小白：哪些强依赖，哪些可以并行

上线最容易浪费时间的原因，不是某一步太难，而是把本来能同时做的事情排成了串行。我的经验是，把所有事情拆成“强依赖”和“可并行”两类。

11.1 必须按顺序完成的强依赖

下面这些步骤不能跳过前置条件：

服务器与 API 可用
  -> 域名解析到服务器
  -> HTTPS 证书签发并验证接口
  -> 微信后台配置 request 合法域名
  -> 用 HTTPS API 重新构建小程序
  -> 真机调试
  -> 上传代码、提交审核
  -> 审核通过后手动发布

原因很具体：

1. 先有可访问的服务器和 API，域名才有目标可解析。服务器没跑通，先买证书或配置微信后台都无法验证。
2. 域名解析生效后，HTTPS 证书才能验证域名归属。证书机构需要确认这个域名确实指向你的服务器。
3. HTTPS 接口正常后，才能添加微信 request 合法域名。微信小程序不接受 HTTP 或 IP 作为正式请求地址。
4. 微信后台域名配置完成后，必须用正式 HTTPS 地址重新构建。否则包里仍然写着旧 IP 或 HTTP 地址，真机请求仍会失败。
5. 真机调试通过后再上传审核。开发者工具里能跑，不代表手机网络和微信域名校验一定能通过。
6. 审核通过后仍需手动发布。“上传成功”和“审核通过”都不是最终线上状态。

这条链路里，HTTPS 是最关键的闸门：它前面依赖域名解析，后面影响微信合法域名、真机测试和审核提交。

11.2 可以提前并行的工作

下面这些不必等待前一个环节完全结束，可以同时推进：

主线任务	可以并行做什么	为什么可以并行
服务器部署与排错	本地功能开发、H5 小范围测试	不依赖正式域名，先验证产品本身是否值得继续做
域名实名认证与备案	小程序页面开发、接口联调、审核资料准备	备案是等待最长的环节，没必要让开发停下来
ICP 备案审核中	准备隐私政策、版本描述、测试说明、产品截图	这些资料提交审核时必需，且不依赖备案结果
HTTPS 配置完成后	微信后台添加合法域名、重新构建、真机测试	三件事可连续推进，不需要再等待备案审核结束
小程序审核中	继续修复非核心问题、准备内测反馈表、整理客服联系方式	已提交的版本不要随意改动；新改动留在开发版准备下一版

这次最应该前置的两件事是：一拿到域名就做实名认证和备案；备案等待期间，把小程序正式接口切换、真机测试和审核资料全部准备好。这样备案一通过，就不会再额外等一轮。

11.3 一套更省等待时间的排期方式

如果从零开始，我会这样安排：

1. 第 1 天：本地调通核心功能，同时购买域名并完成实名认证。
2. 第 1-2 天：部署服务器、拉起数据库和 API，先通过 IP/H5 验证最小链路。
3. 第 2 天：域名解析后立刻提交 ICP 备案；从这里开始进入等待期。
4. 备案等待期：完成 HTTPS、微信后台资料、隐私设置、产品截图、版本描述和真机问题修复。
5. 备案通过后：最终确认 HTTPS API、合法域名、真机测试，上传并提交审核。
6. 微信审核期：保持接口稳定，准备内测反馈与下一版迭代；审核通过后手动发布。

早期为了低成本试错，H5、API 和数据库共用一台 ECS 是合理选择。等用户量和访问量上来，再考虑管理后台拆分、监控、备份与高可用。先走通“能用、能验证、能迭代”的最短路径，比一开始追求复杂架构更重要。

12、上线之后，才开始验证产品是否成立

技术上线只是把产品交到用户手里，真正的验证才刚开始。对这款学习工具而言，更重要的问题是：用户会不会连续使用？学习与复习的过程有没有变轻松？用户愿不愿意推荐给同学？

下一阶段我会先做小范围内测，重点收集哪些页面最常用、哪一步最容易卡住、哪些内容值得补齐。先确认产品是否解决真实学习问题，再决定下一阶段投入多少开发成本。

本期一句话：独立开发者第一次上线，最重要的不是把架构做得多复杂，而是把“能用、能验证、能迭代”的最短路径走通。

你第一次把产品推到线上时，卡在了技术、备案、审核，还是用户反馈？欢迎交流。