Klein/Inbox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
Inbox/Go项目实战/产品需求规格说明书 (PRD) - V1.1.md
Klein 0d81c1792d 创建仓库
2025-12-11 07:24:36 +08:00

6.9 KiB
Raw Permalink Blame History

tags, aliases, date created, date modified
tags aliases date created date modified
📝 产品需求规格说明书 (PRD) - V1.1
星期日, 十二月 7日 2025, 12:14:41 中午 星期日, 十二月 7日 2025, 12:49:19 下午

📝 产品需求规格说明书 (PRD) - V1.1

更新日志:

  • v1.0: 初始版本，定义功能列表。

  • v1.1: [2025-12-07] 补充项目战略背景；优化软删除与缓存策略的灵活性；明确长文本存储类型。

项目名称: Enterprise-CMS-Core (企业级内容管理系统核心)

版本: 1.1.0

状态: [✅ 已锁定]

适用对象: 后端开发人员、架构师、测试人员

1. 项目战略概述 (Strategic Overview)

1.1 项目背景与目标

本项目并非单纯为了交付一个 CMS 软件，而是为了构建一个**“Go 语言企业级后端架构样板间”**。

  • 核心目标: 验证并固化一套“模块化整洁架构”工程实践，使其具备高可维护性、可扩展性和安全性。
  • 衍生价值: 产出的源码将作为团队未来的“SaaS 启动脚手架 (Boilerplate)”，或作为独立的高价值技术资产（源码付费产品）进行商业变现。

1.2 核心用户与价值

  • 系统管理员 (Admin): 痛点是“安全与失控风险”。核心价值是提供银行级的 RBAC 权限控制，确保没人能越权操作。
  • 内容编辑 (Editor): 痛点是“流程混乱”。核心价值是提供状态明确的内容流转机制（草稿 ->审核 ->发布），防止误发。
  • 二开开发者 (Developer): 痛点是“屎山代码”。核心价值是提供清晰的依赖边界和开箱即用的基础设施。

1.3 成功指标 (Success Metrics)

  1. 业务完整性: 必须完整支持 3 种标准角色（Admin/Editor/Subscriber）的权限隔离，且文章状态流转无逻辑漏洞。
  2. 工程质量: 核心业务模块（User/Auth）单元测试覆盖率 > 80%；通过静态代码分析，无循环依赖。
  3. 性能基线: 在单机 2C4G 配置下，并发 100 QPS 时，API P99 响应时间 < 200ms。

2. 核心功能范围 (In-Scope)

2.1 认证与鉴权模块 (Auth & IAM)

唯一来源: 必须使用 JWT 双令牌机制 + RBAC 模型。

  • F-AUTH-01 用户注册: 仅支持“用户名 + 密码”注册。密码必须经过 Argon2 或 Bcrypt 哈希存储。
  • F-AUTH-02 用户登录: 校验账号密码，返回 Access Token (短效 15min) 和 Refresh Token (长效 7 天)。
  • F-AUTH-03 令牌刷新: 使用有效的 Refresh Token 换取新的 Access Token。旧的 Refresh Token 若被复用需触发安全警报（可选）或直接失效。
  • F-AUTH-04 统一登出: 强制使 Refresh Token 失效（需在 Redis 中建立黑名单或白名单机制）。
  • F-AUTH-05 密码重置: 登录状态下修改密码，修改成功后强制吊销所有 Token。

2.2 用户与权限模块 (User & RBAC)

预设角色: 系统初始化必须包含以下三种角色。

角色代码 名称 权限描述
admin 超级管理员 拥有系统所有权限 (用户管理、角色分配、内容强制删除)。
editor 内容编辑 拥有文章发布、审核、标签管理权限。不可管理用户。
subscriber 普通用户 仅拥有修改自身资料、发布评论、查看公开文章权限。
  • F-USER-01 个人资料: 查询与更新当前登录用户的昵称、头像 URL、简介。
  • F-USER-02 用户管理 (Admin): 管理员可查看用户列表，封禁/解封用户状态。
  • F-RBAC-01 角色分配 (Admin): 管理员可修改用户的角色（如将 User 提权为 Editor）。

2.3 内容核心模块 (CMS Core)

核心逻辑: 文章必须包含状态流转。

  • F-ART-01 文章 CRUD:
    • 创建: 默认为 Draft (草稿) 状态。
    • 字段: 标题、内容、封面图 URL、作者 ID。
    • 数据类型约束: 文章内容字段在数据库层面建议使用 TEXT 或 LONGTEXT 类型，以完整承载 Markdown/HTML 长文本。
  • F-ART-02 文章状态流转:
    • 支持状态: Draft (草稿) -> Pending (待审核) -> Published (已发布) -> Archived (归档/软删除)。
  • F-ART-03 分类与标签:
    • 文章必须归属一个分类 (Category)。
    • 文章可关联多个标签 (Tags)。
  • F-ART-04 内容审核 (Editor/Admin):
    • 拥有审核权限的角色可将 Pending 状态的文章改为 Published 或驳回至 Draft。
  • F-ART-05 公开检索:
    • 仅 Published 状态的文章对外接口可见。支持按 分类、标签、标题关键词 搜索。

2.4 互动模块 (Interaction)

  • F-CMT-01 评论发布: 登录用户可对 Published 文章发表评论。
  • F-CMT-02 评论管理: 作者可删除自己文章下的评论；Admin/Editor 可删除任何违规评论。

3. 非功能性需求 (Non-Functional Requirements)

开发人员必须严格遵守以下技术约束：

3.1 数据一致性

  • 删除策略 [优化]: 核心业务数据（用户、文章）原则上必须使用 Soft Delete (deleted_at 字段)。
    • 例外条款: 涉及法律合规（如 GDPR 用户遗忘权）或垃圾数据清理时，经系统管理员明确审批操作后，允许提供物理删除接口。
  • 事务: 文章发布与标签关联必须在同一个 Database Transaction 中完成。

3.2 性能与缓存

  • API 响应: 95% 的请求响应时间需 < 200ms (不含网络延迟)。
  • 缓存策略:
    • 建议对 高频读取且低频修改 的数据（如用户信息 /profile、热门文章详情 /article/:id）实施缓存策略。
    • 具体的缓存实现（Redis Key 设计、TTL 时长、Cache-Aside 或 Write-Through 模式）由开发团队根据实际压测结果灵活调整，不强制硬编码 TTL。

3.3 安全性

  • SQL 注入: 严禁拼接 SQL，必须使用 GORM 参数化查询。
  • 敏感数据: 密码、RefreshToken 严禁明文出现在日志中。
  • 接口保护: 除登录、注册、公开文章列表外，所有接口必须通过 JWT 中间件校验。

3.4 工程规范

  • Schema: 数据库表结构变更必须提供 Up/Down SQL 迁移脚本。
  • Doc: 所有 API 必须自动生成 Swagger 文档。

4. 不在范围 (Out of Scope)

以下功能明确不包含在本次 Phase 1 开发中：

  1. ❌ 第三方登录: 不做微信/GitHub/Google 登录。
  2. ❌ 消息推送/通知: 不做系统内通知。
  3. ❌ 文件存储服务 (OSS): 仅处理 URL 字符串，不处理文件流上传。
  4. ❌ 复杂的富文本处理: 后端仅存储字符串，不解析 HTML。
  5. ❌ 支付与订单: 不包含任何电商逻辑。

5. 核心数据实体关系图 (ER 简述)

  • User (1) <-> (N) Article
  • User (1) <-> (N) Comment
  • Article (1) <-> (N) Comment
  • Article (N) <-> (1) Category
  • Article (N) <-> (N) Tag (Many-to-Many)