企业官网建设流程全解析

1. UniApp做健康饮食小程序：为什么值得选这条路

最近不少做私活和接外包的朋友私信问我，说客户点名要做“健康饮食管理”小程序，又问该用原生微信小程序还是跨端框架。我去年刚从“2048-小程序.zip”那个纯原生小游戏项目转到 UniApp，折腾完一整套健康饮食管理应用之后，最有资格回答这个问题。先说结论：如果你手头只有一份微信小程序源码包需要快速二次开发，同时未来还可能上支付宝小程序、H5甚至App，那么直接用UniApp重构业务层比在原生代码里打补丁省心得多。

之前那份2048项目的源码是原生微信小程序写的，逻辑简单，页面不过几个，拿来当练手没问题。但健康饮食管理这种业务型项目完全是另一回事：页面多、状态复杂、表单交互密集、还得处理用户登录、手机号绑定、订阅消息、数据上报这一堆微信生态能力。用原生开发不是不行，问题是每写一个页面就要考虑一遍不同机型的适配、导航栏高度、事件传递，开发效率明显跟不上需求变。UniApp最核心的价值就是让你用一套Vue语法写出来，编译到微信小程序时自动生成对应原生代码。

我在实际项目里还有一点很深的体会：UniApp的组件语法和生命周期高度接近Vue，社区里的Vue组件生态可以直接复用，比如图表、日历、表单校验这类高频组件，不需要自己造轮子。加上HBuilderX内置的云打包和真机调试，整个开发闭环非常顺。对于健康饮食这种需要长期迭代的SaaS型小程序，选UniApp从长期维护角度看是性价比很高的决定。

这套项目最初交付时客户还额外追问了一个点：“能不能以后直接复用这套代码出App？”这就是用UniApp的又一大红利。如果你选了原生微信小程序，以后做App基本上等于重写；但UniApp在条件编译的加持下，同一套业务代码可以把微信登录、支付、分享这些平台差异全部用条件编译隔离，真正实现“写一次，多端运行”。

2. 项目信息架构与核心功能拆解

2.1 页面结构与TabBar设计

健康饮食管理小程序和游戏类项目的最大区别在于：它的信息架构必须足够清晰，用户进入后三步以内要找到核心功能。我最终确定的TabBar是四个页面：首页、食谱、记录、我的。

首页承载今日概况，包括当天摄入热量、蛋白质/碳水/脂肪三元宏量营养素进度条、饮水杯数，还有今日推荐食谱卡片。这个地方的关键是“一眼抓重点”，不要让用户打开先看一堆运营banner。

食谱页是内容型页面，按早餐、午餐、晚餐、加餐四个时间段分类，每个食谱卡片显示一份的成品图、总热量、预估烹饪时间。食谱详情页里必须有完整的食材清单和克数，用户点“记一笔”可以一键把食谱的食材导入当天饮食记录。

记录页是这款应用最核心也最费力的一页。两条主路径：一条是手动搜索食材添加，另一条是拍照识别。我们项目用的是素材库全手动方案，因为拍照识别涉及文字识别与食材库匹配，如果后端算法不给力体验会很差，这个后面细说。

我的页面承载用户档案：昵称头像、身高体重、目标热量、饮食偏好标签、订阅消息授权入口、历史记录查询。还有一个容易被忽略但非常重要的小功能：亲友绑定。这个需求是后来运营调研加上的，长辈不会用手机记录饮食，子女远程帮忙补录，结果发现使用频率意外地高。

2.2 健康档案与目标热量计算逻辑

健康管理类应用最大的坑是“算不准”。绝大多数人不知道自己一天该吃多少卡，而市面上的应用要么给个固定值（过度简化），要么要求填一堆指标（用户嫌烦）。我们采用的方案是以 Mifflin-St Jeor 公式为基础，用户只需填身高、体重、年龄、性别，再选一个活动系数（久坐/轻度/中度/高度），就能算出基础代谢和每日维持热量。

男性基础代谢 = 10 * 体重(kg) + 6.25 * 身高(cm) - 5 * 年龄 + 5，女性则是最后加161而不是加5。目标热量则在维持热量的基础上按减脂（-20%）、保持（0%）、增肌（+15%）三档调整。这里我没有用更复杂的Katch-McArdle公式，因为它需要体脂率，让普通用户去填体脂率几乎等于劝退，精确度在工程实践上完全够用。

这套逻辑在实现时全部放前端计算，不依赖后端网络请求，用户改完档案立即能看到目标热量变化，体验非常跟手。唯一的坑是活动系数这个选项用户容易乱选，结果严重偏高偏低。我后来加了一个默认值“轻度活动”，并在旁边标注举个例子，比如“外卖为主、每天走路不超过5000步”，普通用户可以照着对号入座。

2.3 食物库、饮食记录与营养汇总

核心的数据模型是三条主表：foods（食物库）、meal_records（饮食记录）、daily_summaries（每日汇总）。其中foods表里每一条食物必须包含：名称、别名、每100克热量、蛋白质、脂肪、碳水、膳食纤维、钠、图片URL。字段不贪多，因为每一克都要用户去输入，字段越多输入成本越高，流失越快。

meal_records记录用户在某一天某一餐添加的食物条目，包含食物ID、摄入克数（一顿饭有多个食物就是多条记录）、记录时间。daily_summaries是每日聚合表，每天凌晨由云函数把当日所有meal_records聚合一次，方便首页和图表页快速读取。这里采用聚合表而不是实时计算，一个重要原因是微信小程序端有性能限制，用户频繁打开首页看汇总时，每次都联表查询几十条记录再做求和，体验会明显卡顿。

营养汇总的具体展示，我用的是一个环形进度条，以目标热量为基准分成三段颜色：低于70%为绿色“还差”，70%-100%为蓝色“接近目标”，超过100%为橙色“已超标”。颜色阈值这个细节是设计反复打磨过的，因为过于简单对用户的行动引导价值不大。

3. 初始化工程与请求层封装：先搭对地基

3.1 从源码包迁移到UniApp工程结构

如果是全新开始，直接在HBuilderX里新建uni-app项目，选择“默认模板”即可，模板自带pages.json、manifest.json、App.vue三个核心文件。但如果你像我一样是从既有微信小程序源码迁移，就不能直接用文件替换，需要手动把原生组件结构映射到Vue模板的component体系。

我那次迁移的做法是先建好uni-app空工程，搭好tabBar和页面路由，再把每个原生页面的wxml结构翻译成vue模板（把data绑定改成vue的:prop，把bindtap改成@tap，把wx:if改成v-if），最后把wx.request统一换成封装好的uni.request。其中最耗时不是模板转换，而是原本原生代码里大量的app.globalData全局变量引用，这在小程序端还能跑，但换到Vue的响应式体系就要改为store管理。

还有一个小细节容易被忽略：原生小程序的sitemap.json和project.config.json不要直接复制到uni-app里。sitemap.json是在微信开发者工具里配置的，uni-app打出来的包会自己带一份，你要是手工覆盖反而把编译配置搞坏。project.config.json则在manifest.json里完成大部分映射，包括appid、项目名称、vConsole开关等。

3.2 请求封装与错误码统一处理

健康饮食项目的接口数量不会特别多，但分布零散：登录、档案、食谱、记录、提醒，每个模块都有不同的错误语义。如果不做统一请求封装，代码里到处都是uni.request的success回调，等着你的就是改一处崩三处的噩梦。

我封装的request工具核心逻辑大致如下：所有请求统一走一个Promise包装，baseURL从环境变量读取，自动携带token，响应体里code等于0才resolve，否则统一走reject并弹toast。这个封装的关键点是后端返回的HTTP状态码和业务码要分开判断，微信小程序经常出现HTTP 200但业务code非0的情况，不能拿HTTP状态码当业务结果用。

登录态过期是高频问题。微信小程序的session_key有时效性，token一旦过期，后端返回的业务码一般是10002（系统内部错误的一种表现，但多数情况是登录态失效或code异常）。我踩过的坑是首次请求返回10002后立即重新wx.login拿新code刷一次token，但并发请求可能同时回来多个10002，导致重复刷新token，最后互相覆盖。解决方式是维护一个isRefreshing标识，同时把刷新期间的请求挂进一个pending队列，刷新完成后统一重放。这个模式在Web端叫“请求拦截与重放”，在微信小程序里完全适用。

基础请求层跑通后，所有业务模块只关心数据本身，不需要再写loading和错误toast的重复代码。我在uni.showToast里统一处理了错误提示文案，后端只需要给一个msg字段即可，前端不背文案管理的锅。

3.3 环境配置与manifest参数项

manifest.json是UniApp跨端配置的中枢，微信小程序相关的配置项集中在mp-weixin节点下。我的建议是打开manifest.json源码视图，逐项核对：

• appid：必须填真实的微信小程序appid，测试号和正式号逻辑不同
• setting.urlCheck：开发阶段可以关掉合法域名校验，发布前必须开
• usingComponents：如果引用了easycom组件规范，不需要逐个声明
• permission：需要在隐私接口（比如定位）时配置对应权限描述
• requiredPrivateInfos：如果使用地理位置相关能力，需要在app.json对应位置声明

还有一项非常容易被遗漏：networkTimeout。微信小程序默认request超时是60秒，但你如果做了上传图片的功能，建议单独给uploadFile配一个更长的超时时间，否则用户上传大图时经常直接断连，体验极差。我在项目里把request设为10秒，uploadFile设为30秒，实测下来用户反馈“上传失败”的投诉明显减少了。

4. 手机号快捷登录与用户体系的落地细节

4.1 登录流程：从wx.login到手机号授权

健康饮食管理属于强个性化应用，用户必须建立档案才能算热量，所以登录环节不可以太轻。标准流程是：进入小程序先静默wx.login拿code，后端拿去换openid，拉取用户头像昵称接口失败也无所谓，可以先用微信昵称作为默认昵称，等用户进到“我的”页面再引导完善。真正影响业务闭环的是手机号，后面做订阅消息推送和亲友绑定时必须有手机号作为唯一账号索引。

手机号获取在微信小程序里有专门组件：button的open-type设为getPhoneNumber，用户在按钮上主动点击触发授权。这里有个重要政策变化，新版基础库要求手机号必须通过“手机号快速验证组件”获取，不能再靠老的getPhoneNumber接口直接拿到明文手机号。也就是说用户点击后，你拿到的是一个code，需要把这个code连同wx.login的code一起发给后端，由后端调用微信服务端接口换取真实手机号。

我刚开始做的时候在真机上反复测试不通过，排查半天才发现问题出在配置上：微信公众平台的“隐私保护指引”没有勾选“手机号”采集项，调用时直接被微信拦截。这种问题在开发者工具里不报错，只显示一个空回调，非常容易让人以为是接口挂了。所以上线前务必去mp后台完善用户隐私保护指引，并且把手机号、头像昵称、地理位置等采集项全部声明清楚。

4.2 登录态过期、静默续期与并发刷新

很多纯前端选手拿原生小程序的wx.login流程直接套到UniApp，会遇到两个坑。第一个坑是wx.login得到的code只能用一次，换session_key后旧code立即失效；如果后端处理慢了，前端又发起一次wx.login，后一次结果会覆盖前一次，最终后端用错code导致登录失败。第二个坑更隐蔽：UniApp的uni.login在不同端上的行为并不完全一致，微信小程序端它封装的就是wx.login，但如果你编译到App端再调uni.login，获取到的可能是App平台的登录凭据。

4.3 头像昵称填写能力的适配策略

微信官方在2022年之后调整了用户头像昵称获取规则，wx.getUserProfile直接弹窗授权的方式已经废弃。现在合规的做法是：在“我的”页面提供一个“设置头像和昵称”的入口，用户点击后通过input组件的type=nickname来填写昵称，通过button组件的open-type=chooseAvatar来选头像。这套交互在UniApp里同样支持，但要注意button组件在部分基础库版本里需要添加微信小程序平台的编译条件。

这个改动对我项目的影响不小，因为健康档案的建立需要用户昵称，而很多用户跳过这一步。后来我把“完善头像昵称”和“建立健康档案”合并成一个引导流程，用户首次进入“我的”页面时出现一个半屏弹窗，一步一步引导填写，完成率比之前直接把表单藏在设置里高出了将近一倍。

5. 健康饮食业务核心：食物库、营养计算与记录场景

5.1 食物数据如何建模：不追求全，追求够用

我见过很多健康应用死在食物库过大无法维护，或者食物库太小覆盖不了用户需求。这里面有个产品层面的trade-off：每新增一种食物，就需要维护对应的营养素数据、别名、图片、单位换算，运营成本并不低。所以初期食物库不需要追求全，但要保证“高频覆盖”。

什么叫高频覆盖？一顿外卖里出现频率最高的：米饭、鸡胸肉、西兰花、鸡蛋、牛奶、苹果、香蕉，加上常见的面条、牛肉、番茄、土豆、酸奶、坚果，把主食、肉蛋奶、蔬菜、水果每个类目做30种上下，基本就能覆盖用户日常饮食80%的记录需求。数据库字段里必须加一个“别名搜索”，比如用户搜“西红柿”要能搜出“番茄”，搜“土豆”要能匹配“马铃薯”，否则用户找不到食物就流失了。

食材的计量单位是另一个隐藏痛点。健康食谱里的食材克数用户没法直接感知，但“一个鸡蛋约50克”“一碗米饭约200克”这种自然语言单位就友好很多。我在foods表里增加了一个extra_units字段，允许录入“1个=50克”“1碗=200克”这类换算规则，录入界面给用户提供“克数输入”和“单位快捷选择”两种模式。这个设计在用户访谈时被多次点赞，算是本项目里最简单但最讨巧的功能之一。

5.2 营养计算逻辑与四舍五入的坑

计算逻辑本身并不复杂：某一餐的蛋白质 = 每种食物每100克蛋白质含量 * 摄入克数 / 100，然后累加。但我在实现中踩了一个比较隐蔽的坑：所有计算如果用Math.round处理，多条记录累加后，最后汇总值会与你手动逐条相加的结果存在1-2克的偏差。因为每条记录在入库前都做了四舍五入，累加时误差就被放大了。

解决办法是入库时保留原始克数和该条食物的营养成分原值，展示时前端只做显示层四舍五入，汇总计算用未四舍五入的原始值聚合并最终一次取整。这是典型的“显示精度与计算精度分离”思想。后来把daily_summaries表里所有营养字段设计成decimal(10,2)，避免浮点存储产生的精度漂移，后端的统计报表再也没对过账的问题。

5.3 每餐记录流程：搜索、快捷添加与一键导入

记录一餐最顺畅的路径是：点开记录页 -> 点“早餐” -> 搜索“鸡蛋” -> 选“鸡蛋（煮）” -> 默认50克 -> 确认。整个流程应该在三步以内完成，任何多余操作都会增加流失率。我在交互上做了两个优化：第一个是最近常用的食物排在最前面，第二个是连续记录同一食材时支持数量累加。

一键导入食谱是指从食谱详情页的“记一笔”按钮，将该食谱里所有食材一次性写入当前餐次。这个功能的实现需要注意：食谱里的食材克数是“食材毛重”，也就是处理之前的重量，比如鸡胸肉120克是生重，不能直接当作成品盘中重量。如果食谱烹饪方式写的是“清炒”，营养素会缩水一点，但这种误差在可接受范围内，不需要为了让数据精确到个位而增加一套复杂换算。

5.4 数据存储与同步策略：本地缓存优先

微信小程序不像浏览器有localStorage那样大容量，也不适合频繁写后端。我们的做法是：用户当天新加的饮食记录，先写入本地storage里一份，同时异步同步到云端；次日凌晨由云函数生成daily_summaries聚合记录。这样即使用户中途断网，本地记录也不会丢，等网络恢复后再补交到后端。

本地缓存的最大坑是字段更新后缓存结构不兼容。我上线过一版在meal_records里新增了“餐次排序”字段，结果老用户更新后读取缓存时缺字段，导致餐次展示顺序错乱。后来统一在缓存写入时加一个version标记，版本不同直接丢弃旧缓存，重新从服务端拉取，彻底解决兼容问题。

6. 我在实际开发中踩过的坑：导航栏、分包、审核与调试

6.1 微信小程序顶部导航栏高度的适配方案

健康饮食应用大量使用自定义导航栏，因为在“记录页”顶部放一个搜索框，原生导航栏的样式控制自由度不够。UniApp里开启自定义导航栏的方法是pages.json中对应页面的navigationStyle设置为custom，之后使用uni.getSystemInfoSync()获取状态栏高度（statusBarHeight），再加上胶囊按钮高度算出导航栏总高度。

这里的坑在于：不同机型胶囊按钮的位置并不完全一致，Android和iOS的胶囊按钮垂直位置计算方式不同。UniApp有一个内置组件uni-nav-bar直接兼容大部分场景，但如果你想极致可控，建议不要用这个组件，自己在页面顶部写一个view，高度为statusBarHeight + 44px（44px是微信胶囊按钮的标准占位高度），用fixed定位并用padding-top撑开内容区。菜单按钮的定位可以调用wx.getMenuButtonBoundingClientRect()拿到精确的top和height，再动态设置导航栏高度。

还有一点值得提醒：iPhone X及以上机型存在底部安全区，如果你的页面有底部提交按钮或者悬浮操作区，不要忘记加上safe-area-inset-bottom的padding，否则按钮会被Home指示条遮住一部分。UniApp里可以用env(safe-area-inset-bottom)，编译到微信小程序时是可以正常识别的。

6.2 分包与主包体积：2MB限制的具体救法

微信小程序主包体积限制是2MB，整包上限是20MB。健康饮食应用如果塞进大量食谱图片，主包很容易超。我的项目特别倒霉，一次迭代后主包直接到了2612KB，微信开发者工具编译直接报错：source size 2612kb exceed max limit 2mb。

我的解决路径依次是：先排查图片资源，食谱页卡片图全部改成云端URL，代码包内只留占位图；接着把所有非TabBar页面全部放进分包pagesSub，主包只保留tabBar四个页面和公共组件；最后把uni_modules里的图表库按需引入，只保留用到的柱状图和环形图模块。这一套组合拳下来，主包体积压缩到了1.4MB。

这里额外说一句：分包不是把pages.json里所有页面都塞进子包就完了。tabBar页面是必须放在主包里的，否则编译直接报错。另外分包之间互相跳转用uni.navigateTo时路径要写完整分包路径，别只写页面名。我遇到过从分包的食谱详情页跳转到另一个分包的记录页时，路由跳转失败，排查半天才发现分包路径少写了一层目录。

6.3 真机调试与抓包：用好Charles和代理配置

小程序调试分两段：开发者工具里主要看console和network，真机上则必须通过代理工具查请求。我在项目里用Charles比较多，配合手机代理设置可以完整看到小程序发出去的HTTPS请求，包括请求头、响应体、耗时。但真机调试有个前提：微信开发者工具里“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”这个选项，真机上默认是不生效的。所以实际测试时，要么把域名加到合法域名白名单，要么用Charles做SSL代理并安装证书。

Charles抓微信小程序的另一个细节是：小程序默认走正经的WSS和HTTPS协议，如果手机端没装Charles的SSL证书，看到的流量全是乱码。解决办法是在手机浏览器访问chls.pro/ssl下载并信任证书，然后在Charles里启用SSL Proxying并添加要抓的域名。我在Android手机上踩过一个坑：部分国产ROM需要额外在系统设置里开启“允许用户安装证书”，否则应用层信任不到Charles证书。

6.4 素材与无版权图片的坑

健康饮食应用最缺不了的就是食物图片。我在外包项目中吃过一次亏：为了赶进度直接用了某图库网站的素材，结果上线后收到律师函。从那之后，我只用三类图片：自家实拍的食谱成品图、无版权图库（比如Unsplash上标注可商用）的图片、以及微信官方素材库里的图标。食物图片尽量不要直接嵌代码包里，全部走CDN，算好图床流量。

6.5 微信审核的那些细碎规矩

审核在小程序生态里是绕不开的关卡。健康饮食类应用一般不涉及特殊类目，但有两个点很容易被打回。第一个是隐私政策，应用里收集了手机号、健康状况、饮食记录，必须在“用户隐私保护指引”里逐项声明，并且在App内提供隐私政策全文页面。第二个是“医疗健康”类目的边界问题，如果文案出现“治疗”“降血糖”“代替药物”这类词，会被平台判定为医疗建议，直接打回。我们的处理方式是把所有营养建议文案里的绝对性词汇全部改成“建议”“可参考”“请咨询专业人士”，审核一次性通过。

7. 从HBuilderX到微信开发者工具：打包、预览与上线

7.1 开发阶段：HBuilderX运行到微信开发者工具

在HBuilderX里写好代码后，点击“运行到微信开发者工具”，HBuilderX会自动编译并把产物输出到项目的unpackage/dist/dev/mp-weixin目录，同时微信开发者工具会自动打开这个目录。这里需要注意：HBuilderX和微信开发者工具必须保持版本适配，新版HBuilderX编译出来的代码，老版微信号开发者工具可能识别不了。另外微信开发者工具要开启“服务端口”，否则HBuilderX调用不起来它。

我第一次跑的时候遇到一个很诡异的现象：HBuilderX改了代码，微信开发者工具却不刷新。后来发现在HBuilderX的运行菜单里，必须选“运行到小程序模拟器”而不是“运行到浏览器”，并且把微信开发者工具里的“文件监听”开关打开。如果你用命令行方式构建项目，还需要在manifest.json里把编译模式配好，否则命令行打包的小程序默认不带vue语法转换。

7.2 上传代码、体验版与正式版发布

发布流程分三步：在HBuilderX点击“发行 -> 小程序-微信”，生成正式构建产物；然后在微信开发者工具里导入unpackage/dist/build/mp-weixin目录，点击“上传”按钮填版本号和项目备注；最后在微信公众平台的后台把刚上传的版本选为体验版，让测试人员扫码验证，没问题再提交审核。

体验版和正式版的差异一定要搞清楚：体验版只能被加入体验成员名单的人访问，适合小范围测试；正式版面向所有用户，需要微信审核。健康饮食项目里我吃过一次亏：在开发版上调试订阅消息完全正常，但上了体验版推送失败，查了半天才发现订阅消息的权限参数每次调用模板ID时要带上当前页面路径，开发版和体验版的pagepath不一样导致授权失败。

7.3 线上环境配置与域名校验

上线前必须做的三件事：第一，把请求地址全部换成https的正式域名，并配置合法域名到微信公众平台；第二，检查manifest.json里setting.urlCheck是否为true；第三，确认后端接口的SSL证书有效且CA可信任。这里有个细节很多人不知道：微信小程序合法域名不支持IP地址和带端口号的域名，如果你后端用的是云服务器IP加端口的方式，必须改成域名加443端口。

我推荐的做法是：开发环境用一个测试域名指向后端测试环境，生产环境用另一个正式域名，前后端环境通过环境变量切换。UniApp里可以在src/config/index.js里根据process.env.NODE_ENV切换baseURL，但注意打包到微信小程序后process.env.NODE_ENV不是直接可用的，需要通过条件编译或者构建时注入。

8. 隐私合规与用户信任：健康数据的特殊要求

健康饮食和普通工具类小程序最大的区别在于：它采集的是用户的健康隐私数据，包括身体指标、饮食习惯甚至可能的疾病偏好。这类数据一旦泄露，后果远比其他类型的应用严重。我在项目启动时就把隐私保护写进了需求文档，而不是后期补丁式处理。

具体落地了这么几件事：所有健康档案和饮食记录字段，在后端存储时做了加密处理，明文展示只在前端完成；用户可以在“我的”页面一键导出所有个人数据，也可以一键注销账号并删除全部历史记录。这个功能看着不起眼，却是用户信任的关键，同时也是应付监管和平台审核的硬指标。

还有一个容易被忽略的点：订阅消息推送的内容也要克制。用户授权订阅消息后，我们只在用户设定的“饮水提醒”和“晚餐建议”两个时间点各推送一条，文案用的是建议语气，不给用户造成打扰。实测下来，订阅消息的48小时有效期让推送频率天然受限，过度推送反而会消耗用户信任。

关于用户画像的年龄限制也提一下：健康饮食应用原则上可以服务未成年用户，但如果涉及疾病相关的饮食建议，必须提示“请咨询专业医师”。小程序类目审核时如果填写了医疗健康相关类目，额外的资质材料会更多，这类项目尽量避开医疗表述，专注做生活方式改善而非疾病管理。

9. 一些我能提供给你的直接建议

如果你打算直接拿这套UniApp源码去用，我强烈建议你提前想清楚三件事。

第一，不要把重心放在“拍照识别食物”这个功能上。这个功能听着炫酷，但实际上食物识别的准确率在复杂场景下很难保证，用户拍个麻辣烫识别出来一堆奇怪菜名，使用体验会非常糟糕。我们做的是“搜索 + 收藏 + 一键导入”的低门槛组合，存天然食物的门槛已经很低了。

第二，健康数据的时序聚合计算一定要和用户端解耦。用户每顿记录一条数据时，能接受少许延迟，但绝不允许卡顿。用云函数凌晨跑批，白天只读汇总表，这是所有健康类小程序的基本操作。你的后端如果用的是自己的服务器，建议用定时任务把日汇总的更新也放到业务低峰期。

第三，分享和裂变功能在设计时就要注意合规。微信生态对诱导分享查得越来越严，我们的做法是用户每累计记录7天饮食，可以生成一张“本周营养周报”的分享卡片，卡片上只有用户自己的数据摘要，不含排名、不含邀请奖励，审核完全没问题，用户自发转发的意愿反而很高。

最后还想再说一个想法：健康饮食这个领域的用户留存，拼的不是功能多，而是“让用户感觉到自己的变化”。每周给出一次营养摄入对比，每月给出一次体重趋势和饮食结构变化，比任何酷炫的动画都有说服力。技术方案只是地基，真正留下用户的是产品对用户生活触达的深度。如果这套代码能帮你把“记录饮食”这个小动作做到极致，那这个项目的价值就已经兑现了。