Roadmap

版本路线图

按「第一版能上线 → 把体验做厚 → 做个性化 → 做治理 → 做生态」的节奏分五个版本交付。每个版本都定义了明确的目标、交付物、验收标准、新增数据表与一个可演示的端到端链路——拒绝半成品堆砌。

交付版本
5 个
累计数据表
52 张
横向能力线
4 条
建议节奏
2–3 周/版

版本总览

五个版本的能力演进路径。V1.0 是必须一次做完的第一版;V1.1 之后按主题逐层加厚。

V1.001

第一版 · 可上线的闭环

能注册、能建社区、能无限级地组织内容、能发帖能被评论

M01 M02 M13 M03 M04 M05 M09 M08 M07
V1.102

互动与富媒体

从「能看」到「愿意留下」

M06 M11
V1.203

个性化与体验打磨

让每个社区像独立站点,让每个用户看到想看的内容

M10
V1.304

治理与运营增强

人多了以后,靠工具而不是靠人肉

M07
V2.005

开放生态与联邦

让第三方和别的社区都能接进来

M12

版本详情

点击任一版本展开完整交付规格。每个版本的 demo 字段描述了一条应当跑通的端到端链路。

贯穿始终的横向能力

安全、性能、可观测、无障碍这四类能力不属于任何单一版本,而是每个版本都必须同时交付的交付标准。把它们列出来,是为了避免被「功能优先」挤掉。

安全

V1.0 起

安全不是某个版本的功能,而是每个版本的交付标准。

  • V1.0:argon2id 密码哈希、HttpOnly 会话 Cookie、SameSite 防护、sqlx 参数化查询杜绝注入
  • V1.0:Markdown 白名单渲染,服务端净化和前端转义双保险,杜绝存储型 XSS
  • V1.0:Nginx 限流 + Rust 侧用户/设备双维度计数,抑制刷票
  • V1.1:媒体直传校验类型与大小,上传目录禁止执行任何脚本
  • V1.3:管理动作全量审计日志,不可篡改
  • V2.0:OAuth 回调白名单、Webhook HMAC 验签、API 配额与吊销

性能

V1.0 起

性能预算在需求阶段就要确定,而不是上线后优化。

  • V1.0:列表查询全部走覆盖索引,禁止 SELECT *;菜单树整体缓存进 Redis
  • V1.0:热度分数预计算写 Redis ZSet,列表不再实时聚合
  • V1.0:slug 页面按需动态加载,单 chunk gzip 后 ≤ 60KB
  • V1.1:评论分层懒加载,限制单次响应体积
  • V1.2:Meilisearch 独立进程与内存限额,不与 MySQL 争资源
  • V1.2:非首屏区块延迟水合,LCP 目标 ≤ 1.5s

可观测

V1.0 起

没有度量就没有优化,核心链路必须全埋点。

  • 请求 ID 贯穿 Nginx → Nitro → axum,日志可按 ID 串联
  • 核心接口 P50/P95/P99 分位监控与告警
  • 磁盘与内存水位告警(单机部署最容易先撑爆磁盘)
  • 业务指标看板:发帖量、评论数、投票率、次日留存
  • outbox 积压监控:待处理事件数持续增长即告警

无障碍与国际化

V1.0 起

在产品早期就纳入,事后补齐成本极高。

  • megamenu 全键盘可操作:←/→ 切换一级、Esc 关闭、Tab 自动展开
  • 菜单选中态与 aria-expanded / aria-label 齐备,屏幕阅读器可导航
  • 图片 alt 引导填写、色彩对比度校验(含社区自定义主题色)
  • 文案全部走 i18n 资源文件,不硬编码(V1.2 补全多语言)
  • 时间与数字按 locale 格式化

交付节奏

关于如何组织交付节奏的建议,避免「版本越做越大、上线越来越晚」的常见陷阱。

  • 1

    V1.0 一次性做完 9 个 P0 模块(约 8–12 周),因为「半个社区」无法验证任何假设。

  • 2

    V1.1 之后每个版本 2–4 周,前 60% 时间做功能,后 40% 做质量与打磨。

  • 3

    每个版本必须有一个可演示的端到端链路(见各版本 demo 字段),拒绝「半成品堆砌」。

  • 4

    P0 模块未达标不允许进入下一版本,避免技术债滚雪球。

  • 5

    V1.0 上线后先用小范围邀请验证核心循环,再决定 V1.1 的优先级排序。

  • 6

    V1.3 之后进入增长期,重点从「做功能」转向「做留存与治理」。