企业官网建设流程全解析

微信小程序开发这事，我前前后后带过不少人从零起步。很多朋友一开口就是“我想做个小程序”，但真要动手时，连开发者工具和微信App的关系都分不清，更别提云开发、组件生命周期这些概念了。正好手上刚完成了一个名为WorkBuddy的效率工具类小程序，从注册账号到真机发布全流程走了一遍。这篇教程就把这次实践从头到尾拆开来讲，每一步都写清楚为什么这么做、代码怎么写、坑在哪，给想自己动手做一款小程序的朋友一份能直接照着做的完整参考。

WorkBuddy这个项目，定位是个人任务与待办管理工具，核心功能包括任务列表、分类筛选、进度标记和简单的数据统计。选它作为教学案例，是因为它麻雀虽小五脏俱全，既有页面跳转、数据渲染，又涉及本地存储和云函数，正好覆盖小程序开发的所有关键环节。无论你是刚学编程的学生，还是想做个工具解决自己实际需求的职场人，都能靠这篇内容把一条完整链路跑通。

1. 项目规划与技术选型

1.1 先把需求想清楚，再谈怎么写代码

我见过太多人一上来就打开开发者工具写页面，结果写到一半发现数据不知道放哪、页面之间怎么传参搞不明白，返工成本极高。做WorkBuddy之前，我先在纸上把功能边界划清楚了：用户能创建任务、标记完成、按分类筛选、查看今日待办数量。不做账号体系，不做团队协作，不搞消息推送。砍掉这些功能不是偷懒，而是因为微信小程序冷启动时，任何多余的功能都会变成学习路上的拦路虎。

明确需求后，要拆解成数据模型。WorkBuddy的核心数据就是任务，那任务应该有哪些字段？我的设计如下：id（唯一标识）、title（标题）、category（分类）、done（是否完成）、createTime（创建时间）。分类暂时用固定值：工作、生活、学习。这套字段基本覆盖了待办工具的常见场景，也为后续加云同步留了扩展空间。

1.2 选原生还是选框架，关键看你的目标

微信小程序开发有原生、uni-app、Taro等几种主要路径，很多新手在这里就开始纠结。我的建议很直接：如果是第一次做小程序，且目标是理解小程序本身的机制，就用原生。虽然原生写起来啰嗦一点，但它能让你看清页面逻辑、生命周期、组件通信这些底层的运作方式。用框架虽然写起来舒服，但遇到问题你很难分清是框架的锅还是微信的锅。

WorkBuddy就选了原生开发，搭配微信的云开发能力。云开发是微信提供的一套后端方案，它能免去自己买服务器、配域名、做HTTPS证书这一堆运维工作。对小工具类项目来说，云开发的免费额度足够个人项目跑很久，成本上几乎为零。这里做一个简单对比：

WorkBuddy选择原生加云开发，因为我们需要数据同步能力，但又不希望被服务器运维拖住手脚。这个选型逻辑对99%的个人小程序项目都是适用的。

2. 环境搭建与初始化

2.1 账号注册和AppID申请

开发小程序第一步不是装软件，而是去微信公众平台注册小程序账号。这里有个容易忽略的细节：个人主体的小程序很多能力是受限的，比如微信支付、部分类目审核，但对WorkBuddy这种工具类应用来说，个人主体完全够用。注册流程网上到处都是，我只提醒三个关键点：

• 邮箱必须没用过微信公众号或个人微信号，需要接收激活邮件。
• 主体类型选“个人”，不要选企业，否则要营业执照，审核周期也完全不同。
• 注册完成后，在“开发管理-开发设置”里找到AppID，这串字符相当于小程序在微信世界的身份证，后面处处要用。

拿到AppID后，去微信开发者官网下载对应系统的开发者工具。安装过程没什么坑，唯一要注意的是登录时用微信扫码，不要用账号密码登录，否则偶尔会提示登录过期。

2.2 创建项目和目录结构理解

打开开发者工具，选择“小程序项目”，填入AppID，项目名称填WorkBuddy，模板选“不使用模板”或“JavaScript基础模板”都行。Framework我们选JavaScript，TypeScript虽然类型安全更好，但对新手多了一层编译概念，先不引入。

创建完项目后，你会看到一堆文件。很多初学者看到这些文件直接懵了，其实核心就五个角色：

• app.js：小程序入口逻辑，可以理解成项目的大脑，负责全局数据、启动时的初始化。
• app.json：全局配置，包括所有页面的注册、窗口样式的设置、导航栏标题等。
• app.wxss：全局样式，定义通用的样式类，供所有页面复用。
• pages/：存放页面文件，每个页面是一个文件夹，内部包含.js（逻辑）、.wxml（结构）、.wxss（样式）、.json（页面配置）四个文件。
• project.config.json：项目工具配置，比如AppID、编译设置。

一个值得新手牢记的原则是：页面要想能被跳转访问，必须先在app.json的pages数组里注册。如果漏掉注册，即使文件都在，运行时也会报错。WorkBuddy的页面结构规划为三个：首页（任务列表）、详情页（任务编辑）、统计页（完成率概览）。

在app.json里做如下设置：

{ "pages": [ "pages/index/index", "pages/detail/detail", "pages/stats/stats" ], "window": { "navigationBarTitleText": "WorkBuddy", "navigationBarBackgroundColor": "#4A90D9", "navigationBarTextStyle": "white" }, "tabBar": { "list": [ { "pagePath": "pages/index/index", "text": "任务" }, { "pagePath": "pages/stats/stats", "text": "统计" } ] } }

我这里直接把首页和统计页配成了底部Tab，任务详情页则不加入TabBar，而是通过点击事件跳转。这种划分从用户习惯出发，两个常驻入口满足日常使用，详情页则按需打开，逻辑更清爽。

2.3 开发者工具的几个实用设置

开发者工具装好后，别急着敲代码，先进“设置-项目设置”，把“增强编译”和“上传代码时自动补全”勾上。前者能让部分新语法特性直接使用，后者则在真机预览时避免一些路径解析问题。调试基础库建议选择当前最新的稳定版，但不要勾选“自动切换最近版本”，否则哪天微信更新基础库可能导致线上的小程序行为变化，而你本地完全复现不出来。

WorkBuddy开发过程中，我几乎全程依赖预览模式而非模拟器。模拟器对网络状态的模拟不准确，云开发调用在模拟器里容易遇到跨域和真机环境差异，真机预览虽然麻烦一点，但反馈最真实。

3. 云开发环境配置与数据库设计

3.1 开通云开发，获取环境ID

WorkBuddy的数据需要云数据库支撑，所以必须开通云开发。在开发者工具左上角点击“云开发”，首次使用会要求开通并创建环境。环境名称可以叫workbuddy-prod，创建后得到一个环境ID，是一串类似workbuddy-prod-1a2b3c的字符串，后面所有云调用都要用到它。

开通后，在项目根目录的app.js里做云环境初始化：

App({ onLaunch() { if (!wx.cloud) { console.error('请使用 2.2.3 或以上的基础库以使用云能力') return } wx.cloud.init({ env: 'workbuddy-prod', traceUser: true }) }, globalData: { openid: '' } })

这里traceUser设置为true，意思是云开发会记录访问用户信息，方便查日志。第一次接触openid的读者可能会问这是什么——它是微信用户在当前小程序下的唯一标识，可以理解成用户在你这栋大楼里的门禁卡号。因为没有做账号系统，后续云函数的身份识别就全靠它。

3.2 数据库集合规划与权限设置

云开发里的“集合”概念，基本等价于传统数据库里的“表”。WorkBuddy只建一个集合，名字叫todos，文档结构沿用前面定义的任务字段。无需新建任何索引，数据量小时默认索引足够用。

权限设置上有个非常容易踩坑的点。新建集合后，默认权限是“仅创建者可读写”，也就是说只有创建这条数据的用户才能读写它。这意味着你在云函数里用管理员权限读写数据时会发现一切正常，但如果尝试在客户端直接查数据库，就会因为权限被拒而拿到空数组。WorkBuddy的做法是权限选第四项：“所有用户可读，仅创建者可读写”，同时把新增和修改操作放到云函数里执行，用云函数的高权限绕开客户端限制。这个组合方案很简单但非常实用。

WorkBuddy的云函数设计成两个：addTodo用来新增任务，toggleTodo用来切换完成状态。为什么不直接在客户端调数据库呢？因为云函数端使用的是管理员权限，不受权限规则限制，尤其后续要做数据统计或批处理时，云函数几乎是必经之路。

4. 核心页面开发详解

4.1 首页任务列表的实现逻辑

首页是WorkBuddy的门面，承担着任务展示和操作的主入口。页面的wxml核心结构如下：

<view class="page"> <view class="header"> <text class="title">今日待办</text> <text class="count">{{remainingCount}} 项未完成</text> </view> <view class="filters"> <view class="filter-item {{currentFilter === 'all' ? 'active' : ''}}" bindtap="changeFilter">const db = wx.cloud.database() Page({ data: { tasks: [], remainingCount: 0, currentFilter: 'all' }, onShow() { this.loadTasks() }, async loadTasks() { const filter = this.data.currentFilter let query = {} if (filter !== 'all') { query.category = filter } wx.showLoading({ title: '加载中' }) try { const res = await db.collection('todos') .where(query) .orderBy('createTime', 'desc') .get() const tasks = res.data const remainingCount = tasks.filter(t => !t.done).length this.setData({ tasks, remainingCount }) wx.hideLoading() } catch (err) { console.error('加载任务失败', err) wx.hideLoading() wx.showToast({ title: '加载失败', icon: 'none' }) } }, changeFilter(e) { const type = e.currentTarget.dataset.type this.setData({ currentFilter: type }) this.loadTasks() }, async toggleTask(e) { const id = e.currentTarget.dataset.id try { await wx.cloud.callFunction({ name: 'toggleTodo', data: { id } }) this.loadTasks() } catch (err) { wx.showToast({ title: '操作失败', icon: 'none' }) } }, goDetail(e) { const id = e.currentTarget.dataset.id wx.navigateTo({ url: `/pages/detail/detail?id=${id}` }) }, goAdd() { wx.navigateTo({ url: '/pages/detail/detail' }) } })

这里我故意把loadTasks放在onShow而不是onLoad里，原因很重要：onLoad只在页面初次加载时执行一次，而onShow每次页面显示都会触发。当用户从详情页完成任务编辑返回首页时，onShow会重新拉取数据，页面状态才能保持新鲜。如果你把加载逻辑放在onLoad，返回首页时你会看到旧的列表，数据不同步，用户的修改“凭空消失”，这个问题很多新手都遇到过。

e.currentTarget.dataset是事件对象上挂参数的标准方式。在wxml里通过>const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() const _ = db.command exports.main = async (event) => { const { id } = event try { const res = await db.collection('todos').doc(id).get() const currentDone = res.data.done await db.collection('todos').doc(id).update({ data: { done: !currentDone } }) return { success: true, done: !currentDone } } catch (err) { return { success: false, error: err.message } } }

这里_被定义但没有用到，其实是为了后续扩展做准备。比如以后要批量更新或做更复杂的查询，db.command是必备工具。这种“先放着”的习惯，在实际项目里很常见，但要注意删掉用不到的变量，避免代码检查报错。

部署云函数时，在开发者工具中右键点击云函数目录，选择“上传并部署：云端安装依赖”，而不是“上传所有文件”。差别在于云端安装依赖会自动执行npm install，而上传本地文件时如果你的node_modules不完整，运行时会直接报找不到模块的错误。新手很容易卡在这里，反复排查代码却找不到原因。

addTodo云函数的逻辑则多一步：要往任务数据里塞入用户的openid字段。云函数获取openid的方式很简单，在cloud.getWXContext()里取：

const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event) => { const { title, category } = event const { OPENID } = cloud.getWXContext() try { const res = await db.collection('todos').add({ data: { title, category, done: false, createTime: Date.now(), _openid: OPENID } }) return { success: true, id: res._id } } catch (err) { return { success: false, error: err.message } } }

createTime用的是毫秒时间戳，排序方便，展示时再格式化即可。_openid字段是云数据库权限机制自动识别的字段，加上它，集合的“仅创建者可读写”权限策略才能精确到人。

4.4 详情页的任务编辑与保存

详情页承担两个职责：创建新任务和编辑已有任务。页面加载时通过路由参数判断是哪种场景。onLoad里接收options.id，如果有值，说明要编辑已有任务，需要先查库回显；如果没有，就是全新的创建流程。

const db = wx.cloud.database() Page({ data: { id: '', title: '', category: '工作', categories: ['工作', '生活', '学习'], isEdit: false }, onLoad(options) { if (options.id) { this.setData({ id: options.id, isEdit: true }) this.loadDetail() } }, async loadDetail() { const { id } = this.data const res = await db.collection('todos').doc(id).get() this.setData({ title: res.data.title, category: res.data.category }) }, onTitleInput(e) { this.setData({ title: e.detail.value }) }, onCategoryChange(e) { this.setData({ category: this.data.categories[e.detail.value] }) }, async saveTask() { const { id, title, category, isEdit } = this.data if (!title.trim()) { wx.showToast({ title: '请输入任务标题', icon: 'none' }) return } wx.showLoading({ title: '保存中' }) try { if (isEdit) { await wx.cloud.callFunction({ name: 'updateTodo', data: { id, title, category } }) } else { await wx.cloud.callFunction({ name: 'addTodo', data: { title, category } }) } wx.hideLoading() wx.showToast({ title: '保存成功' }) setTimeout(() => { wx.navigateBack() }, 500) } catch (err) { wx.hideLoading() wx.showToast({ title: '保存失败', icon: 'none' }) } } })

表单校验这里我只做了非空判断，实际项目中建议再加长度限制，比如任务标题最长50个字符，避免用户在移动端输入冗长的内容。保存成功后延迟500毫秒再返回，是给用户留出看清“保存成功”提示的时间，体验上的一个细节。

详情的wxml里，分类选择用的是picker组件。它在微信里是一个原生弹层选择器，绑定的bindchange事件要在<picker>上，而不是内层的view上，这个位置摆放错误也是新手经常排查半天的小坑。

5. 数据展示与体验优化

5.1 统计页面的聚合计算

统计页需要展示总任务数、已完成数和完成率。对于个人体量的数据，直接在客户端拉全量数据再算也不算夸张的情况，但为了演示云开发的聚合能力，我还是选择在云函数getStats中处理：

const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async () => { const { OPENID } = cloud.getWXContext() try { const totalRes = await db.collection('todos') .where({ _openid: OPENID }) .count() const doneRes = await db.collection('todos') .where({ _openid: OPENID, done: true }) .count() const total = totalRes.total const done = doneRes.total return { success: true, total, done, percent: total === 0 ? 0 : Math.round((done / total) * 100) } } catch (err) { return { success: false, error: err.message } } }

这里的.where({ _openid: OPENID })是云函数里手动加用户维度过滤。虽然云函数是管理员权限，不加这个条件也能跑，但不同用户的数据会混在一起，统计结果就完全错了。这条最佳实践适用于所有云函数：不管云函数有没有权限限制，只要涉及用户数据，就按openid过滤。这是云端数据隔离的基本素养。

返回的percent提前在云函数里算成百分比整数，客户端直接渲染显示，避免在界面上做二次运算。这种“能后端算的别让前端算”的思路不只适用于云开发，也适用于所有前后端分离的项目。

5.2 下拉刷新与加载状态

小程序页面启用下拉刷新需要在app.json或页面自己的配置里开启"enablePullDownRefresh": true，WorkBuddy在首页的index.json中开启，同时配合onPullDownRefresh生命周期：

async onPullDownRefresh() { await this.loadTasks() wx.stopPullDownRefresh() }

注意wx.stopPullDownRefresh()一定要调用，否则顶部加载动画会一直转圈。另外，首页加载数据时我已经用了wx.showLoading，这时如果用户正好在下拉刷新，会出现两个加载提示叠在一起，体验很差。实践里的处理方式是：在loadTasks中增加一个参数，下拉刷新时不再弹出showLoading，只等数据回来再结束下拉动画。

这种“同一函数在不同上下文有不同行为”的模式，在小程序开发里很常见。思路其实就是给loadTasks加一个silent参数，代码改动很小，但对用户体验的提升立竿见影。

5.3 自定义组件复用

WorkBuddy的微信小程序的架构里，任务项是整个项目最核心的展示单元。首页和可能的其他页面都会用到，所以把它封装成组件是合理选择。在components/task-item/下新建组件，四个文件齐全。

组件的properties定义接收的外部数据：

Component({ properties: { task: { type: Object, value: {} } }, methods: { onToggle() { this.triggerEvent('toggle', { id: this.properties.task.id }) }, onTap() { this.triggerEvent('tap', { id: this.properties.task.id }) } } })

组件的通信规则是：数据自上而下通过属性传递，事件自下而上通过triggerEvent抛出。这样首页只需要监听bindtoggle和bindtap两个自定义事件，具体业务逻辑留在页面层处理。这种模式的好处是组件的任务项高度独立，以后做任务长列表、任务卡片展示也都能复用它，不用到处复制同样的代码。

使用组件时，在页面的json文件里声明：

{ "usingComponents": { "task-item": "/components/task-item/task-item" } }

组件路径必须以/开头，写成绝对路径。用相对路径有时候能跑，但一旦嵌套层级变深就易出错，统一绝对路径是省心之道。

5.4 骨架屏与边界状态处理

数据加载过程中如果直接渲染空列表，页面会闪一下空白，视觉上非常突兀。更友好的做法是加载完成前显示骨架屏。WorkBuddy用了简化的占位方案：在wxml里用wx:if="{{loading}}"渲染几个灰色的圆角矩形，模拟真实列表的形状；真实列表用wx:else包裹。虽然不如专业骨架屏那么精细，但实现成本极低，能明显改善首次加载的观感。

边界状态同样不能忽视。当过滤器选择了某个分类，而该分类下没有任何任务时，要显示空状态引导，比如“这个分类还没有任务，点击下方按钮创建”，而不是留白一块。用户对空白的容忍度很低，却很容易被一句友好的提示打动。

6. 完整调试与发布上线

6.1 按场景逐层进行功能验证

WorkBuddy开发完成后，我没有直接点“上传”，而是按用户操作路径从头到尾过了一遍场景测试。手机号、云函数、数据库、页面跳转，这些模块单独测都正常，不代表组合在一起也正常。清单如下：

• 新任务创建：填写标题、选择分类、点击保存、返回列表看到新任务。
• 任务勾选：点击勾选圆，任务变为完成态，剩余计数减少。
• 分类筛选：分别切到工作、生活、学习，列表内容跟随变化。
• 编辑任务：从列表点进详情，修改标题和分类，保存后返回列表，内容已更新。
• 数据持久性：完全关闭小程序重新打开，数据还在。
• 异常输入：在详情页不填标题直接保存，弹出提示，不崩溃。

每轮测试都顺手在开发者工具里观察Console面板有没有报错。只要出现红色错误信息，无论页面看起来是否正常，都要追根究底。

6.2 真机预览与云函数排错

模拟器里测完，还要用真机预览。在开发者工具点“预览”，会生成一个二维码，手机微信扫码即可以开发版身份打开小程序。真机上最容易暴露两类问题：

一类是网络路径问题。模拟器走的是开发者电脑的本地代理，真机走的是手机自身的网络。如果云函数名称写错或环境ID配置有误，模拟器偶尔能蒙混过关，真机则必然失败。遇到白屏或数据加载不出，先去云开发控制台的“云函数-日志”里看有没有调用记录和报错堆栈。

另一类是样式兼容问题。不同手机的微信版本对部分新样式支持不一致，比如深色模式下背景色不会自动调整。WorkBuddy的处理方法是主动检测设备深色模式，针对性地覆盖默认样式，保证无论手机处于哪种模式，界面的对比度都合理。

排查云函数问题时，我习惯先在云开发控制台手动测试云函数，填入模拟参数看返回结果。如果手动执行成功而客户端调用失败，问题大概率出在客户端的入参格式或云函数名的拼写。这个定位思路能把问题范围缩小一大半，比反复改代码高效得多。

6.3 代码上传与后台配置

一切测试通过后，在开发者工具点“上传”，填写版本号和备注。版本号建议语义化，比如1.0.0，备注可以写本次变更内容。上传成功后，需要到微信公众平台的“版本管理”里将开发版本提交为审核版本。

审核阶段按要求填写功能页面描述。WorkBuddy属于工具类目，审核周期一般几个小时到一两天。这期间可以把小程序名称、头像、简介等资料补充完整。特别注意个人主体小程序名称不能与已有名称重复，且要有一定辨识度，WorkBuddy这个词作为独立词汇，基本上不会撞名。

6.4 发布后监控

审核通过后手动点“发布”，小程序就算是正式上线了。上线不等于终点，我习惯第一时间用手机打开线上版本，完整走一遍核心流程。然后看云开发控制台的数据访问统计和请求日志，确保没有意外的异常调用。前两周每天瞄一眼数据增长情况，如果发现日活远低于预期，多半不是技术问题，而是需求的真实性存疑，这个信号越早发现越好。

7. 常见问题与排查技巧

7.1 数据处理相关的典型问题

问题一：云函数调用后数据库里没有数据？

排查顺序先看云函数日志，确认调用是否成功。如果日志显示成功但集合里没有记录，检查集合是否选对了环境。开发者工具默认连接的环境和云函数里cloud.init指定的环境必须一致，网上最常见的问题就是“环境ID不匹配”。

问题二：列表数据一直不刷新？

回到onShow和onLoad的区别。如果你在onLoad加载数据，从详情页返回时页面不会重新触发加载。解决办法就是把数据加载统一放在onShow。这也是我在这篇教程里反复强调onShow的原因。

问题三：勾选任务时会跳转到详情页？

事件冒泡问题，把勾选区域的bindtap改成catchtap。这几乎是零成本修复，但不知道原理的人可能要在代码里找半天。

问题四：修改标题后页面不显示？

确认onTitleInput是否真的从输入事件里取到了值。e.detail.value才是用户输入的内容，有些初学者写成e.target.value，结果取到的是空值，白忙一场。

7.2 编译和权限相关的问题

问题五：页面空白但无报错？

检查app.json里是否注册了该页面。没注册的页面文件存在但不会生效。这个问题的诡异之处在于编译不报错，运行时却没有反应。

问题六：数据库权限导致用户之间能看到彼此数据？

集合权限设置成“所有用户可读”时，任何客户端都能读到所有数据。如果不想看到这种情况，回到云开发控制台把权限改回“仅创建者可读写”，并把写操作都挪到云函数里执行。

问题七：真机调试时图片或资源加载失败？

资源路径写错。建议统一使用绝对路径/images/xxx.png，不要写相对路径，因为页面在不同层级时相对路径的结果不同，很容易白屏。

7.3 常用排查工具清单

这六样工具配合使用，足以覆盖WorkBuddy开发过程中95%以上的问题排查场景。

8. 上线后的体验复盘与扩展思路

8.1 从WorkBuddy项目里沉淀出的通用经验

WorkBuddy开发过程中，我最大的体会是：小程序的复杂度不在单点技术，而在模块之间的衔接。页面生命周期和云函数调用时机、组件事件和页面状态同步、用户操作路径与数据更新的顺序，这些衔接环节才是真正的重点。新手写完单个页面觉得一切顺利，一旦开始串流程就各种出错，原因就在这里。

另一个体会是关于功能取舍的。WorkBuddy最初规划过提醒推送、日历视图、标签系统，最后全部砍掉。这不是懒，而是保护了项目的可完成性。第一版只保留了“创建任务、标记完成、分类、统计”这条主闭环。正是这个极简闭环让整个项目能在可控时间内从零走到发布。如果一开始功能列表写得密密麻麻，很可能卡在某个边缘功能上，整个项目都被拖垮。

这一点对新项目尤其重要：用一个最小功能闭环走通全流程，之后再逐步加复杂度，是最高效的策略。

8.2 可能的扩展方向

WorkBuddy后续的扩展方向，按优先级排列的话：

• 任务提醒功能。微信小程序端目前没有原生本地通知能力，但可以通过“订阅消息”实现每日待办推送。用户每次操作时主动订阅一次，系统才能给该用户发一条提醒。需要注意的是，订阅次数有严格限制，不能无限发送。
• 数据导入导出。支持通过复制文本批量创建任务，或者把任务导出为表格文件，个人用户的迁移成本会大大降低。
• 标签自由配置。目前分类是写死的工作/生活/学习，可以改成用户自定义分类，增加灵活性。

每次扩展前都先回答三个问题：是否真的有必要、投入产出比是否合理、当前数据结构是否需要迁移。这三个问题能帮你挡住不少拍脑袋的功能。

最后分享一个实操中的小技巧。如果你打算长期维护这个项目，从一开始就给云函数和集合名加上统一的前缀，比如wb_todos、wb_addTodo，因为微信的云开发控制台里，所有小程序共用一个环境列表，清晰的前缀能让你在多个项目共存时一眼找到属于WorkBuddy的资源。这把命名习惯坚持下来，后面能省下大量在控制台里翻找的时间。