运动打卡与数据记录是产品的核心，记录方式不确定，数据就没人信
项目概览
项目背景
这是一套运动健康方向的移动产品，共 6 个仓库，覆盖 2020 至 2026 年。前端包括基于 uni-app 的跨端应用（配套 UI 组件库，含 49 个 Vue 文件）与 Objective-C 编写的 iOS 端；后端为 Java，另有 JavaScript 编写的 Node 侧服务。App 与小程序共用同一份业务接口。
客户当时的状态
运动健康类产品的核心是打卡与记录，而这类数据能不能被信任，取决于记录方式本身是否明确。如果打卡时间、来源与规则含糊，数据攒得越多反而越没人看。另一类麻烦来自端：App 与小程序都要覆盖同一套功能，各写一套的结果就是功能很快分叉——一边上了新功能另一边没有，规则改了一处另一处没跟上。此外，iOS 端是较早的技术选型，积累了历史包袱，改动前必须先判断哪些模块能碰。打卡数据的价值又是长期的：用户坚持几个月之后回看，如果记录缺了一段、或者时间对不上，产品的说服力就没了。
我们的做法与取舍
第一个取舍是把打卡口径在动手前定死。记录字段、时间来源与判定规则先确定，再写功能。代价是前期投入更多沟通，收益是数据后面可以被信任、被使用。
第二个取舍是让 App 与小程序共用同一份业务接口。两端只做展示差异，业务规则只有一份。这要求接口设计更克制，但换来了两端长期一致。
第三个取舍是iOS 端不整端重写，而是在保留既有功能的前提下按模块推进。重写看起来干净，但会引入不可控的回归，对已经在上线的产品来说代价太高。
系统怎么承载这条链路
客户端是 uni-app 跨端应用与 iOS 端；服务层承载运动打卡与记录、好友与圈子互动，以及内容可见范围的权限判断；数据层保存运动记录与互动数据。权限判断放在服务端统一处理，不依赖各端自行过滤。打卡与互动是两条独立的业务链路，但共用同一份用户数据与关系数据。
交付状态与边界
代码处于维护状态，最近一次提交在 2026 年（具体月份未披露）。边界说明：运动数据如果来自可穿戴设备，采集设备与算法由相应方案提供，我们负责接入与记录；产品提供的是记录能力，不提供医疗诊断或健康建议；应用商店的上架与审核由贵方主体提交，我们配合处理技术问题。各仓库的活跃度并不一致，这一点同样按实际情况说明。
项目信息
客户
某运动健康产品项目
行业
体育与运动科学
项目周期
未披露
技术栈
Vue + uni-app（配套 UI 组件库，49 个 Vue 文件）/ Objective-C（iOS 端）/ Java（后端）/ JavaScript（Node 后端）
服务类型
运动健康移动产品
CHALLENGES
客户当时面对的现实
好友与圈子互动涉及可见范围与关系链，权限规则不清晰会带来真实的隐私问题
App 与小程序要覆盖同一份业务，如果各自实现一套，功能很快就会不一致
iOS 端积累了历史包袱，改动前必须先判断哪些能碰、哪些不能碰
CAPABILITIES
我们交付的能力
打卡数据能不能被信任，取决于记录方式
运动打卡与记录
运动打卡与数据记录作为核心链路，记录结果可查、可回看。
好友与圈子互动
好友关系与圈子互动功能，内容可见范围按关系与设置区分。
跨端共用接口
App 与小程序复用同一份业务接口，两端只做展示差异，业务规则只有一份。
iOS 端演进
iOS 端为 Objective-C 实现，在保留既有功能的前提下按模块推进重构。
SCOPE
交付范围
以下范围按本项目实际交付内容与边界整理，不属于这次范围的部分一并列出。
已交付
- 运动打卡与数据记录功能
- 好友关系与圈子互动
- uni-app 跨端应用（含小程序形态）
- iOS 端（Objective-C）
- 后端服务与 Node 侧接口
不在本次范围
- 运动数据采集的设备与算法：如涉及可穿戴设备，由相应方案提供数据
- 健康与医疗建议：产品提供记录能力，不提供医疗诊断或建议
- 应用商店的上架与审核：由贵方主体提交，我们配合处理技术问题
ARCHITECTURE
分层技术架构
公开口径归纳为三层：客户端是 uni-app 跨端应用与 iOS 端；服务层是 Java 后端与 Node 侧接口，承载打卡、关系链与圈子；数据层保存运动记录与互动数据。
FLOW 01
客户端
uni-app 跨端应用
小程序形态
iOS 端（Objective-C）
覆盖用户实际的设备与使用入口
FLOW 02
服务层
运动打卡与记录
好友与圈子
权限判断
业务规则只有一份，两端共用
FLOW 03
数据层
运动记录存储
关系与互动数据
保证记录可查、互动范围可控
DELIVERY
交付过程
分阶段推进，每个阶段都有可验收的产出，客户在早期就能看到实际效果。
阶段一
打卡口径与规则
确定运动打卡的记录方式、数据字段与可见范围规则。
阶段二
后端与业务接口
后端服务与接口层建设，收敛打卡、关系链与圈子逻辑。
阶段三
跨端与 iOS 端落地
uni-app 跨端应用与 iOS 端接入同一份业务接口。
阶段四
互动能力与端侧整理
好友与圈子互动完善，iOS 端按模块整理历史代码。
FACTS
可核验的交付事实
以下内容来自本项目实际交付物；未经验证的指标不予展示。
6个仓库
覆盖移动端与配套服务
49个 Vue 文件
跨端应用的前端代码规模
2020–2026年
仓库覆盖的年份跨度
TRANSFER
这套做法适不适合你
案例的用处不是证明"我们做过"，而是让你判断"在我们这种条件下能不能做成"。下面三句是我们对这一单的判断，写下来供你对照自己的情况。
适合什么情况
适合同时需要 App 与小程序形态、且核心功能依赖持续记录的产品。
什么情况下别照搬
若只是单一端、功能以浏览为主，做跨端共用接口与权限模型属于过度设计。
如果要试，第一步做什么
先把打卡的记录口径与可见范围规则定下来，再谈端和界面。
RELATED SERVICES
相关服务
从实际业务问题出发，查看对应服务的适用场景、交付物与不含项；具体范围仍需单独确认。
FAQ
常见问题
以下是同类项目沟通中出现频率最高的问题，答案就是我们实际的做法。
打卡类产品最容易被忽视的是什么？
是记录本身的可信度。打卡时间、方式、来源如果不明确，数据越攒越多反而越没人用。所以我们在设计阶段就把记录口径固定下来，而不是事后补规则。
为什么 App 和小程序不各做一套？
各做一套的话，功能会以肉眼可见的速度分叉——小程序上线的功能 App 没有，App 改了规则小程序没跟上。共用业务接口是唯一能长期维持一致的做法。
iOS 端为什么用 Objective-C？
这是项目的历史技术选型决定的。我们没有为了「看起来新」而整端重写，而是在保留既有功能的前提下按模块推进，避免重写引入不可控的回归。
好友和圈子的权限怎么处理？
按关系链与用户设置区分可见范围，规则在服务端统一判断，不依赖各端自行过滤。隐私类规则放在端上是不可靠的。
现在还在维护吗？
代码处于维护状态，最近一次提交在 2026 年（具体月份未披露）。各仓库活跃度不一致，我们按实际情况说明。
本页最后更新：2026年9月24日
