# 丹阳公益婚恋服务平台 # V1.0 前端信息架构、路由与状态管理设计 版本：V1.0 适用范围：微信小程序用户端、公益红娘工作台、运营管理后台 目标：统一页面组织、路由规则、登录态、审核态、婚恋状态、缓存策略、消息未读、表单草稿与异常跳转逻辑 --- # 第一章 设计目标 本文件主要解决四类问题： 1. 用户从哪里进入、下一步去哪 2. 不同账号状态下可以访问哪些页面 3. 页面之间如何统一跳转 4. 前端状态、缓存、表单草稿和消息如何管理 V1.0必须避免： - 页面之间互相乱跳 - 登录态丢失 - 审核中还能进入匹配页 - 已封禁用户仍能聊天 - 已成功牵手仍被持续推荐 - 用户填一半资料退出后全部丢失 - 消息未读数量不一致 - 页面各自维护一套用户状态 - 后台刷新页面后上下文丢失 核心原则： > **路由由状态决定，页面不能自己猜状态。** --- # 第二章 前端整体信息架构 前端分为三个独立应用域。 ```text 丹阳公益婚恋服务平台 │ ├── 微信小程序用户端 │ ├── 公益红娘工作台 │ └── 运营管理后台 ``` 三个端共享： - 用户基础数据定义 - 状态枚举 - 权限模型 - API规范 - Design Token - 部分通用业务规则 但路由和状态容器独立。 --- # 第三章 用户端信息架构 用户端一级结构保持： ```text 首页 找对象 消息 活动 我的 ``` 底部Tab只对以下用户开放： > 已登录 + 已实名 + 已完成资料 + 已审核通过 + 账号正常 其他状态用户不进入完整Tab体系。 --- # 第四章 用户端路由分层 建议将页面分成六类。 ## 4.1 启动与身份类 ```text 启动 登录 绑定手机号 实名认证说明 实名认证 ``` --- ## 4.2 新手资料类 ```text 基础资料 生活资料 照片上传 婚恋态度 择偶条件 资料确认 ``` --- ## 4.3 审核状态类 ```text 审核中 审核退回 账号受限 ``` --- ## 4.4 主业务类 ```text 首页 找对象 用户详情 我的缘分 消息 聊天 活动 公益红娘 我的 ``` --- ## 4.5 设置与辅助类 ```text 我的资料 我的择偶条件 婚恋状态 隐私设置 黑名单 系统通知 帮助中心 意见反馈 ``` --- ## 4.6 业务详情类 ```text 活动详情 活动报名 活动签到 红娘服务详情 红娘推荐 举报 解除匹配 ``` --- # 第五章 用户端路由命名建议 微信小程序目录建议： ```text pages/ launch/ login/ phone/ verification-intro/ verification/ onboarding/ basic-profile/ lifestyle/ photos/ relationship-intent/ partner-preference/ review-submit/ review/ pending/ rejected/ home/ discover/ profile-detail/ match/ messages/ chat/ activities/ matchmaker/ mine/ settings/ profile/ partner-preference/ relationship-status/ privacy/ blacklist/ notifications/ help/ feedback/ safety/ report/ restricted/ activity/ detail/ apply/ checkin/ matchmaker/ apply/ progress/ recommendation/ ``` --- # 第六章 用户端核心状态模型 前端必须维护一份统一用户状态。 建议： ```text UserState ``` 至少包含： ```text isLoggedIn hasPhone isRealNameVerified profileCompletionStatus profileReviewStatus accountStatus relationshipStatus recommendationEnabled searchVisibility matchmakerEnabled activityRecommendationEnabled ``` --- # 第七章 profileCompletionStatus 建议枚举： ```text not_started in_progress completed ``` 含义： ## not_started 未开始填写资料。 ## in_progress 已开始但未完成。 ## completed 资料已经完成，可以提交审核。 --- # 第八章 profileReviewStatus 统一枚举： ```text not_submitted pending approved need_edit rejected ``` 含义： ```text not_submitted = 尚未提交 pending = 审核中 approved = 已通过 need_edit = 需修改 rejected = 拒绝 ``` --- # 第九章 accountStatus 建议： ```text normal reviewing_risk limited suspended banned closed ``` 含义： - normal：正常 - reviewing_risk：风险审核中 - limited：部分功能限制 - suspended：暂停 - banned：封禁 - closed：账户关闭/注销 --- # 第十章 relationshipStatus 婚恋状态统一定义： ```text searching getting_to_know paused matched_successfully service_exited ``` 分别对应： ```text 正在寻找 正在了解 暂停寻找 成功牵手 退出婚恋服务 ``` --- # 第十一章 启动路由守卫 用户每次打开小程序，都先经过统一启动判断。 流程： ```text 启动 ↓ 检查本地Token ↓ Token存在？ ├─ 否 → 登录页 └─ 是 ↓ 拉取当前用户状态 ↓ 根据状态决定首页 ``` --- # 第十二章 全局路由判断顺序 建议严格按照以下优先级。 ```text 1. 是否登录 2. 是否绑定手机号 3. 是否实名认证 4. 是否完成资料 5. 是否提交审核 6. 审核结果 7. 账号风险状态 8. 婚恋服务状态 9. 正常进入业务页 ``` 不要颠倒。 --- # 第十三章 启动页状态跳转表 | 状态 | 默认进入 | |---|---| | 未登录 | 登录页 | | 已登录未绑定手机号 | 手机号绑定 | | 已绑定未实名 | 实名认证说明 | | 已实名资料未完成 | 上次未完成步骤 | | 资料完成未提交 | 资料确认 | | 审核中 | 审核中 | | 需修改 | 审核退回 | | 审核拒绝 | 审核退回/账号说明 | | 风险审核中 | 账号受限 | | 账号封禁 | 账号受限 | | 审核通过正常用户 | 首页 | --- # 第十四章 新手资料流程路由 资料填写步骤建议固定： ```text step1 基础资料 ↓ step2 生活资料 ↓ step3 照片 ↓ step4 婚恋态度 ↓ step5 择偶条件 ↓ 资料确认 ``` 系统记录： ```text onboardingCurrentStep ``` --- # 第十五章 新手流程断点续填 用户在任一步骤退出： 前端必须保存： ```text 当前步骤 已填写字段 本地草稿时间 服务端草稿状态 ``` 重新进入： > 自动回到上次未完成步骤。 不要求用户重新开始。 --- # 第十六章 草稿保存策略 建议采用： > 本地即时保存 + 服务端阶段性保存 --- ## 16.1 本地保存 每次字段修改： 可采用轻量防抖后保存。 用于： - 断网 - 临时退出 - 页面切换 --- ## 16.2 服务端保存 用户点击： > 下一步 时保存当前步骤。 这样即使换设备也可以继续。 --- # 第十七章 草稿冲突处理 如果： ```text 本地草稿更新时间 > 服务端草稿更新时间 ``` 优先本地。 如果： ```text 服务端更新时间 > 本地 ``` 优先服务端。 如差异较大： 可提示： > 检测到较新的资料版本，已为你恢复。 V1不需要做复杂版本合并。 --- # 第十八章 Tab路由规则 底部五个Tab： ```text /home /discover /messages /activities /mine ``` 只能使用： > switchTab 不能通过普通push形成多层Tab堆栈。 --- # 第十九章 Tab访问守卫 只有以下条件同时成立： ```text isLoggedIn = true isRealNameVerified = true profileReviewStatus = approved accountStatus = normal ``` 才允许进入主Tab。 否则统一重定向。 --- # 第二十章 首页状态 首页主要依赖： ```text recommendationList recommendationCursor todayViewedCount dailyRecommendationLimit relationshipStatus recommendationEnabled ``` --- # 第二十一章 首页推荐状态机 建议： ```text idle loading loaded empty finished error ``` --- ## idle 尚未请求。 ## loading 正在加载。 ## loaded 有候选人。 ## empty 暂时无候选人。 ## finished 今日推荐已浏览完。 ## error 请求失败。 --- # 第二十二章 推荐卡片操作状态 单个推荐用户关系状态： ```text neutral liked passed mutual_match blocked ``` 页面只根据关系状态展示按钮。 --- # 第二十三章 喜欢操作逻辑 点击喜欢： ```text 检查登录 ↓ 检查审核状态 ↓ 检查自身婚恋状态 ↓ 检查对方状态 ↓ 调用喜欢接口 ↓ 返回关系状态 ``` 如果： ```text mutual_match = false ``` Toast： > 已表达喜欢。 如果： ```text mutual_match = true ``` 进入双向匹配成功页。 --- # 第二十四章 喜欢防重复 前端状态： ```text likeSubmitting = true ``` 提交过程中按钮不可重复点击。 后端仍需幂等。 --- # 第二十五章 不合适状态 点击： > 不合适 状态立即： ```text passed ``` 然后切下一人。 失败时： 恢复原卡片状态并提示： > 操作失败，请重试。 --- # 第二十六章 找对象状态 需要保存： ```text discoverFilters discoverSort discoverPage discoverScrollPosition ``` 用户进入某个详情后返回： > 尽可能恢复原列表位置。 避免重新回到顶部。 --- # 第二十七章 筛选条件状态 分两层： ```text savedPreference temporaryFilter ``` --- ## savedPreference 用户“我的择偶条件”。 用于： > 系统匹配。 --- ## temporaryFilter 用户“找对象”当前临时筛选。 只影响当前浏览。 不能自动覆盖择偶条件。 --- # 第二十八章 筛选条件退出处理 用户修改临时筛选但未点击： > 查看结果 直接返回： > 不保存本次修改。 用户点击： > 查看结果 才写入当前页面状态。 --- # 第二十九章 用户详情状态 页面需要： ```text profileData relationStatus isBlocked isReported canChat ``` 底部操作根据 relationStatus 自动改变。 --- # 第三十章 用户详情访问异常 如果对方： - 被封禁 - 删除账号 - 暂停对外展示 - 已拉黑当前用户 显示： > 该用户当前不可查看。 不要显示旧资料。 --- # 第三十一章 我的缘分状态 三个列表独立缓存： ```text mutualList likedByMeList likedMeList ``` 分别维护： ```text loading hasMore cursor ``` --- # 第三十二章 消息模块状态 建议全局维护： ```text chatUnreadCount systemUnreadCount totalUnreadCount ``` Bottom Tab的消息Badge取： ```text totalUnreadCount ``` --- # 第三十三章 未读数单一来源 不能： > 聊天页自己算一个 > Tab自己算一个 > 系统通知自己算一个 统一由全局消息状态维护。 --- # 第三十四章 消息未读同步 以下场景刷新： - App启动 - 消息页进入 - 聊天消息收到 - 用户阅读聊天 - 系统通知已读 - 小程序重新回到前台 --- # 第三十五章 聊天会话状态 每个会话至少： ```text conversationId targetUserId relationStatus lastMessage lastMessageAt unreadCount canSendMessage ``` --- # 第三十六章 canSendMessage逻辑 只有： ```text relationStatus = mutual_match AND 双方账号正常 AND 双方未拉黑 AND 匹配未解除 ``` 才能发送。 --- # 第三十七章 聊天输入草稿 每个conversation保存： ```text chatDraft[conversationId] ``` 用户切换页面后再回来： > 恢复未发送文字。 --- # 第三十八章 聊天历史缓存 V1建议： > 当前会话最近一部分消息内存缓存。 长期历史： > 从服务端分页加载。 不要长期把大量聊天记录放本地Storage。 --- # 第三十九章 解除匹配后的状态更新 成功解除： ```text relationStatus = unmatched canSendMessage = false ``` 同时： - 聊天输入框禁用 - 聊天列表可转历史或隐藏 - 用户详情按钮恢复为不可聊天状态 --- # 第四十章 拉黑后的全局影响 拉黑成功后立即更新： ```text blockedUsers ``` 并从以下列表移除： - 首页推荐 - 找对象 - 喜欢列表 - 聊天列表可见关系 - 红娘普通候选 不要等下次刷新。 --- # 第四十一章 举报状态 举报后不强制拉黑。 前端保存： ```text reportedUserIds ``` 主要用于： > 防止重复误报提示。 但允许用户再次提交新的举报事项时由后端判断。 --- # 第四十二章 活动模块状态 全局/页面状态： ```text activityList myActivities activityFilters currentActivity ``` --- # 第四十三章 活动详情状态 包含： ```text activityStatus registrationStatus checkinStatus ``` --- # 第四十四章 activityStatus ```text draft registration_open registration_closed ongoing ended cancelled ``` 用户端只会看到已发布活动。 --- # 第四十五章 registrationStatus ```text not_applied pending approved rejected cancelled ``` 按钮根据状态自动变化。 --- # 第四十六章 活动报名按钮状态 | 状态 | 按钮 | |---|---| | 未报名 | 立即报名 | | 审核中 | 报名审核中 | | 已通过 | 报名成功 | | 已拒绝 | 查看原因 | | 已满 | 报名已满 | | 已截止 | 报名已结束 | --- # 第四十七章 活动签到状态 ```text not_checked_in checked_in ``` 只有： ```text registrationStatus = approved ``` 才显示签到码。 --- # 第四十八章 公益红娘状态 建议： ```text matchmakerServiceList currentService matchmakerRecommendations ``` --- # 第四十九章 红娘服务状态枚举 ```text submitted assigned in_service waiting_user completed cancelled ``` --- # 第五十章 红娘推荐状态 每条推荐： ```text pending_view viewed liked passed mutual_match expired ``` --- # 第五十一章 我的模块状态 建议用户主状态集中在： ```text UserStore ``` 包括： ```text profile verification review relationship privacy account ``` 不让“我的”页面自行维护一份独立用户数据。 --- # 第五十二章 用户资料缓存 建议： ```text currentUserProfile ``` 缓存时间可较短。 以下操作成功后立即更新： - 修改资料 - 修改择偶条件 - 修改婚恋状态 - 修改隐私 - 资料审核结果改变 --- # 第五十三章 婚恋状态全局影响 relationshipStatus变化必须立即影响： ```text 首页 推荐池 找对象曝光 系统推荐 消息提示 我的状态 红娘候选 ``` --- # 第五十四章 searching状态 允许： - 推荐 - 找对象 - 被别人看到 - 喜欢 - 红娘推荐 --- # 第五十五章 getting_to_know状态 根据： ```text recommendationEnabled ``` 决定是否继续推荐。 --- # 第五十六章 paused状态 默认： ```text recommendationEnabled = false searchVisibility = false ``` 不能继续被系统推荐。 --- # 第五十七章 matched_successfully状态 默认： ```text recommendationEnabled = false searchVisibility = false ``` 但： > 已有聊天可保留。 --- # 第五十八章 service_exited状态 关闭婚恋核心入口。 用户仍可以： - 查看账号 - 查看历史活动 - 修改隐私 - 帮助反馈 不能： - 找对象 - 喜欢 - 被推荐 --- # 第五十九章 隐私状态 建议独立： ```text PrivacySettings ``` 包含： ```text visibleInRecommendations visibleInSearch showOccupation showLifestylePhotos receiveActivityRecommendations acceptMatchmakerRecommendations ``` --- # 第六十章 隐私修改策略 用户切换Switch： V1建议： > 立即保存。 失败： 恢复原状态。 不要让用户改很多项后还需要找到页面底部“保存”。 --- # 第六十一章 全局Store建议 小程序建议至少拆： ```text AuthStore UserStore MatchStore MessageStore ActivityStore MatchmakerStore AppStore ``` --- # 第六十二章 AuthStore 负责： ```text token loginStatus phoneBinding sessionExpired ``` --- # 第六十三章 UserStore 负责： ```text profile verificationStatus reviewStatus accountStatus relationshipStatus privacySettings profileCompletion ``` --- # 第六十四章 MatchStore 负责： ```text todayRecommendations discoverFilters mutualMatches likedByMe likedMe blockedUsers ``` --- # 第六十五章 MessageStore 负责： ```text conversations chatUnreadCount systemUnreadCount totalUnreadCount ``` --- # 第六十六章 ActivityStore 负责： ```text activityList myActivities currentActivity registrationStatus ``` --- # 第六十七章 MatchmakerStore 负责： ```text services currentService recommendations ``` --- # 第六十八章 AppStore 负责： ```text appConfig networkStatus appVersion maintenanceStatus featureFlags ``` --- # 第六十九章 状态管理原则 ## 页面临时状态 放页面内部。 例如： ```text 当前弹窗是否打开 输入框当前值 当前Tab ``` --- ## 跨页面业务状态 放Store。 例如： ```text 用户审核状态 未读消息 婚恋状态 ``` --- ## 服务端真实业务状态 最终以服务器为准。 Store只是前端缓存。 --- # 第七十章 本地Storage使用边界 适合保存： ```text token 轻量用户状态 新手流程草稿 临时筛选 聊天输入草稿 已关闭的新手提示 ``` 不适合长期保存： - 身份证完整信息 - 完整聊天历史 - 敏感审核资料 - 举报证据 - 后台敏感权限数据 --- # 第七十一章 Token存储 根据微信小程序实际认证方案执行。 原则： - 不在页面参数传Token - 不写入日志 - 不暴露在错误信息 - 过期统一处理 --- # 第七十二章 Session过期处理 接口返回统一未授权状态： 前端： ```text 清除失效会话 ↓ 保留安全的本地草稿 ↓ 跳登录 ``` 提示： > 登录状态已过期，请重新登录。 重新登录后： > 尽可能恢复之前业务入口。 --- # 第七十三章 路由回跳 登录前保存： ```text redirectAfterLogin ``` 但只允许白名单内部页面。 不能接受外部任意URL。 --- # 第七十四章 审核状态变化实时处理 例如用户正在“审核中”页面。 后台审核通过后： 用户重新进入前台或主动刷新： > 自动更新状态。 然后显示： > 资料已通过审核。 按钮： > 开始寻找。 --- # 第七十五章 风控状态变化 如果用户使用过程中账号被限制： 下一次关键接口请求返回： > ACCOUNT_LIMITED 前端立即： ```text 刷新UserStore ↓ 关闭关键业务弹层 ↓ 跳账号受限页 ``` 不要继续允许交互。 --- # 第七十六章 Feature Flag V1建议预留轻量功能开关。 例如： ```text enableMatchmaker enableActivities enableImageChat enableRiskKeywordWarning ``` 但不要建设复杂远程配置平台。 用于以后灰度/临时关闭即可。 --- # 第七十七章 系统维护状态 AppStore： ```text maintenanceStatus ``` 如果维护： 显示统一页面： > 平台正在维护，请稍后再试。 不进入业务页。 --- # 第七十八章 网络状态 前端监听： ```text online offline weak_network ``` 断网时： - 已填写表单继续本地保存 - 提交操作提示网络异常 - 不直接清空当前页面 --- # 第七十九章 请求失败统一规范 业务请求错误分： ```text network_error unauthorized forbidden business_error server_error maintenance ``` 页面不直接展示后端原始message。 通过统一错误映射输出用户可理解文案。 --- # 第八十章 API错误码建议前端映射 示例： ```text AUTH_EXPIRED PROFILE_NOT_APPROVED ACCOUNT_LIMITED TARGET_UNAVAILABLE MATCH_REQUIRED ACTIVITY_FULL ACTIVITY_CLOSED ALREADY_APPLIED DUPLICATE_ACTION ``` --- # 第八十一章 PROFILE_NOT_APPROVED 统一处理： > 当前资料尚未通过审核。 并跳： > 审核状态页。 --- # 第八十二章 MATCH_REQUIRED 用户尝试访问聊天： 提示： > 双方互相喜欢后才能开始聊天。 --- # 第八十三章 TARGET_UNAVAILABLE 对方已不可用： > 该用户当前不可查看或联系。 返回上一页。 --- # 第八十四章 ACTIVITY_FULL > 本次活动报名人数已满。 刷新活动状态。 --- # 第八十五章 数据刷新策略 建议： ## 启动时 刷新： - 当前用户 - 未读数 - App配置 --- ## 首页进入 刷新： - 今日推荐摘要 --- ## 消息进入 刷新： - 会话列表 - 未读数 --- ## 我的进入 刷新： - 用户核心状态 --- # 第八十六章 页面缓存策略 适合保留： - 找对象滚动位置 - 筛选条件 - 首页当前推荐位置 - 活动列表当前位置 不建议强缓存： - 用户详情 - 风险状态 - 审核状态 这些应较新。 --- # 第八十七章 页面返回行为 例如： ```text 找对象 → 用户详情 → 返回 ``` 恢复： - 原筛选条件 - 原列表 - 原滚动位置 --- # 第八十八章 Tab再次点击行为 再次点击当前Tab： V1可以保持当前位置。 不强制： > 自动滚到顶部。 以后如有需要再增加。 --- # 第八十九章 用户退出登录 点击退出： 二次确认。 成功： ```text 清除Token 清除用户敏感缓存 清除消息缓存 保留非敏感App设置 跳登录 ``` --- # 第九十章 注销账户 与退出登录不同。 注销属于后端业务。 前端不可只清缓存。 必须走： > 账号注销流程。 --- # 第九十一章 红娘端路由架构 建议： ```text /login /workbench /service-requests /service/:id /candidates/:userId /my-users /follow-ups ``` --- # 第九十二章 红娘端权限守卫 进入任何业务路由前检查： ```text isLoggedIn role organization accountStatus permission ``` --- # 第九十三章 红娘端状态容器 建议： ```text AuthStore OperatorStore ServiceStore UserSearchStore AppStore ``` --- # 第九十四章 红娘工作台上下文 进入服务详情： 必须保存： ```text serviceId userId assignedMatchmakerId serviceStatus ``` 刷新页面后重新从URL参数恢复。 不要只放内存。 --- # 第九十五章 红娘候选人筛选状态 保存： ```text candidateFilters candidateSort candidatePage ``` 从候选详情返回： > 恢复原位置。 --- # 第九十六章 后台路由架构 建议： ```text /login /dashboard /users /users/:id /reviews /reviews/:id /matches /match-rules /matchmaker-services /matchmakers /activities /activities/new /activities/:id /activities/:id/registrations /activities/:id/checkin /reports /reports/:id /organizations /operators /roles /analytics /settings ``` --- # 第九十七章 后台路由权限 每个Route绑定： ```text permissionCode ``` 例如： ```text /users/:id → user.view ``` ```text /reviews/:id → review.process ``` ```text /reports/:id → risk.report.view ``` --- # 第九十八章 前端权限不能代替后端权限 前端隐藏按钮只是： > 用户体验。 真正权限必须由后端校验。 即使用户手动访问URL： > 无权限仍拒绝。 --- # 第九十九章 后台菜单生成 建议根据： ```text currentOperator.permissions ``` 动态生成菜单。 用户无权限： > 不显示对应一级菜单。 --- # 第一百章 后台刷新页恢复 由于PC后台用户会刷新浏览器： 所有核心详情页必须通过： > URL参数重新获取数据。 不能依赖： > 上一个页面传递的临时对象。 --- # 第一百零一章 后台筛选状态 列表筛选建议同步到URL Query。 例如： ```text /reviews?status=pending&page=2 ``` 这样： - 刷新不丢 - 返回不丢 - 可以复制内部链接 --- # 第一百零二章 小程序页面参数原则 只传： ```text userId activityId serviceId conversationId ``` 不要在URL携带： - 姓名 - 身份证 - 完整资料JSON - 敏感业务状态 进入页面后再请求数据。 --- # 第一百零三章 全局事件机制 V1应避免大量EventBus。 跨模块变化优先： > 更新Store。 例如： 用户拉黑： ```text MatchStore更新 MessageStore更新 ``` 而不是发送十几个自定义事件。 --- # 第一百零四章 WebSocket/实时消息建议 如果聊天采用实时通信： 连接状态放： ```text MessageStore.connectionStatus ``` 状态： ```text disconnected connecting connected reconnecting ``` --- # 第一百零五章 实时消息断线 断线后： 自动重连。 重连成功： 根据： ```text lastSyncCursor ``` 补拉遗漏消息。 避免重复消息。 --- # 第一百零六章 消息去重 每条消息必须有： ```text messageId ``` 前端收到实时消息和补拉消息时： 以messageId去重。 --- # 第一百零七章 消息发送状态 本地消息： ```text sending sent failed ``` 发送失败： 显示： > 发送失败，点击重试。 --- # 第一百零八章 时间状态 聊天、通知、跟进等时间： 统一由前端格式化。 例如： 今天： > 10:32 昨天： > 昨天 更早： > 8月28日 后台： > 2026-08-28 10:32 --- # 第一百零九章 本地时区 所有服务端时间建议统一标准存储。 前端展示： > 用户当前本地时区。 V1主要服务丹阳，本地业务仍需避免服务端、数据库和前端各自混乱处理时间。 --- # 第一百一十章 页面Loading原则 首次加载： > Skeleton。 局部更新： > 局部Loading。 提交： > Button Loading。 不要： > 页面每次操作全部白屏重载。 --- # 第一百一十一章 乐观更新使用范围 适合： - 喜欢 - 不合适 - 隐私Switch 但失败必须回滚。 --- # 第一百一十二章 不适合乐观更新 以下必须等待服务端确认： - 实名认证 - 资料审核提交 - 活动报名 - 成功牵手确认 - 封禁 - 举报处理 --- # 第一百一十三章 表单状态结构 统一： ```text values errors touched dirty submitting ``` 避免每个表单页面自定义一套混乱逻辑。 --- # 第一百一十四章 表单离开提醒 首次资料填写： > 自动保存，无需每次提醒。 后台复杂编辑： 如果有未保存修改，离开时： > 你有未保存的修改，确定离开吗？ --- # 第一百一十五章 图片上传状态 每张图片： ```text local uploading uploaded failed review_pending ``` --- # 第一百一十六章 图片草稿 用户选了图片但上传失败： 本地显示失败状态。 允许： > 点击重试。 不要让用户重新选择所有图片。 --- # 第一百一十七章 审核后图片状态 一旦头像需要修改： 前端在我的资料中： > 清晰标识该图片需修改。 不要整个资料页只显示“审核不通过”。 --- # 第一百一十八章 App配置 服务端可返回轻量配置： ```text dailyRecommendationLimit maxProfilePhotos maxInterestTags chatImageEnabled activityEnabled matchmakerEnabled supportContact ``` 避免关键运营参数硬编码。 --- # 第一百一十九章 配置读取失败 使用安全默认值。 不要因为配置接口失败导致： > 整个小程序打不开。 --- # 第一百二十章 埋点状态 V1建议预留基础Analytics接口。 关键事件： ```text login_success verification_success profile_submit review_approved recommendation_view like_click mutual_match chat_started matchmaker_apply activity_apply activity_checkin relationship_success ``` --- # 第一百二十一章 埋点原则 不得上报： - 身份证 - 聊天正文 - 完整手机号 - 私密照片 - 举报证据 只记录必要事件与匿名业务ID。 --- # 第一百二十二章 推荐核心漏斗 前端埋点对应： ```text 推荐曝光 ↓ 查看详情 ↓ 喜欢 ↓ 双向匹配 ↓ 开始聊天 ``` 用于后续判断： > 哪一步用户流失。 --- # 第一百二十三章 用户主流程状态图 ```text 未登录 ↓ 已登录 ↓ 已绑定手机号 ↓ 已实名 ↓ 资料填写中 ↓ 资料完成 ↓ 审核中 ↓ 审核通过 ↓ 正在寻找 ↓ 互相喜欢 ↓ 沟通 ↓ 正在了解 ↓ 成功牵手 ``` --- # 第一百二十四章 状态不可逆与可逆 ## 不可随意回退 ```text 未实名 → 已实名 审核通过 → 未提交 ``` 不能前端自行改变。 --- ## 可逆状态 ```text 正在寻找 ↔ 暂停寻找 ``` 由业务规则控制。 --- # 第一百二十五章 状态变更单一入口 前端不能： ```text UserStore.relationshipStatus = success ``` 直接赋值。 必须通过： ```text updateRelationshipStatus() ``` 请求服务端后再更新Store。 --- # 第一百二十六章 推荐的前端状态更新模式 ```text Action ↓ API ↓ Server Result ↓ Store ↓ UI ``` 简单、清晰。 --- # 第一百二十七章 不建议V1引入的复杂方案 V1不要为了“技术先进”引入： - 复杂前端微服务 - 微前端 - Event Sourcing前端实现 - 大量全局事件总线 - GraphQL缓存系统 - 离线优先复杂同步 - 多套状态库共存 --- # 第一百二十八章 技术实现要求 无论最终采用： - 原生微信小程序 - Taro - uni-app 都必须保持： > 一套清晰Store + 一套路由守卫 + 一套API层 + 一套错误处理。 --- # 第一百二十九章 推荐前端分层 ```text pages ↓ features ↓ stores ↓ services ↓ components ↓ theme ↓ utils ``` --- # 第一百三十章 services层 建议： ```text services/ auth user profile match message activity matchmaker safety ``` 页面不直接调用底层request。 --- # 第一百三十一章 API统一请求层 统一处理： - Token - 超时 - 错误码 - 重试 - 日志脱敏 - Session失效 - 维护状态 --- # 第一百三十二章 推荐目录结构 ```text src/ pages/ components/ features/ stores/ services/ theme/ utils/ constants/ types/ ``` 后台和红娘端可采用类似分层。 --- # 第一百三十三章 constants目录 统一存放： ```text routeNames statusEnums permissionCodes storageKeys businessLimits ``` 不要把状态字符串散落页面。 --- # 第一百三十四章 types目录 统一： ```text User Profile PartnerPreference MatchRelation Conversation Activity MatchmakerService Report ``` --- # 第一百三十五章 路由验收标准 必须测试： 1. 未登录直接访问用户详情 2. 未实名直接访问首页 3. 审核中打开找对象 4. 封禁用户打开聊天 5. 已成功牵手进入首页 6. Token过期期间填写资料 7. 从聊天返回消息列表 8. 从用户详情返回找对象列表 每种都必须有明确结果。 --- # 第一百三十六章 状态验收标准 必须保证： > 用户状态只有一个真实来源。 例如： 不能出现： 首页显示： > 正在寻找 我的显示： > 暂停寻找。 --- # 第一百三十七章 未读数验收 必须确保： ```text Tab Badge 消息列表 系统通知 聊天详情 ``` 四处数据一致。 --- # 第一百三十八章 草稿验收 测试： 用户填写到： > 资料3/5 直接关闭微信。 重新打开： > 自动进入3/5，并保留已填内容。 --- # 第一百三十九章 弱网验收 弱网下： - 按钮不能重复提交 - 图片上传失败可重试 - 已填写表单不丢 - 推荐加载失败有重试 - 聊天发送失败有明确状态 --- # 第一百四十章 权限验收 红娘和后台必须测试： - 无权限菜单不显示 - 手动输入URL仍被拒绝 - 敏感信息默认脱敏 - 查看敏感字段留下日志 --- # 第一百四十一章 V1.0前端架构核心结论 用户端核心状态： ```text 登录状态 实名认证状态 资料完成状态 审核状态 账号状态 婚恋状态 隐私状态 匹配关系 消息未读 活动报名 红娘服务 ``` 这些状态必须统一管理。 页面只负责： > 展示和用户交互。 页面不能自己创造业务真相。 --- # 第一百四十二章 最终设计原则 整个前端信息架构必须做到： > 用户进入任何页面，都不会因为账号状态错误而走进不该走的流程。 > 用户退出再回来，不需要重复填写已经完成的内容。 > 后台改变用户审核或风险状态后，前端能够及时同步。 > 所有关键业务状态只有一份可信来源。 > 页面跳转始终可预测，不形成路由迷宫。 最终标准可以概括为一句： > **状态决定权限，权限决定路由，路由承载任务，页面只负责把当前任务做好。**