Hightube/docs/PROJECT_PLAN.md

Hightube - 开源直播平台项目文档与实现方针

1. 项目概述

Hightube 是一个针对网络应用开发课程大作业的跨平台开源个人直播平台。旨在提供用户注册、登录、开启个人直播室以及实时评论（后续迭代弹幕）等互动功能。

2. 技术栈架构与评估

2.1 客户端 (Flutter)

• 目标平台: Windows, Linux, Android, Web
• 优势: 一套代码编译多端运行，UI 表现力强且一致性好。
• 挑战: 桌面端和 Web 端的音视频采集（推流）和硬件加速播放（拉流）生态可能略逊于移动端，需仔细调研第三方插件的跨平台支持度（例如 video_player, fvp 等拉流插件；推流端前期可借用 OBS，后期再实现原生/插件推流）。

2.2 服务端 (Go 或 Rust)

• 推荐选型: Go (Golang)。
• 理由: 直播服务本质是一个处理大量高并发连接和音视频协议的网络应用。Go 的 Goroutine 并发模型非常适合处理长连接（如 WebSocket 和 RTMP 推拉流）。且 Go 拥有完善的流媒体和网络编程库，可以让你专注于业务逻辑而非底层内存管理，开发周期更贴合大作业的进度。
• 备选: Rust。性能卓越且内存安全，是极佳的加分项，但处理复杂协议的学习曲线和开发成本较高。

2.3 数据库与存储

• 关系型数据库: SQLite
• 理由: 作为课程大作业初期/MVP版本，SQLite 轻量且无需额外配置服务端即可运行。
• 扩展性设计: 直播和评论的并发写入特性，如果后续升级或实际部署，SQLite 的并发写性能可能是瓶颈。建议在后端使用 ORM 框架（如 Gorm/SeaORM），这样可以利用同一套代码在未来无缝迁移至 PostgreSQL 或 MySQL。

3. 核心架构设计

系统将分为三个主要逻辑模块：

1. API 服务 (业务后端): 处理用户认证（注册/登录/JWT）、直播间创建/配置管理、获取推流凭证（Stream Key）、以及持久化历史评论。
2. Media 服务 (流媒体中心): 核心服务。负责接收主播的音视频流（推荐使用 RTMP 协议接入），并将其分发（转封装/转码）给观众端（例如 HTTP-FLV, HLS 或 WebRTC）。初期可以将该服务与 API 服务跑在同一个进程内。
3. 互动服务 (WebSocket): 为当前活跃的直播间提供低延迟的实时评论广播和弹幕分发通道。

---

4. 阶段性迭代计划 (Roadmap)

本项目采用敏捷开发、逐步迭代的策略，从核心底层做起，直至完善前端交互。

Phase 1: 核心流媒体服务构建 (推拉流基石)

目标：跑通纯流媒体的“推、拉”数据通路，这是整个项目的核心难点。

1. 技术确认: 确定后端的开发语言与流媒体协议（首选 RTMP 接收，HTTP-FLV / HLS 分发）。
2. 服务端搭建: 实现 TCP 监听，能够解析基础的推流握手和音视频数据包包头（可手写核心逻辑或引入开源基础库辅助）。
3. 推流测试: 不写前端推流代码，直接使用第三方工具（如 OBS Studio）配置推流地址向我们的本地服务器推流。
4. 拉流测试: 不写前端播放器，直接使用本地播放器（如 VLC）或基于网页的测试工具（flv.js）测试拉取直播流。

Phase 2: 基础业务 API 与数据库搭建

目标：建立平台的基本业务逻辑和数据存储，实现账号与权限控制。

1. 数据库设计: 引入 ORM，设计基本的 users (用户表) 和 rooms (直播间表)。
2. API 开发:
   • 用户注册与登录，颁发 JWT Token。
   • 获取/重置个人专属推流密钥（Stream Key）。
   • 获取当前活跃状态的直播间列表。
3. 安全鉴权: 改造 Phase 1 的流媒体服务，在接收推流时校验推流地址中的 Stream Key 是否合法并对应正确的用户房间。

Phase 3: 客户端 MVP 版本构建 (观看端)

目标：用户可以使用我们自己的 Flutter 客户端进行注册并观看直播。

1. Flutter 框架初始化: 搭建跨端项目架构，配置网络请求拦截器（携带 Token）。
2. 基础 UI 开发:
   • 登录与注册页面。
   • 平台首页（大厅），展示通过 API 获取的直播列表卡片。
   • 直播间详情页。
3. 播放器集成: 引入并在四个平台上跑通 Flutter 视频播放插件，实现在直播间页面动态加载 HTTP-FLV 或 HLS 流媒体链接。

Phase 4: 实时互动服务 (评论系统)

目标：增加平台的社交互动性。

1. 后端 WebSocket 服务: 建立基于 room_id 的 WebSocket 广播群组（Hub 模式）。
2. 前后端联调: 客户端进入直播间后自动连接 WebSocket 服务，实现收发消息。
3. 弹幕预演: 客户端除了在底部展示聊天列表外，开始尝试利用 Flutter 的 Stack 布局机制，实现简单的文字横向漂移弹幕层。

Phase 5: 客户端开播体验 (完全体)

目标：摆脱 OBS，使用我们的应用自行调用软硬件资源进行推流开播。

1. 开播 UI: 客户端新增“主播控制台”界面。
2. 多端推流探究: 调研 Flutter 中的音视频采集和推流插件（如 flutter_webrtc 或相机结合底层编码推流库）。
3. 整体整合与测试: 对四大平台进行兼容性测试、性能调优和 UI 美化，准备课程答辩演示。

---

本文档将作为整个大作业项目的开发基准与进度追踪参考。