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