danyang-match/前端信息架构、路由与状态管理设计.md

# 丹阳公益婚恋服务平台
# 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
登录状态
实名认证状态
资料完成状态
审核状态
账号状态
婚恋状态
隐私状态
匹配关系
消息未读
活动报名
红娘服务
```

这些状态必须统一管理。

页面只负责：

> 展示和用户交互。

页面不能自己创造业务真相。

---

# 第一百四十二章 最终设计原则

整个前端信息架构必须做到：

> 用户进入任何页面，都不会因为账号状态错误而走进不该走的流程。

> 用户退出再回来，不需要重复填写已经完成的内容。

> 后台改变用户审核或风险状态后，前端能够及时同步。

> 所有关键业务状态只有一份可信来源。

> 页面跳转始终可预测，不形成路由迷宫。

最终标准可以概括为一句：

> **状态决定权限，权限决定路由，路由承载任务，页面只负责把当前任务做好。**