给这个项目起名叫 weixin131听起来像一串随机编号其实是我本地工程里的第131个微信小程序 demo后来这个 demo 越做越完整干脆当正式项目用了。最初要解决的问题很朴素家里买菜、缴费、接送孩子、周末安排、水电账单全在微信群里来回刷消息一多就漏事。做出来的东西就是一套能共享给全家的家庭事务管理微信小程序把琐碎的家务变成一张明确的、所有家庭成员都能看懂的清单再配上到期提醒和账本记录。这个项目适合两类人参考一类是家里事务庞杂、想在微信里低成本协调分工的家庭用户另一类是刚入门微信小程序开发、想找一个真实业务场景练手的人。它不复杂但五脏俱全涉及多人协作、数据隔离、订阅消息、定时任务、账单分摊这些常见诉求把它跑通一遍后面再做大应用会顺手很多。下面按我的实际开发顺序把需求和实现细节完整拆一遍。1. 项目立项为什么一个家庭需要专用事务管理工具1.1 家庭场景里的真实需求拆解在动手写代码之前我先在亲戚群里观察了小半个月。结论是绝大多数家庭不是没有“管理系统”而是把微信当成了管理系统但微信群天然不适合处理任务。几个典型场景我相信大家都有印象妈妈说下班路上买鸡蛋爸爸回了个“好”结果忘买了周末要交电费有人说“回头交”就再也没有下文月底算开销谁花的钱都对不上。这些问题的根源不是记性差而是信息散落在聊天记录里没有责任人、没有截止时间、没有完成状态。我把家庭事务拆成三类任务类包括买菜、打扫、接送、维修、缴费时间类比如水电费每月几号交、孩子的兴趣班哪天上课钱类家庭日常支出、共享购物、水电燃气分摊。家庭事务管理小程序只要把这三类事情闭环掉就解决了90%的问题。所以需求清单可以定量表述家里人能创建任务指定某人负责设置截止时间任务到期能通过微信订阅消息提醒任何一个家庭成员能记录家庭支出月底能自动算出每人该付多少家里所有人能看到同一个任务视图而不是各自手机里一个孤立的待办列表。1.2 为什么选微信小程序而不是独立App这个选择我犹豫过几天因为身边有同事用原生App做得挺重功能强大但从推广角度很尴尬。让我实际放弃App和纯网页方案的原因主要是这几个。第一是安装成本。让家里六十岁的长辈单独装一个App还要注册账号基本可以宣告项目失败。微信小程序扫一下或者从聊天窗口点进去就能用对不熟悉电子设备的人友好很多。第二是消息触达小程序可以直接使用微信的订阅消息用户授权后能在任务到期时收到服务通知这是网页端做不到的。第三是开发成本这个项目使用了微信云开发数据库、云函数、文件存储都在云端不用自己买服务器。我把三种方案做了个简单对比方案亲人上手成本消息触达能力开发维护成本适合场景原生App高需下载安装受系统策略限制高两套平台商业化产品网页应用低发链接即可基本无推送能力中工具型后台微信小程序最低扫码即用支持订阅消息提醒低云开发省去运维家庭/小团队协作还有一个方案是写个微信机器人管群它能发消息提醒但没有统一家庭视图、没有账单字段、任务多了没法归档最后放弃了。核心需求不是“发通知”而是“一家人基于同一组任务协作”。这个判断直接决定了选型。2. 功能框架与数据结构先把底子打牢2.1 功能模块清单与优先级规划我一开始很容易想复杂比如做互动板块、家庭日记、积分商城、排行榜。冷静下来以后我把所有想法收敛成四个核心模块家庭空间创建家庭、邀请成员、成员角色管理任务管理发布任务、指派成员、设置截止时间、任务状态流转提醒中心订阅消息的授权管理、到期提醒、每日汇总家庭账本记账、分类统计、人均分摊优先级排序是任务第一因为这是刚需提醒第二因为它是小程序相较于其他工具的差异化能力账本第三可以放到第二版家庭空间从第一天就要做否则所有数据没有归属。页面结构也跟着功能走底部 tabBar 分成四页“今日”看当天安排“任务”看全部事务“账单”看收支“我的”管成员和设置。第一版千万不要再加第五个 tab家人用起来会发懵开发成本也高。2.2 云开发数据库集合设计这个项目用的是微信云开发数据库是文档型的没有传统关系型数据库里的外键和 JOIN所以在设计集合时要做一些数据冗余。一开始没想清楚后面有些查询就很别扭这里直接给出我最终用的结构。第一个集合是houses一个文档代表一个家庭{ _id: house-id, name: 幸福小窝, ownerOpenid: 创建者openid, members: [ { openid: xxx, role: admin, joinedAt: 202401011200 } ], inviteCode: ADF8K2, inviteExpireAt: 202401111200, createdAt: 202401011200 }第二个集合是users记录用户的基础信息{ _id: user-id, openid: 用户openid, nickname: 昵称, avatarUrl: 头像地址, activeHouseId: 当前选中的家庭, createdAt: 202401011200 }第三个集合是tasks家庭任务的主体{ _id: task-id, houseId: house-id, title: 交电费, description: 顺便看下余额, category: 缴费, assigneeOpenid: 负责人的openid, dueDate: 2024-01-15, priority: high, status: todo, createdByOpenid: 创建者openid, createdAt: 202401011200, updatedAt: 202401011200 }第四个集合是bills记录家庭收支{ _id: bill-id, houseId: house-id, amount: 268.50, type: expense, category: 日常采购, recordedByOpenid: 记账人openid, payDate: 2024-01-10, note: 周末超市采购, createdAt: 202401101200 }设计过程中最重要的是每个集合都带houseId之后所有查询都以它为第一过滤条件既保证数据隔离也方便建索引。tasks集合中我冗余了assigneeOpenid而不是像关系型数据库那样单独建一张关联表目的就是减少一次查询毕竟微信小程序云函数调用数据库也有延迟能在一张表里拿全数据就别拆。索引方面houses的inviteCode建唯一索引tasks建议联合索引houseId status dueDatebills建议联合索引houseId payDate。云开发控制台里新建索引很快但一开始只建单字段索引的话数据量到几千条时查询速度就会明显下降。2.3 成员权限与家庭组织关系的设计多人协作用户最怕的就是权限混乱。我实现的方案是家庭创建者自动成为owner可以邀请成员、移除成员、解散家庭其他成员统一是member可以创建任务、记账但不能解散家庭。管理员和普通成员在操作上实际没做差异因为家庭场景不需要复杂的审批流刻意区分反而让家人不知所措。家庭成员加入时用邀请码方式。先由已有成员在“我的”页面生成邀请码新成员输入邀请码后加入对应家庭。邀请码存在houses集合的inviteCode字段里生成时顺手写个过期时间默认24小时有效避免邀请码被随意使用。权限检查放在两个层面前端根据当前用户是不是家庭成员控制按钮显示后端云函数每次写操作前再查一次houses确认 openid 在 members 数组里才继续。前端隐藏按钮只是交互逻辑不能作为安全边界这个认知后面排查问题时帮了我大忙。3. 关键功能实现任务、提醒与实时协作3.1 任务清单与“今日待办”的前端逻辑任务模块是整个小程序的主干。“今日”页面看起来简单但它不是简单查一下dueDate等于今天而是要做三层筛选第一层取当前家庭的未完成任务第二层取“到期日小于等于今天”的任务第三层按截止时间排序越紧急的越靠前。这样过了期的未完成任务会一直留在今天视图里提醒家人去收尾而不是悄悄沉底。查询直接放在云函数里做不把全表拉到前端再过滤。原因有两个一是家庭成员手机性能差距大老手机处理几百条数据也有卡顿二是安全边界需要统一在云函数控制前端只接收自己家庭的数据。云函数里的核心查询逻辑大概是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 { openid, houseId } event const today new Date() const dateStr today.toISOString().split(T)[0] const res await db.collection(tasks) .where({ houseId, status: todo, dueDate: _.lte(dateStr) }) .orderBy(dueDate, asc) .limit(50) .get() return { tasks: res.data } }服务器返回后前端按dueDate显示在对应分组里已完成的任务可以点击切换状态。这里我特意没做“恢复已完成”的撤销功能因为家庭场景里误操作不多撤销交互会让代码复杂很多收益很小。3.2 订阅消息实现任务到期提醒订阅消息是这个项目区别于普通账本工具的核心能力也是最容易踩坑的部分我放在技术实现最前面讲。微信小程序的订阅消息分“一次性订阅”和“长期订阅”。家庭事务类目下个人小程序的长期订阅基本申请不到所以实际方案是用一次性订阅用户授权一次只能发送一条消息。这意味着不能在用户创建任务时就默认帮他订阅所有提醒因为授权次数很快就用完了。我最终设计的规则是任务创建者和任务负责人可以对任务本身授权提醒。用户在任务详情页点“接收提醒”按钮时小程序弹起订阅授权面板用户点了同意后前端把授权记录写入users表的subscribeTimes字段里。到这里只是拿到“凭证”真正发送在云函数里执行。发送订阅消息的云函数核心代码// index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event, context) { const { taskId, templateId } event const openid cloud.getWXContext().OPENID const task (await db.collection(tasks).doc(taskId).get()).data if (!task) return { code: -1, msg: 任务不存在 } const res await cloud.openapi.subscribeMessage.send({ touser: task.assigneeOpenid, page: pages/task/detail?id${task._id}, data: { thing1: { value: task.title.slice(0, 20) }, time2: { value: task.dueDate 23:59 } }, miniprogramState: formal }) return res }这里 templateId 是申请订阅消息模板后生成的动态从参数传入会更好维护。发送时要注意字段类型thing1只能填20个字符以内的短文本超了会报错time2必须是标准时间格式。页面跳转路径也要认真配置点通知后要能进到任务详情页否则用户会有“假通知”的感觉。定时提醒用的是云开发定时触发器在云函数目录下config.json里配置{ triggers: [ { name: dailyReminderCheck, type: timer, config: 0 0 8 * * * * } ] }这个表达式的意思是每天早上8点触发一次注意云开发的 cron 表达式是七位包含秒。定时器被触发后云函数去查所有状态为todo、截止时间为当天的任务给每个任务负责人发订阅消息把当天要办的琐事一次性汇总成一条消息。为了让推送不超限每个用户每天最多收到3条提醒这是我用云函数里计数逻辑控制的。3.3 账单记录与人均分摊计算家庭账本相比专业个人记账软件要轻量很多不需要复杂的资产账户和预算体系只记录日常收支和家庭成员开支分配。所以我的bills集合刻意没有做“借款人”和“还款人”字段只用两条规则每笔支出记录实际付款人和金额月底按参与分摊的成员数算人均。分摊计算的逻辑很简单某成员当月实际支出总额减去当月人均应摊值正数代表别人欠他钱负数代表他欠别人钱。我直接用db.collection(bills).aggregate()按月分组求amount的和然后遍历家庭成员算出差额。const $ db.command.aggregate const res await db.collection(bills) .aggregate() .match({ houseId, payDate: _.gte(monthStart).and(_.lte(monthEnd)), type: expense }) .group({ _id: $recordedByOpenid, total: $.sum($amount) }) .end()结果集里就能看到每位成员当月花了多少钱再除以人数得到人均。页面里直接展示“本月人均支出XXX你超支了XX”这种口语化文案家里人一看就明白。为了让这个模块不至于太重我没有做逐笔记账的分类统计图只在顶部保留收入、支出、结余三个数字再往下是明细列表这样妈妈们用起来压力小。3.4 家庭成员实时同步的监听方案多人协作最怕一个人改了任务状态另一个人看到的还是旧数据。云开发的数据库支持watch实时监听前端可以监听某个查询条件的数据变化但这里有两个坑一是watch只能在真机或开发者工具中测试普通get查询不会触发二是监听范围不能太大否则每次变化都会拉全量数据。我的做法是在任务列表页开启一个限定范围监听只监听当前家庭下状态不是done的任务const watcher db.collection(tasks) .where({ houseId, status: _.neq(done) }) .watch({ onChange: snapshot { // 用 snapshot.docs 更新页面数据 this.setData({ taskList: snapshot.docs }) }, onError: err { console.error(watch error:, err) } })watch返回的snapshot类型是QuerySnapshot里面包含了查询结果和变更类型。页面卸载时需要调用watcher.close()关闭监听否则会一直占用资源在 iOS 上会有卡顿感。并发更新我遇到过一个实际问题两个人同时打开任务页A把任务标记完成B也已经打开了详情页然后B也点了完成后写入的数据可能覆盖掉先写入的数据状态本身没有歧义但如果在完成时附带时间戳、操作人这类信息就会被覆盖成错的。解决办法是云函数更新前比对updatedAt只允许基于最新版本执行更新这是典型的乐观锁方案。4. 从开发到上线的避坑经验4.1 订阅消息下发失败的排查实录订阅消息是高频踩坑点。我整理了实际遇到的几类问题发现原因高度集中。第一种是错误码 43101意思是用户拒绝授权或者授权次数用完。家庭场景里常见的情况是长辈试了一下嫌弹窗烦就拒绝了后面任务到期自然收不到提醒。这个现象不是 bug但体验很差。我的处理方法是在任务详情页做一个醒目的卡片显示“提醒剩余次数0次点此再次授权”而不是让用户误以为系统坏了。第二种是模板字段不匹配。云开发发送时要求touser是消息接收者的 openid页面路径必须已经发布上线miniprogramState如果填developer只能在开发者工具里收到正式版本里要改回formal。我调试时被这个参数卡了很久最后在云函数日志里看到返回码才反应过来。第三种是短时间内发送频率过高微信会对同一个用户的消息下发做限流。家庭用户每天操作不超过几十次不容易触发但如果定时任务全家人统一上午8点发周末可能瞬间集中很多消息。我在云函数里加了一个简单的节流同一用户当天最多发3条多出来的任务合并到晚间推送里。错误码常见原因排查方向43101用户拒绝或订阅次数耗尽检查订阅授权记录是否存在40001缺少参数或格式非法检查模板字段和长度40037模板ID无效核对模板ID与标题字段类型45009接口调用频率超限控制批量发送节奏4.2 数据库权限与并发造成的脏数据云开发数据库的默认权限策略我一开始用的是“仅创建者可读写”这个配置下发现自己创建的houses文档没问题但其他家庭成员写不了共享的tasks因为任务是 A 创建的B 点击完成时会提示无权限。后来又改成“所有用户可读”结果发现任何用户都能读到所有家庭的房屋编号这显然不能接受。最终方案是用安全规则让用户只能访问自己的houseId数据。比如tasks集合的安全规则可以写成{ read: doc.houseId auth.openid || doc.houseId in auth.openid.houses, write: doc.houseId in auth.openid.houses }但需要说明的是安全规则的表达式其实不适合表达从另一个集合里查 membership 的复杂逻辑所以我的所有数据操作都强制走云函数云函数内通过db.collection(houses).where({ _id: houseId, members: _.elemMatch(_.eq(openid)) })校验身份然后再读写。前端数据库权限一律设置为“仅创建者可读写”服务端用管理员权限绕过限制。这样既隔离了数据又不用纠结安全规则的表达能力。并发问题在任务状态更新上表现最明显。两个家庭成员同一秒对一个任务操作可能导致status被覆盖。我的做法是用updatedAt比较更新前先查一次任务详情然后把updateTime大于本地updatedAt的请求拒绝。家庭应用数据量没那么大这种轻量乐观锁完全够用。4.3 定时触发器时间设置的坑定时触发器第一次配置时我按传统cron的六位格式写了0 8 * * *结果一直没触发。后来查文档发现微信云开发的定时触发器是七位表达式顺序是“秒 分 时 日 月 星期 年”所以每天8点要写成0 0 8 * * * *秒位不能省略。第二个坑是时区。云开发定时器用的是 UTC 时间国内用户默认东八区如果写0 0 0 * * * *实际上跑的是北京时间早上8点。我把提醒任务配置成0 0 8 * * * *其实是 UTC 8点也就是北京时间16点完全背离了“早上提醒”的预期。后来在代码里做了时区换算function getBeijingTimeString(date) { const utc date.getTime() date.getTimezoneOffset() * 60000 return new Date(utc 8 * 3600000) }更稳妥的做法依然是触发后取当前时间再通过Intl或者手动加8小时得到北京时间再进行查询和业务判断。这个坑不踩一次很难意识到写在这里给后面的人提个醒。第三个坑是触发器部署后不是立即生效需要重新上传部署云函数并且在云开发控制台的“云函数-触发器”页面确认已经出现定时任务。有时候改完config.json忘了重新部署看起来配了实际没生效这个问题只能靠自查解决。4.4 隐私合规与云函数安全边界做任何涉及家庭成员数据的小程序都要重视隐私保护。在小程序后台需要配置用户隐私保护指引声明收集昵称、头像、家庭信息等用途采集用户信息前必须有弹窗说明不能偷偷传数据。头像昵称这块有个明显的变化过去可以直接调用wx.getUserProfile现在政策调整后建议优先使用小程序提供的头像昵称填写能力让用户自己选择头像和昵称这样省去授权弹窗也减少隐私风险。我在“我的”页面布局了微信原生提供的昵称输入框和头像选择组件接起来比自定义上传要省很多事。后端日志里也要小心避免把 openid 明文打印出来。openid 作为用户的持久标识一旦泄露结合其他信息可能追踪到个人。云函数返回的错误信息我统一改成语义化消息把内部错误码和 openid 藏在日志里只向前端返回业务提示。清理日志是上线前必做的一件事。最后提一个我个人的习惯所有用户产生的数据都属于家庭这个组织而不是个人。所以数据库集合里每个文档都带houseId每次云函数调用都先校验这个标识中途出现过一次因为忘记带上houseId导致查全表的情况虽然数据量小没爆出问题但这种习惯一旦养成项目大了会很难追查。多说两句项目做完以后我自己在家里用了半年最大的感受是工具做得再好最终还是要落到家庭成员的理解成本上。有些功能技术上是合理的但老年人用起来就是别扭。比如订阅消息第一次弹窗他们根本不知道这是什么后来我把授权入口改得极其直白写了一句“点这里明天早上提醒你交水费”接受度立刻上来了。最后分享一个小技巧不要把“今日待办”和“历史任务”完全分开。我把过期任务每天自动留在今日列表里同时附上一个红色的“超期”标记家庭成员养成习惯后每天早上只需要看一屏就能知道今天谁欠着什么。这个设计没有太复杂但确实是家里老人愿意长期用的核心原因。