微信小程序从零开发到上线：原生框架+云开发完整实践

先说结论：用微信原生框架从零开始写一个能正常上线的小程序，没有想象中那么玄乎，但也不会像看几分钟视频就能马上搞定那么容易。这篇文章我想用一个名字叫 WorkBuddy 的“工作辅助小程序”当例子，把从注册账号、安装开发者工具、创建第一个页面、接上云数据库，到最后上传代码、提审上线的完整流程，一五一十讲清楚。不管你是刚接触小程序开发，还是之前只用网页或者脚本写过一些工具，只要愿意动手跟着做，基本上都能把一个能用的版本跑起来，而且做完之后心里的整个链路会清晰很多。

WorkBuddy 这个名字没什么花头，就是 Work（干活）+ Buddy（搭档）。它的定位是一个帮上班族或自由职业者打理日常任务的工作台：列待办、记工时、做简单的工作复盘。这类工具很适合当第一个小程序项目，因为功能直观、数据模型简单，但又覆盖了小程序开发最核心的几条赛道：页面结构、列表渲染、事件交互、数据存储、发布流程。跟着做一遍，相当于把一段完整的产品闭环走了一遍。下文里我会尽量按照实际操作顺序来讲，遇到关键步骤会解释为什么这么做，而不是只让你复制粘贴。

1. 动手之前：WorkBuddy 要做成什么，先想清楚再动手

很多新手拿到小程序项目就急着写代码，这是最大的坑。我先展开说说 WorkBuddy 的功能边界和整体技术选型，这两件事决定了后面写代码的时候会不会反复返工。

1.1 功能定型和范围控制：MVP 怎么切分

WorkBuddy 面向的是日常工作场景，如果一开始就把什么日历、周报、多人协作、消息提醒全塞进去，那估计一个月都开发不完。做第一版的时候，我建议只保留三个核心模块：

• 待办管理：能新增待办事项、标记完成、删除已完成事项
• 工作记录：记录当天的工作任务和实际耗时，简单做一条一列的数据
• 数据看板：统计今日完成数量、待办总数、累计工时，用一个页面展示

这个范围看起来小，但它已经能用“真实的业务逻辑”把整个小程序串起来：首页是待办列表，第二个页面是工作记录的填写和列表，第三个页面是数据和设置。三个页面之间的数据流是一致的，不存在逻辑冲突，非常适合当一个全流程范例。如果后面想扩展，比如加登录体系、加多人共享清单，也都是在现有数据模型上加字段，不会推倒重来。

我还想强调一个原则：第一版不要碰支付，不要碰客服消息，不要碰用户身份绑定这些“看起来不难但实际很重”的能力。小程序里有些能力是“能用”和“能上线”两回事，比如用户隐私相关接口，审核的时候要求非常多。WorkBuddy 第一版就把所有数据存储放在本地缓存和云开发数据库，不上任何实名认证，体验链路完整，门槛也低。

1.2 技术选型：为什么选原生框架加云开发

小程序开发有几种常见路线：微信原生框架、第三方跨端框架（如 Taro、uni-app）、纯 Web 套壳。我的建议是，如果以“学会小程序开发底层逻辑”为目标，必须以微信原生框架为主。原因很简单：原生框架的 WXML、WXSS、JS、JSON 四件套是官方定义的，所有功能官方文档都有对应说明，出了问题社区也比较容易搜到。第三方跨端框架虽然一套代码能同时出小程序和 App，但它多了一层编译转换，遇到边界问题排查成本反而更高。WorkBuddy 这个项目没有多端需求，用原生最直接。

后端部分，我选了微信云开发。这个决定主要是想省掉一台服务器和域名备案的麻烦。云开发提供云数据库、云函数、云存储，对小程序项目来说，等于在微信的体系内直接拿到了一个后端底座。开发者不需要自己购买云主机、配置 Nginx、搭 HTTPS 证书，也不需要处理跨域，因为云开发和小程序之间天然联通。对小项目来说，云开发还提供有免费额度，WorkBuddy 这种量级的个人工具基本够用。就算以后用户量大了，再平滑去接自己的后端服务也不冲突，因为业务逻辑都在前端，替换起来只是改数据请求层而已。

2. 环境准备三件套：账号、开发者工具、项目初始化

这一节属于纯粹的“磨刀不误砍柴工”。很多人会在这一步卡住，大部分问题是注册信息对不上、工具版本选错、项目模板误选。我按顺序拆开讲。

2.1 注册小程序账号并拿到 AppID

打开微信公众平台，点击右上角的“立即注册”，选择“小程序”类型。这里有个细节：如果你已经有微信公众号账号，不建议用公众号里的“小程序”入口直接创建，因为主体关联复杂，个人开发时非常容易把管理员信息绑定错。最好重新用邮箱注册一个小程序账号。

注册流程按系统提示走就行，重点注意几个信息：

• 邮箱必须没注册过公众号或小程序
• 主体类型建议先选“个人”，审核流程简单、不用对公账户打款验证
• 平台会要求绑定管理员微信，这个管理员就是以后唯一能扫码登录后台的人，别随便绑

注册完成后，进入小程序后台，在“开发管理”的“开发设置”里能看到一串 AppID，形如wx1234567890abcdef。这串东西相当于小程序在微信体系里的身份证，后面创建项目必须用到。注意还有一个叫“AppSecret”的东西，它主要给服务端 API 调用用，前端代码里永远不要写 AppSecret，否则等于把整个后台钥匙直接暴露出去。

2.2 安装开发者工具并创建第一个空白项目

微信开发者工具是日常开发的入口，直接在官网下载稳定版即可。安装的时候有个小建议：Windows 系统尽量选默认安装路径，因为工具内置了一些调试相关组件，路径有中文或者空格偶尔会触发无法解释的报错。

打开工具，用管理员微信扫码登录。然后选择“小程序项目”，项目名称填 WorkBuddy，目录选一个专门放代码的文件夹，AppID 就填刚才注册拿到的那个，后端服务选“不使用云服务”或者“使用云开发”都可以，因为即使现在选“不使用”，后边也能手动开通。模板那里关键一步：不要选任何现成模板，直接选“不使用模板”或者“空白目录”。

创建完成后，你会看到一个满屏的欢迎页和一堆文件。很多人第一次会懵，我先讲一下原生小程序的标准目录结构，这在后面写代码时会反复使用：

• app.js：小程序逻辑入口，注册应用实例，适合放全局数据和生命周期方法
• app.json：全局配置，包括页面路径、窗口样式、导航栏、TabBar
• app.wxss：全局样式，所有页面都会继承这份样式
• pages/目录：每个页面一个文件夹，里面包含.wxml、.wxss、.js、.json四个同名文件
• project.config.json：项目配置，记录 AppID 和工具设置

WorkBuddy 我准备做三个页面，在pages/index（待办主页）、pages/task（工作记录页）、pages/profile（数据看板与设置页）之间切换。新建页面的方式有两种，一种是在pages目录右键新建 Page，工具会自动生成四个文件；另一种是在app.json的pages字段里手动加一行路径后保存，工具也会自动补齐文件。第二种更贴近实际开发节奏，后边我讲配置时会用到。

注意：小程序里app.json的pages数组第一项就是启动页，WorkBuddy 的首页必须写在第一行，否则每次启动可能落在别的页面。

3. 从空白目录到工作台页面：全局配置和首页交互

环境搭好之后，真正的开发流程开始了。这一节先解决“项目长什么样”和“首页怎么交互”这两个问题，代码不多，但要把逻辑理顺。

3.1 全局配置：导航条、TabBar 和页面注册

打开app.json，这是一个 JSON 文件，里面的字段直接决定小程序壳子的行为。WorkBuddy 有三个 Tab 页面，所以底下需要一个 TabBar，让用户能一键切换。我给出一份可以直接用的配置：

{ "pages": [ "pages/index/index", "pages/task/task", "pages/profile/profile" ], "window": { "backgroundTextStyle": "light", "navigationBarBackgroundColor": "#2F54EB", "navigationBarTitleText": "WorkBuddy 工作台", "navigationBarTextStyle": "white" }, "tabBar": { "color": "#999999", "selectedColor": "#2F54EB", "backgroundColor": "#ffffff", "borderStyle": "black", "list": [ { "pagePath": "pages/index/index", "text": "待办" }, { "pagePath": "pages/task/task", "text": "记录" }, { "pagePath": "pages/profile/profile", "text": "我的" } ] } }

这段配置里的小细节挺多。pages数组里的路径不能写.wxml后缀，只写页面目录名。tabBar.list最少 2 项、最多 5 项，顺序决定了显示顺序。TabBar 也可以配iconPath和selectedIconPath，但图片素材这版本可以不加，因为如果图标没有及时准备，工具会直接报编译错误。用纯文字 TabBar 不影响正常使用，等以后设计稿出来再补图标就行。导航栏标题色和背景色我用了一套偏商务的蓝，这个大家按自己喜好定，但注意navigationBarTextStyle只有white和black两个值，浅色背景必须配black，深色背景配white，否则字会看不清。

保存之后，工具会自动编译，左侧模拟器里会出现一个带三个 Tab 的小程序外壳。如果页面对应目录还没生成文件，工具会在控制台提示找不到页面，所以接下来要顺手把三个空页面建出来。我习惯先在app.json里写好路径再保存，让工具自动生成文件，这样连新建 Page 那步都省了。

3.2 首页待办列表：数据绑定、事件处理和输入框

首页是 WorkBuddy 的门面，用来列待办事项。一个待办项最简单的数据结构只需要三个字段：id、title、done。id用来标记唯一身份，title是任务描述，done是个布尔值，表示是否已完成。首页功能我给三个：添加任务、勾选完成/取消、删除已完成任务。

先看pages/index/index.wxml，这里用wx:for实现列表渲染，每行渲染一条待办：

<view class="page"> <view class="input-row"> <input placeholder="输入待办事项" value="{{inputValue}}" bindinput="onInput" confirm-type="done" bindconfirm="addTodo" /> <button size="mini" type="primary" bindtap="addTodo">添加</button> </view> <view class="todo-list"> <view wx:for="{{todos}}" wx:key="id" class="todo-item {{item.done ? 'done' : ''}}"> <checkbox checked="{{item.done}}">Page({ data: { todos: [], inputValue: '' }, onInput(e) { this.setData({ inputValue: e.detail.value }); }, addTodo() { const title = this.data.inputValue.trim(); if (!title) { wx.showToast({ title: '内容不能为空', icon: 'none' }); return; } const todos = this.data.todos.concat({ id: Date.now(), title: title, done: false }); this.setData({ todos, inputValue: '' }); }, toggleTodo(e) { const index = e.currentTarget.dataset.index; const todos = this.data.todos; todos[index].done = !todos[index].done; this.setData({ todos }); }, deleteTodo(e) { const index = e.currentTarget.dataset.index; const todos = this.data.todos; todos.splice(index, 1); this.setData({ todos }); } });

这里有一个新手高频踩坑点：在小程序里直接修改this.data.todos[index]后再调用this.setData({ todos })是可以生效的，但在更复杂的数据结构里容易出问题，因为setData的对比过程不一定能正确识别深层变化。更稳的做法是复制一份新数组再操作：

const todos = [...this.data.todos]; todos.splice(index, 1); this.setData({ todos });

用这个写法，每步操作都在新数组上完成，避免踩到setData对深层数据监听不一致的坑。另外wx:for的每一项一定要有wx:key，并且key必须是项目里唯一且稳定的值，这里用的id正好符合。如果不写wx:key，控制台会有警告；如果这个列表未来会支持拖拽排序或复杂更新，没有稳定key甚至会导致渲染错乱。

4. 把数据留住：本地缓存到云开发数据库

首页现在能用，但一关掉小程序，数据全没了，因为数据只存在内存里。这一节解决数据持久化的问题。我先说本地缓存，因为对一个小工具而言，本地缓存是最快、最稳定、零成本的方式；然后再引出云开发，这样数据能跨设备同步，也为以后多端使用留好能力。

4.1 本地缓存：用 Storage 保住新增和修改

微信小程序提供了wx.setStorageSync和wx.getStorageSync两组接口，用于同步读写本地缓存。这两组接口底层就是 Key-Value 存储，容量上限单条 1MB，WorkBuddy 的待办列表和记录列表完全够用。用法特别简单，在addTodo、toggleTodo、deleteTodo三个方法里分别加上一行：

wx.setStorageSync('todos', todos);

然后在页面的onLoad生命周期里读取缓存并初始化：

onLoad() { const todos = wx.getStorageSync('todos') || []; this.setData({ todos }); }

这里有一点非常关键：onLoad只在页面第一次加载时执行一次，后续如果从别的页面跳转回来，不会再执行。WorkBuddy 的 Tab 页面默认是留在内存里的，从“记录”切回“待办”时，不会触发onLoad。所以如果数据在“记录”页被改动了，回“待办”页时要保证数据最新，通常的做法是在onShow里重新拉取缓存：

onShow() { const todos = wx.getStorageSync('todos') || []; this.setData({ todos }); }

用onShow的好处是每次页面重新显示都会执行，这样能保证页面间的数据同步。逻辑上等于每次切回首页都“刷新一次”，这个小细节能让用户体验明显提升。

4.2 云开发：集合设计、数据库权限与云函数

本地缓存够用，但不支持多设备同步，也不方便以后做数据分析。所以 WorkBuddy 第二版开始接云开发，这一步能学到的知识也更接近真实商业项目。

在开发者工具里点击“云开发”按钮，开通环境。这里的“环境”相当于一个独立的隔离环境，每个环境里有自己的数据库、存储和云函数。开发环境和生产环境最好分开，但 WorkBuddy 第一版只开一个环境就够了，毕竟核心是跑通流程。

云开发数据库是一种文档型数据库，类似 MongoDB 的用法。数据以“集合”为单位组织，WorkBuddy 只需要建一个集合，名字叫todos。每个待办记录就是集合里的一条文档，文档可以理解成一个 JSON 对象。我设计的待办文档结构是：

{ "_id": "自动生成", "title": "整理项目周报", "done": false, "createTime": 1700000000000, "updateTime": 1700000000000 }

_id是文档唯一标识，不需要自己传，插入数据时后端会自动生成。createTime和updateTime我建议主动写入，因为后面做统计排序时一定要用到时间字段。如果不在写入时存时间，后面就没有任何方式可以找回“这条任务是什么时候创建的”，这一点经常被漏掉。

数据库权限这里要特别小心。在云开发控制台里，每个集合的权限默认是“仅创建者可读写”，如果想做到“用户不需要登录也能在全网数据里读写”，这不是一步改权限就能解决的。WorkBuddy 第一版没有做登录体系，最省事的做法是让前端直接用wx.cloud.database()操作集合，但这要求数据权限设置为“所有用户可读，仅创建者可读写”之类的宽泛规则。安全上更稳妥的做法是通过云函数来操作数据库，这样前端不直接暴露数据库读写权限。虽然 WorkBuddy 的演示属性比较强，但我还是强烈建议走云函数这条路，因为实际项目里这是主流做法，也能避免将来上线后被扫描接口薅数据。

云函数本质是一个运行在云端的 Node.js 函数。在开发者工具里右键cloudfunctions目录，新建云函数，名字叫addTodo，然后修改入口文件index.js：

const cloud = require('wx-server-sdk'); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }); const db = cloud.database(); exports.main = async (event) => { const { title } = event; if (!title) return { code: 1, msg: '缺少title' }; const res = await db.collection('todos').add({ data: { title, done: false, createTime: Date.now(), updateTime: Date.now() } }); return { code: 0, data: res._id }; };

然后在每个云函数目录上右键选择“上传并部署：云端安装依赖”，云函数才能在小程序里被调用。前端调用云函数的代码：

wx.cloud.callFunction({ name: 'addTodo', data: { title }, success: (res) => { console.log('新增结果', res.result); } });

加了云函数之后，前端代码量会多一点，但数据安全性和架构清晰度都上来了。WorkBuddy 的架构最后变成这样：前端页面展示状态 → 事件触发 → 调用云函数 → 云函数访问云数据库 → 返回结果 → 前端重新拉取列表。链路虽然比本地缓存长，但每一步都看得懂，出了问题就能单独排查。

5. 记录页和统计页：把多个页面串成完整闭环

首页解决完待办列表，WorkBuddy 还需要一个“工作记录”页面和一个“数据看板”页面，这才像一个工具型小程序。

5.1 工作记录页：表单输入和记录列表

工作记录页用来提交“今天做了什么事，花了多少时间”。操作流程是：用户输入工作描述、选择耗时分钟数、点击保存，记录会出现在下方的历史记录列表里。表单页用.wxml写两个控件，一个输入框，一个 slider 滑块：

<view class="page"> <view class="form-card"> <view class="field-label">工作内容</view> <input placeholder="例如：整理需求文档" value="{{workDesc}}" bindinput="onDescInput" /> <view class="field-label">耗时：{{minutes}} 分钟</view> <slider min="5" max="120" step="5" value="{{minutes}}" bindchange="onMinutesChange" show-value /> <button type="primary" bindtap="saveRecord">保存记录</button> </view> <view class="record-list"> <view wx:for="{{records}}" wx:key="id" class="record-item"> <text>{{item.desc}}</text> <text>{{item.minutes}} 分钟</text> </view> </view> </view>

页面数据里维护workDesc、minutes、records三个字段。保存的时候构造一条新记录，追加到records数组，同时写入缓存。和首页待办的处理方式一致，最好把读写逻辑抽出一个通用的数据服务层，不让每个页面都直接拼wx.getStorageSync。虽然 WorkBuddy 的代码量还不算大，但有了数据层之后，页面代码会干净很多，后面接云开发也只需要改数据层一个文件。这个习惯越早形成越有益。

工作记录页还有一个可加可不加的能力：每天第一次打开时自动显示当前日期，作为记录的分类维度。实现不难，在onShow里取一下系统时间并格式化即可。不要小看这个“日期”字段，后续统计“今天完成多少”“本周工时”都依赖它，没有日期，数据看板根本无从做起。

5.2 数据看板：统计和展示本地数据

“我的”页面要承担两个职责：展示今日完成情况和提供基础设置入口。WorkBuddy 的统计逻辑可以做成：

• 待办总数：todos.length
• 已完成数量：todos.filter(item => item.done).length
• 今日新增记录数量：按createTime筛选当天的记录数
• 今日投入总分钟数：按日期筛选后累加minutes

这些统计在数据量比较小的时候，直接在前端用 JavaScript 的filter和reduce计算就行，不需要数据库做聚合查询。比如今天的完成数：

const now = new Date(); const todayStart = new Date(now.getFullYear(), now.getMonth(), now.getDate()).getTime(); const todayEnd = todayStart + 24 * 60 * 60 * 1000; const todayRecords = records.filter(item => { return item.createTime >= todayStart && item.createTime < todayEnd; }); const totalMinutes = todayRecords.reduce((sum, item) => sum + item.minutes, 0);

这里有个时间戳细节：Date.now()返回的是毫秒级时间戳，而24 * 60 * 60 * 1000是一天的毫秒数。很多新手在统计“当天”数据时会把起始边界算错，导致统计结果看起来少了一天。调试方法也很简单，把开始和结束时间戳console.log出来，放进时间戳转换工具里确认边界，基本能避免这类问题。

数据看板的展示形式不建议搞复杂的图表，小程序里画图表需要额外引用第三方库，对项目体积和调试都有影响。直接用数字卡片排列展示就好，简洁、加载快，也不容易出兼容性问题。第一版的目标永远是先把核心流程跑通，而不是引入一堆华丽但在当前阶段用不上的依赖。

6. 模拟器调试到真机发布：从关卡到真正上线

代码写到这里，WorkBuddy 的核心功能已经完整了。接下来这个阶段是很多教程一笔带过但其实最容易翻车的部分：怎么从“能跑”到“能上线”。这里面的坑多为环境问题、权限问题和编译缓存问题。

6.1 模拟器调试：必须盯住的几个检查点

我把.wxml、.wxss、.js、.json四类文件在调试时的重点分开来说，因为对应到不同的问题排查思路。

.wxml文件里最常见的问题就是路径写错、组件名拼写错误、数据绑定字段名大小写不一致。开发者工具的调试器里有一个“WXML”面板，点它可以看到页面的真实渲染树。如果页面空白但控制台没有报错，优先打开 WXML 面板，看看是不是wx:if把整个内容拦掉了。

.wxss文件要注意小程序里默认的单位是rpx，不是px。rpx是响应式像素，以屏幕宽度 750 为基准来换算，能自动适配不同宽度的手机。如果拿网页开发的px习惯直接写死，在 iPhone 全面屏和安卓手机之间会出现明显的布局错位。WorkBuddy 里按钮高度、列表内边距这些地方我全部用rpx，只在边框粗细这种必须精确的地方用px。

.js文件的调试主要集中在数据变化是否符合预期。模拟器里选中某个页面组件，可以在 Console 里通过getApp()拿到全局对象，配合打印this.data可以实时观察数据状态。如果你的页面数据更新了但视图没变，第一反应检查setData的 key 路径，确认没有在对象里新增了未初始化的字段。

.json文件配置的坑多数在页面级配置覆盖全局配置时。比如navigationBarTitleText在全局已经设置了“WorkBuddy 工作台”，但在某个页面的.json里又写了别的标题，那这个页面上的标题就会局部覆盖全局值。这类问题在视觉上很明显，但新手容易以为是 bug，其实是优先级规则在起作用。

6.2 真机预览、体验版和提审上线

模拟器上一切正常，和真机上正常是两码事。模拟器在开发者工具里渲染方式和微信客户端内实际渲染逻辑有细微差别，尤其是输入框、滑块这些原生组件。所以无论如何都要养成的习惯是：每个里程碑节点都做一次真机预览。

点击工具栏里的“预览”按钮，会生成一个临时预览二维码。用微信扫码后，就能在手机微信里打开当前代码的小程序。真机预览有一个限制：临时二维码只对当前开发者微信有效，有效期大约 25 分钟，只适合自己调试，不适合发给别人测试。

要让别人也能体验，需要把代码上传。在工具右上角点击“上传”，填好版本号和备注，版本号按0.1.0这种语义化方式去写。回到小程序后台的“版本管理”，会看到刚才上传的版本。点击“设为体验版”，再把体验版二维码发给同事或朋友，他们就能以“体验成员”身份使用这个版本。注意，体验成员需要我们提前在后台“成员管理”里添加微信号，这一步经常被忽略，导致别人扫码后显示无权限，其实就是没把对方加到体验成员列表。

最后一步是提审上线。在版本管理里选择体验版本，点击“提交审核”。提交时要选择类目，WorkBuddy 属于“工具-效率”，选一个符合的类目即可。审核通常需要一两天，期间别闲着，可以顺手准备一下应用截图和隐私说明。特别是涉及到收集用户录入的内容（即使只是文字），现在平台要求补充隐私保护指引，需要在后台的“设置-用户隐私保护指引”里填写，否则审核会被驳回。我第一次提交这类工具小程序时就因为漏了隐私指引被驳回过一次，驳回原因写得很清楚，按提示补上基本上都能过。

关键经验：审核驳回不可怕，怕的是反复提交不检查。每次驳回通知里都把违规原因和需要修改的点列得很清楚，严格按照提示修完、上传新版本，再走一遍提交审核即可。

7. 开发中必踩的坑：WorkBuddy 高频问题清单

这些问题是基于实际开发中高频出现的问题，我整理成一个速查表，方便大家对照自查：

以上每一条都是实际开发中会反复碰到的场景，WorkBuddy 从零到能拿到体验版，至少会踩到其中三四条。提前把这些问题理清楚，后面遇到时就不会浪费时间瞎折腾。

8. 项目还能怎么扩展：从 WorkBuddy 到你自己的产品

WorkBuddy 做完之后，它不是终点，而是一个可扩展的起点。很多开发者第一次完成项目后，会在心里产生“我这是不是太简单了”的疑问。我的看法是，只要它完整走完了从注册到发布的全链路，且没有明显逻辑错误，这个项目就已经具备了继续迭代的基础。

最容易加的扩展点是用户体系。接入微信的wx.login，拿到用户的唯一标识，然后把它作为每条待办、每条记录的ownerId。这样不同用户登录后看到的就是自己的数据，多人数据不会互相污染。在云开发里这一步已经比较成熟，本质上就是在查询条件里加上openid过滤，不需要额外引入大型后端框架。

另一个有意思的扩展方向是给数据增加“标签”能力。比如 WorkBuddy 里记录的工作项可以打上“开会”“写代码”“沟通”这些标签，然后统计页按标签维度展示工时分布。数据模型上只是多一个tags数组字段，页面里加一个标签选择器，画布上如果要用图表，可以引入小程序版的图表库，不过记得控制包体大小。

第三个方向是和微信消息订阅能力结合，做一个“每日提醒”。用户订阅了待办提醒后，云函数定时触发，通过订阅消息推送给用户。这个能力对工具类小程序有显著加持效果，但会涉及用户授权和消息模板配置，复杂度比前一节的功能上了一个台阶。等 WorkBuddy 的本地流程已经玩熟，再考虑这块即可。

WorkBuddy 这个项目，规模不大，但五脏俱全：有页面交互、有本地数据、有云端能力、有完整的发布链路。拿它练完手，再去研究商业级小程序的框架设计、组件封装、自动部署这些高级话题，就会觉得基础没有白费。如果你想做一个自己的小工具，照着这条从 0 到 1 的路重新走一遍，很快就能跑出第一个可以给别人用的版本。