首页底部导航与消息中心优化 · PRD

作者 Luke　版本 v1.9　日期 2026-10-06　状态 待开发评审　平台 BRAND_A & BRAND_B　类 X

模板基准 prd

模板调整说明：沿用最新版精简 PRD 骨架；本需求为纯客户端交互，保留既有 X 类，不硬套 P／R／M／S／K／W。正文合并「入口路由、消息中心、已读红点、批量删除与异常」；不重复既有公告发布与站内信后台规格。原型视觉清单依新版模板收在默认折叠附录。

L0 · 快速掌握

① 一句话需求

把消息中心提升为客户端主要入口：跑马灯只进入 Announcement 单分页；底栏 Inbox 保留既有登录限制与回跳，并以一致的逐条已读、批量删除及红点规则呈现结果。

② 术语写死表

③ 全局红线表

④ 适用范围与「不做」边界

本期做

1. 首页入口、登录路由与回跳（§1）。
2. 消息中心双态、列表、详情与返回（§2）。
3. 红点、逐条已读、批量删除及并发收敛（§3）。
4. 品牌、身份、安全与异常降级（§4）。

明确不做

1. 首页 Header、Banner、游戏大厅，以及 Promo／Deposit／Chat 的既有行为（§1）。
2. 公告／站内信发布后台、公告生效算法、站内信删除的软删／硬删实现（§4）。
3. 推广页内容与系统级监控告警（§4）。

阅读者为客户端前端、服务端与测试。

1. 入口与路由

1.1 本需求建立的入口语义

1.1.1 跑马灯从「弹窗显示公告」改为「跳公告列表」；不弹窗，也不定位或直达所点公告。

1.1.2 从跑马灯进入时，无论登录态，消息中心都只显示 Announcement 一个分页；此入口不显示 Inbox 分页。

1.1.3 底栏项目名称写死为 Inbox。未登录点击 Inbox 或 Account 进入既有注册／登录页；登录成功只回到登录状态的首页，不直接打开消息中心 Inbox 或个人中心面板。本需求只复用已上线认证流程并做回归保护，不新建认证流程。

1.1.4 登录态在点击入口当下判断；登录成功后的首页须立即呈现已登录状态，用户须再次点击 Inbox 或 Account 才进入对应目标页。

2. 消息中心

2.1 页面状态

2.1.1 返回来源页；来源失效时回首页。

2.2 列表与详情

2.2.1 进页拉最新，列表以游标滚动加载并支持下拉刷新；Tab 首次进入才拉取，之后切换只显隐，主动刷新除外。

2.2.2 列表无资料显示 No more data…；已登录站内信为空时停在 Inbox，不得自动切到公告。

3. 已读、红点与批量删除

3.1 红点矩阵

3.2 单条已读

3.2.1 点公告或站内信进入详情时，前端立即乐观清除该行红点，并提交已读请求。

3.2.2 请求成功即维持已读；明确失败才恢复红点。请求未决期间，即使下拉刷新返回 is_read=false，也不得覆盖本地乐观态。

3.2.3 未登录／公告降级态不提交公告已读；打开与返回都维持 is_read=false。

3.3 批量删除与并发

3.3.1 删除 batch 返回后，不论目前在哪个 Tab，都立即更新本地站内信资料源。

3.3.2 同一消息的删除与已读并发时，删除为终态，后到的已读不得让消息恢复可见。并发已读为幂等，任一成功即收敛为已读。

3.3.3 删除期间新下发的消息及未包含在成功 ID 的消息必须保留。

4. 资料、安全与异常

4.1 身份与资料范围

4.1.1 用户身份不得从请求参数取得；列表与详情只回必要字段，不下发他人资料或内部统计。

4.2 异常与降级

4.2.1 游标异常、翻页去重、删除 batch 空数组／上限／去重、删除底层实现及公告生效算法沿用现有平台，本需求不重定义。

5. 提示语

6. 待确认项

本版无待确认项。实现细节沿用既有的项目，不构成本需求新选型。

文档版本：v1.9 | 日期: 2026-10-06 | 作者: Luke | 文档状态：待开发评审

Home Bottom Navigation and Message Center Optimization · PRD

Author Luke　Source Version v1.9　Translation EN-1.5　Date 2026-10-06　Status Pending Development Review　Platforms BRAND_A & BRAND_B　Class X　Template Base prd

Template adjustment: Uses the current concise PRD skeleton. This is a client-only interaction requirement, so its established Class X is retained. The prototype visual inventory follows the current template and is contained in a collapsed appendix.

L0 · Quick Overview

① Requirement in One Sentence

Promote Message Center to a primary client destination: the marquee opens an Announcement-only page, while bottom Inbox retains the existing authentication and return route; all message states follow consistent per-item read, batch-delete, and badge rules.

② Fixed Terminology

③ Global Invariants

④ Scope and Explicit Exclusions

In scope

1. Home entries, login routing, and post-login return (§1).
2. Message Center states, lists, details, and Back behavior (§2).
3. Badges, per-item read state, batch delete, and convergence (§3).
4. Brand, identity, security, and failure degradation (§4).

Out of scope

1. Home Header, Banner, Game Lobby, and existing Promo/Deposit/Chat behavior.
2. Announcement/Inbox publishing backoffice, announcement-effective algorithm, and soft/hard deletion implementation.
3. Affiliate page content and system monitoring.

Readers are client frontend, backend, and QA.

1. Entry and Routing

1.1 Entry Semantics Established Here

1.1.1 The marquee changes from an announcement modal to the Announcement list. It does not open or focus the tapped announcement.

1.1.2 Regardless of authentication state, marquee entry shows Announcement as the only page/tab. Inbox is not exposed from this entry.

1.1.3 The bottom item is named exactly Inbox. A guest click on Inbox or Account enters the existing Register/Login page. After successful login, the app returns only to signed-in Home and does not directly open Message Center Inbox or the Account panel. This requirement reuses and regression-protects the live authentication flow rather than rebuilding it.

1.1.4 Authentication is checked at click time. After login, Home must immediately show the signed-in state; the user must click Inbox or Account again to enter that destination.

2. Message Center

2.1 Page States

2.1.1 Back returns to the source; if the source is invalid, return Home.

2.2 Lists and Details

2.2.1 Load the newest data on entry, use cursor-based infinite scroll, and support pull-to-refresh. Each tab loads on first use; later tab switches only reveal cached data unless explicitly refreshed.

2.2.2 An empty list shows No more data…. An authenticated empty Inbox remains on Inbox and never auto-switches to Announcement.

3. Read State, Badges, and Batch Delete

3.1 Badge Matrix

3.2 Single-item Read

3.2.1 Entering an Announcement or Inbox detail optimistically clears its row badge and submits the read request.

3.2.2 Success keeps the read state. Only explicit failure restores the badge. While the request is pending, pull-to-refresh returning is_read=false must not override the optimistic state.

3.2.3 Guest/public-fallback announcement details submit no read request and remain is_read=false after Back.

3.3 Batch Delete and Concurrency

3.3.1 Apply the delete-batch response to the local Inbox source immediately even when another tab is visible.

3.3.2 When delete and read race on one message, deletion is terminal. Concurrent reads are idempotent; any successful request converges to read.

3.3.3 Messages delivered during deletion and IDs not reported successful must remain.

4. Data, Security, and Failure Behavior

4.1 Identity and Scope

Never take user identity from request parameters. Lists and details return only necessary fields and no other-user data or internal metrics.

4.2 Failure and Degradation

Invalid cursors, page deduplication, empty/maximum/deduplicated delete-batch input, deletion implementation, and the announcement-effective algorithm reuse existing platform behavior.

5. UI Messages

6. Open Points

None. Items that reuse existing implementation are not new product decisions.

Document version: v1.9 | Date: 2026-10-06 | Author: Luke | Status: Pending Development Review