Phase 2 completed: Stream Server Auth, Database and Business API

docs/PROGRESS.md

@@ -0,0 +1,23 @@
+# Hightube 开发进度记录
+
+## 2026-03-16: Phase 2 核心后端与鉴权完成
+
+### 已实现功能：
+1.  **RTMP 流媒体服务 (Phase 1 & 2)**:
+    - 支持 OBS 推流鉴权（基于数据库中的 `stream_key`）。
+    - 支持观众通过公开的 `room_id` 进行拉流（实现推拉路径隔离，保护主播私钥）。
+    - 优化了连接断开时的日志处理。
+2.  **数据库集成**:
+    - 使用 SQLite + GORM。
+    - 实现了 `User` 和 `Room` 的数据模型与自动迁移。
+3.  **业务 API (Gin)**:
+    - `POST /api/register`: 用户注册并自动创建直播间。
+    - `POST /api/login`: JWT 鉴权登录。
+    - `GET /api/room/my`: 获取个人直播间推流码。
+    - `GET /api/rooms/active`: 发现正在直播的房间。
+4.  **工程化**:
+    - 标准的 Go `cmd/internal` 目录结构。
+    - 接入了 JWT 中间件进行接口保护。
+
+### 待验证/待办:
+- 进入 Phase 3: 开始构建 Flutter 跨平台客户端。

docs/PROJECT_PLAN.md

@@ -0,0 +1,74 @@
+# 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 美化，准备课程答辩演示。
+
+---
+*本文档将作为整个大作业项目的开发基准与进度追踪参考。*