核心交付:
- 新建 MeetingLifecycleService(6 钩子 + sync.Map 本地 timer + Redis key 双保险 + RescheduleFromRedis)
- 新建 MeetingCleanupTask(启动重建 timer + 每 N 秒扫 host_grace/empty_ttl 兜底 + 4h stale active 回收)
- MediaOrchestrator 新增 ResolveRouterID;HTTPMediaOrchestrator.CreateRouter 入口 sync.Map 幂等防御
- 业务层 JoinRoom 移除 CreateRouter 调用改走 CancelEmptyTTL + ResolveRouterID;LeaveRoom 空房分支改调 OnAllMembersLeft 不再立即销毁
- MeetingSignalService 新增 OnWSDisconnect 实现 ws.MeetingDisconnectHook;OnRoomJoin 追加 host 重连钩子
- ws.handler 定义 MeetingDisconnectHook 接口 + SetMeetingDisconnectHook,解耦 ws→meeting 反向依赖
- config 新增 MeetingConfig{HostGrace=120, EmptyRoomTTL=300, CleanupInterval=30, StaleRoomHours=4}
关键设计决策:
- Redis key TTL = 业务时长 + max(CleanupIntervalSeconds*2, 30s) buffer:避免本地 timer 与
Redis 自动过期同步到期导致 DEL 返回 0 被误判为"已被其他路径处理"而跳过业务逻辑
- Router 幂等双层防御(决策 q2_router_dedup=a2_both):业务层不重复调 + HTTP 层 sync.Map 命中直接返回
- 普通成员 WS 断开仅清 media 资源不动 participant 表(决策 q1_nonhost_disconnect=a1_keep_current)
E2E 验证:docs/verify/meeting_t8_verify.mjs PASS=20 FAIL=0,覆盖 5 场景:
- S1 host 宽限期过期自动转让(meeting.host.changed + DB host_id 更新)
- S2 宽限期内重连保留身份
- S3 empty_ttl 期内新成员加入复活房间
- S4 empty_ttl 过期 → 房间 Ended + 新 join 被拒
- S5 CreateRoom +1 Router / JoinRoom 不再创建新 Router(通过 media-server /internal/info stats.routers 断言)
media-server:/internal/info 响应追加 stats.routers + routers[] 供 E2E 断言 Router 幂等
文档同步:
- docs/progress/CURRENT_STATUS.md 头部 + 新增 Task 8 交付条目
- docs/plans/2026-04-21-phase2e-2-implementation.plan.md Task 8 标记完成 + 实际产出/决策/验证
- docs/api/frontend/meeting.md 补充 host.changed.auto_reason / room.ended.reason=system_error / 空房 TTL 复活语义 + Task 8 验证记录
- docs/architecture/system-architecture.md meeting 模块职责补充"会议生命周期状态机"
- .cursor/rules/project-context.mdc 追加 Task 8 条目并更新 Phase 2e-2 进度(Task 0-8 ✅)
Made-with: Cursor
46 KiB
46 KiB
Phase 2e-2 实施计划:会议 MVP(多人音视频)
状态: 📋 待执行(设计文档定稿后进入代码开发) 设计文档: Phase 2e-2 设计文档 上级路线图: Phase 2e 整体路线图 分支:
feature/phase2e-2-meeting-mvp预估总工时: 约 17 人日(17 个 Task,含 PoC 与 UI 打磨) 最后更新: 2026-04-21(Task 0-8 ✅ 已落地,会议生命周期状态机 E2E 20/20 PASS,下一步 Task 9 前端 mediasoup-client 接入)
一、范围锁定
本期交付(与设计文档 §2.2.1 一一对应)
- 即时会议创建 / 加入 / 离开 / 结束 / 列表 / 详情
- 会议号
XXX-XXX-XXX+ 可选密码(bcrypt)+ 邀请链接 + 通知中心邀请(meeting_invite) - 入会前设备预览页(设备选择 + 本地预览 + 音量检测)
- ≤ 8 人音视频(mediasoup SFU + simulcast 3 档)
- 主持人四件套:静音他人 / 移除成员 / 转让主持人 / 结束会议
- 会议生命周期:host 掉线 2 分钟宽限 + host 转让(最早加入者)+ 空房 5 分钟 TTL
- 会议内文字聊天(独立
meeting_chats表,24 小时后清理) - 响应式布局:桌面 3×3 / 平板 2×2 / 手机 单列+抽屉
- 双态部署:本机 Docker Compose + 公网
announcedIp+ coturn--profile public
显式推迟(与设计文档 §2.2.2 一一对应)
预约会议 / 提醒 / 等候室 / 锁定 / 屏幕共享 / 录制 / 虚拟背景 / 联合主持人 / 管理端会议管理 / 多 Worker 集群。
二、Task 依赖拓扑
flowchart LR
T0[Task 0 mediasoup PoC Spike] --> T1[Task 1 media-server 骨架]
T1 --> T2[Task 2 Node 9 个 REST API]
T0 --> T3[Task 3 数据库 DDL]
T3 --> T4[Task 4 Go meeting 模块骨架]
T4 --> T5[Task 5 会议 REST 接口]
T4 --> T6[Task 6 WS 信令处理器]
T2 --> T7[Task 7 Go-Node HTTP Client]
T6 --> T7
T5 --> T8[Task 8 生命周期状态机]
T2 --> T9[Task 9 前端 mediasoup-client + Store]
T5 --> T10[Task 10 前端预览/创建/加入页]
T9 --> T11[Task 11 会议室主页]
T11 --> T12[Task 12 会议内聊天面板]
T5 --> T13[Task 13 meeting_invite 通知对接]
T11 --> T14[Task 14 docker-compose + 双态配置]
T11 --> T15[Task 15 UI/UX 打磨]
T15 --> T16[Task 16 E2E + 代码审查 + 文档同步]
T12 --> T16
T13 --> T16
T14 --> T16
T8 --> T16
关键路径:T0 → T1 → T2 → T9 → T11 → T15 → T16(≈ 9 人日) 并行机会:T3/T4 可与 T1/T2 并行;T10/T13 可与 T11 并行;T14 可与 T15 并行。
三、文件与变更清单概览
3.1 新建子项目
media-server/—— 根级子项目(与backend//frontend//admin/并列)src/app.ts/src/config.tssrc/mediasoup/{worker.ts, router.ts, codecs.ts}src/routes/{router,transport,producer,consumer}.route.tssrc/services/{router,transport,producer,consumer}.service.tssrc/middlewares/internal-auth.tssrc/utils/logger.tstests/*.spec.tspackage.json/tsconfig.json/Dockerfile/.env.example
3.2 后端新增(backend/go-service/app/meeting/)
| 文件 | 作用 |
|---|---|
constants/{meeting_status,meeting_role,ws_events}.go |
常量 |
model/{meeting_room,meeting_participant,meeting_chat}.go |
GORM 模型 |
dao/{meeting_room_dao,meeting_participant_dao,meeting_chat_dao}.go |
DAO |
service/meeting_service.go |
房间 CRUD + 生命周期 |
service/meeting_signal_service.go |
WS 信令处理 |
service/meeting_chat_service.go |
会议内聊天 |
service/node_client.go |
Go → Node HTTP 客户端 |
service/interfaces.go |
对外注入接口(NotifyPusher / UserInfoResolver) |
controller/{meeting_controller,meeting_chat_controller}.go |
REST Controller |
controller/meeting_ws_handler.go |
WS 事件处理(注册到 ws.Hub) |
router/meeting_router.go |
路由注册 |
task/meeting_cleanup_task.go |
定时任务:空房 TTL 兜底 + chat 24h 清理 |
provider/{provider,wire_gen}.go |
Wire |
3.3 后端改造
| 文件 | 改动 |
|---|---|
app/provider/wire.go |
注册 MeetingSet;绑定 meetingService.NotifyPusher = notifyService、meetingService.UserInfoResolver = userService、ws.Hub.MeetingSignalDispatcher = meetingSignalService |
app/provider/provider.go |
App 新增 MeetingController / MeetingChatController / MeetingCleanupTask |
cmd/server/main.go |
启动 app.MeetingCleanupTask.Start() + defer Stop() |
router/router.go |
注册 meeting 路由 |
app/ws/hub.go / app/ws/handler.go |
新增 MeetingSignalDispatcher 接口注入;WS 断线时触发 meeting.OnUserDisconnect |
deploy/docker/postgres/init.sql |
追加 meeting_rooms / meeting_participants / meeting_chats DDL + 索引 |
app/dto/meeting_dto.go |
请求 / 响应 DTO |
3.4 前端新增(frontend/src/)
| 文件 | 作用 |
|---|---|
api/meeting.js |
REST API 封装 |
constants/meeting.js |
会议类型 / 角色 / WS 事件常量 |
store/meeting.js |
Pinia Store |
utils/mediasoup-client.js |
Device/Transport/Producer/Consumer 封装 |
pages/meeting/{index,create,join,preview,room}.vue |
5 个页面 |
components/meeting/{VideoTile,VideoGrid,MeetingToolbar,MemberPanel,ChatPanel,InviteDialog,DevicePreview,NetworkBadge}.vue |
8 个组件 |
3.5 前端改造
| 文件 | 改动 |
|---|---|
pages.json |
新增 5 条 page 注册 |
utils/ws.js |
增加 meeting 事件分发 |
components/NotifyItem.vue |
meeting_invite 卡片补齐「立即加入 / 稍后」 |
store/notify.js |
meeting_invite 点击跳转 /pages/meeting/preview?code=xxx |
3.6 Docker / 脚本
| 文件 | 改动 |
|---|---|
deploy/docker-compose.dev.yml |
新增 media-server 服务;新增 coturn 服务(profiles: [public]) |
scripts/start.sh |
增加 media 子命令(启动 media-server)与 full 子命令(全部服务) |
scripts/stop.sh |
对应 stop |
scripts/status.sh |
增加 media-server 进程/容器检测 |
scripts/deploy-public.sh(新建) |
公网部署快捷脚本(校验 announcedIp、端口开放) |
.env.example / .env.local.example |
新增 MEDIASOUP_* / MEDIA_INTERNAL_TOKEN / TURN_* |
四、Task 明细
Task 0:mediasoup PoC Spike ✅
- 状态:✅ 已完成(2026-04-21)
- 目标:在正式动工前用最小代码跑通"2 个浏览器 ↔ Node ↔ mediasoup ↔ 互相看见视频",验证技术栈可用性与关键参数
- 依赖:无(起点)
- 实际产出:
media-server/poc/:Fastify + WS 信令 + mediasoup Worker/Router 约 500 行代码server.mjs(248 行)+public/client.mjs(215 行)+public/index.html- 依赖固定版本:
mediasoup@3.14.11/fastify@4.28.1/@fastify/websocket@10.0.1/pino@9.3.2,Node 24 下 C++ 编译 53 秒完成 - PoC 结论文档:
media-server/docs/poc-notes.md(9 章节:架构图 / 实测数据 / 7 项关键坑 / 技术栈判定 / 复用映射 / 启动步骤)
- 实测数据(Playwright 双 tab 自动化验证):
- 2 人会议:4 transports / 4 producers / 4 consumers / RSS 61MB
- 线性外推 8 人会议:16 transports / 16 producers / 112 consumers / 约 200MB RSS(Node 单进程毫无压力)
- peer 关闭后资源自动清理(consumers 从 4 → 0),无泄漏
- 已锁定的关键坑:
- 本机 Demo
MEDIASOUP_ANNOUNCED_IP必须留空(非127.0.0.1),让 Chromium 自动替换0.0.0.0为可用地址 - mediasoup-client 无 UMD bundle,PoC 走
esm.shCDN;Task 9 正式前端改用npm + vite - Consumer 必须以
paused:true创建,客户端transport.consume后再调resumeConsumer,否则首帧丢失 - Worker
died事件必须监听 + 外部进程管理器重启
- 本机 Demo
- 决策结论:维持 mediasoup + fastify + mediasoup-client 选型,不改用 livekit-server。技术栈可用性已满足 MVP 需求。
- 工作量:1 人日(实际用时吻合估算)
Task 1:media-server 项目骨架
- 状态:✅ 已完成(2026-04-21)
- 目标:创建正式
media-server/目录,包含 TS 配置、Fastify 入口、日志、中间件、Dockerfile - 依赖:T0
- 实际产出:
media-server/package.json— 锁定(已在同日升级至 v5 生态)mediasoup@3.19.0 / fastify@5.8.5 / fastify-plugin@5.1.0 / @fastify/sensible@6.0.4 / @fastify/websocket@11.2.0 / pino@9.3.2 / zod@3.23.8;开发链:tsx / typescript@5.5 / eslint / prettier / vitestmedia-server/tsconfig.json+tsconfig.build.json— TS 5.5 严格模式、ES2022 + Bundler 解析media-server/.eslintrc.json+.prettierrc— @typescript-eslint + prettier 协同,强制consistent-type-importsmedia-server/.env.example+.gitignore+.dockerignore— 双态部署环境变量模板media-server/src/config.ts(110 行)— dotenv 加载 + zod 严格校验 + 端口区间交叉校验 + 校验失败process.exit(1)media-server/src/utils/logger.ts(45 行)— pino + pino-pretty(dev 可选)+ token redact +childLoggermedia-server/src/mediasoup/worker.ts(115 行)— Worker 单例 +died事件指数退避重启(1s → 30s 封顶)media-server/src/middlewares/internal-auth.ts(55 行)—fastify-plugin包装 onRequest hook +timingSafeEqual防侧信道 +/healthz//readyz白名单media-server/src/app.ts(125 行)— Fastify 入口 +/healthz+/readyz(未就绪 503)+/internal/info+ 优雅停机(SIGINT/SIGTERM/unhandledRejection/uncaughtException)media-server/Dockerfile— 多阶段(node:20-bookworm-slim),builder 装 python3 + build-essential 编译 mediasoup worker,runtime 裁 dev deps + 非 root 用户 + curl HEALTHCHECK + 显式暴露40000-40199/UDP+TCPmedia-server/README.md— 目录结构 / 快速开始 / 鉴权校验 / Docker 构建 / 配置说明 / Task 1 验收清单
- 实测验收(已通过):
npm install成功(315 包,mediasoup C++ worker 编译通过)npm run typecheck0 错误、npm run lint0 错误npm run dev→ 2s 内 "media-server listening"curl /healthz→{"ok":true,"mediasoupVersion":"3.19.0","workerPid":<pid>,"workerRestartAttempts":0}curl /readyz→{"ready":true}- 未带/错误
X-Internal-Token→ HTTP 401;正确 token → 200 返回 mediasoup 版本 / worker 状态 kill -9 <workerPid>→ 1s 后自动拉起新 Worker(PID 变更),日志出现 "worker died" → "worker started"
- 关键决策:
- Fastify 5 + 单 pino 实例:首轮骨架先用 v4 跑通,发现 Fastify 4 已过 LTS(2025-06-30)且无
loggerInstance导致两个 pino 实例;同日升级至 fastify@5.8.5,回归单实例 + 官方维护版本,插件(@fastify/websocket 11 / @fastify/sensible 6 / fastify-plugin 5)已 GA 支持 v5 - mediasoup 3.19 类型从
mediasoup/types子路径引入(Worker/WorkerLogLevel) - 内部鉴权使用
timingSafeEqual替代===,对长度不等先拉齐再比,防 token 长度时序探测 - Worker 指数退避
1s → 2s → 4s → 8s → 16s → 30s(封顶),重启成功后restartAttempts归零 - Fastify 5 破坏性变更逐条核查通过:Node ≥20(Dockerfile 已满足)/ schema 完整 JSON Schema(Task 2 配合 zod)/
.listen()对象签名 / plugin 纯 async
- Fastify 5 + 单 pino 实例:首轮骨架先用 v4 跑通,发现 Fastify 4 已过 LTS(2025-06-30)且无
- 工作量:0.5 人日(实际用时吻合估算,含 Fastify 4→5 升级 30 分钟)
Task 2:Node 侧 9 个 REST API ✅(2026-04-21 完成)
- 目标:实现设计文档 §7.2 的 9 个接口,mediasoup 资源完整生命周期
- 依赖:T1
- 实际产出:
src/schemas/{common,router,transport,producer,consumer}.schema.ts(5 文件,zod schema 全覆盖 body/params/DTLS fingerprints)src/utils/errors.ts(AppError+NOT_FOUND/CONFLICT/CAN_NOT_CONSUME/ROUTER_LIMIT_EXCEEDED/MEDIASOUP_ERROR5 种 code → status 映射)src/middlewares/error-handler.ts(ZodError → 400 VALIDATION_ERROR / AppError → 对应 status / Fastify 4xx 透传 / 未知 → 500 INTERNAL_ERROR)src/mediasoup/codecs.ts(opus + VP8 + H264 三种RouterRtpCodecCapability)src/services/{router,transport,producer,consumer}.service.ts(4 文件,Map + observer-close 自清理;Consumer 还监听producerclose级联关闭)src/routes/{router,transport,producer,consumer}.route.ts(4 文件,9 接口均手动调.parse()+ 调用对应 service)src/app.ts注册 errorHandler + 以/internal/v1前缀挂载路由vitest.config.ts+tests/setup.ts+tests/{schemas,errors,app}.spec.ts+tests/services/{router,transport,producer,consumer}.service.spec.ts(7 个 spec 共 58 个测试)
- 检查点实测通过:
- ✅
typecheck/lint0 错误 - ✅
npm test:58/58 passed(约 900ms);覆盖率 stmts 80.89% / branches 76.03% / funcs 90.9% / lines 80.89%(>> 60% 目标) - ✅ 9 接口 happy path:
curl依次 POST /routers → POST /transports(send+recv)→ DELETE /routers/:id 全部 201/200 - ✅ 错误路径:unknown router→404 NOT_FOUND / produce on recv transport→409 CONFLICT / delete unknown producer→404 / resume unknown consumer→404 / lowercase roomCode→400 VALIDATION_ERROR(含 fieldErrors)/ 缺 token→401 UNAUTHORIZED
- ✅ 资源释放:DELETE router 后
routerMap.size === 0,observer.once('close') 同步清理 map
- ✅
- code-reviewer 子代理修复(2026-04-21):
- M1
_clearXxxMap→ 新增src/utils/test-guard.ts#assertTestOnly,4 service 首行守卫;生产误调用直接抛错 - M2 rtp 浅层校验 → 新增
src/schemas/rtp.ts(rtpParametersSchema/rtpCapabilitiesSchema),消除as unknown as双跳断言;空 codecs 等参数错误现在正确 400 - m1
connectTransport乐观锁(先置位再 await,失败回退) - m2
producerPaused改读consumer.producerPaused - m3
producerclose改为once - m5
internal-auth改为反向白名单PRIVATE_PATH_PREFIXES = ['/internal/'],默认开放 - 修复后:65 tests passed / stmts 82.87% / branches 75.83% / funcs 91.3%;
internal-auth.ts覆盖率 100%;schemas/rtp.ts覆盖率 100% - 其余 Minor / Nits(m4/m6
m10、n1n10)登记至CURRENT_STATUS.mdTask 16 收尾清单
- M1
- 工作量:2 人日(实际用时吻合估算;审查修复耗时 ~0.3 人日,已含在内)
Task 3:数据库 DDL + 模型 + DAO ✅
- 目标:PostgreSQL 3 张表落地 + Go 侧 model/dao 完整实现
- 依赖:T0
- 主要产出:
deploy/docker/postgres/init.sql追加 3 张表 + 9 索引 + COMMENT(对齐设计 §5.1)deploy/docker/postgres/phase2e2_migration.sql增量升级脚本(IF NOT EXISTS幂等,用于已运行环境无损追加)backend/go-service/app/meeting/model/{meeting_room,meeting_participant,meeting_chat}.go(3 个 model + GORM 复合索引 tag +IsActive()等辅助方法)backend/go-service/app/meeting/dao/*.go(24 个持久化方法:room 9 + participant 11 + chat 4,含JoinRoom重入复用事务、TransferHost角色交接事务、LeaveRoom基于EXTRACT(EPOCH ...)的 DB 端 duration 计算、FindActiveByUser单点参会校验、MarkEnded乐观锁、ListExpiredForCleanup批量扫描)backend/go-service/app/constants/meeting.go(单文件承载会议类型/状态/角色/结束原因/离会原因/默认配置/WS 事件 8 组常量 +*Map中文映射)
- 检查点:
docker exec postgres psql < phase2e2_migration.sql幂等应用,3 表 + 9 索引 + 外键全部正确 ✅- psql 集成脚本跑通 8 场景:CRUD、
room_codeUNIQUE、(room_id,user_id)UNIQUE、主持人转让事务(role=1→0+role=0→1+host_id更新)、聊天写入、duration=10s精确匹配、CASCADE 删除 room 后 participants/chats 残留 0 ✅ go build ./.../go vet ./.../ReadLints零错误 ✅
- 实际产出 vs 计划差异(关键风格修正):
- 常量目录:草案写的
app/meeting/constants/{meeting_status,meeting_role}.go与项目实际风格不符;按project-context.mdc第 11 条「代码风格全局一致(最高优先级)」,采用app/constants/meeting.go单文件承载所有会议常量(与group.go/notify.go同构)。 - 时间字段:草案写
TIMESTAMPTZ,项目所有表统一TIMESTAMP(0)(见 init.sql),本次改为TIMESTAMP(0)对齐,Go model 配gorm:"type:timestamp(0)"。 - 冗余索引移除:草案写
idx_meeting_rooms_code,但room_code UNIQUE已自动建 B-tree,冗余索引已移除。 - Go 单元测试:项目 Go 侧 0 个
_test.go(沿用"代码审查 + Playwright E2E"验证模式),本次同样不新增_test.go;改用 psql 真库集成脚本覆盖 DAO 核心路径,验证价值等价且避免破坏项目一致性。
- 常量目录:草案写的
- 工作量:0.5 人日(实际 0.5,吻合估算)
Task 4:Go 侧 meeting 模块骨架 + Wire ✅(2026-04-21 完成)
- 目标:controller/service/router/provider 空壳搭建 + Wire 绑定完成
- 依赖:T3
- 实际产出:
backend/go-service/app/meeting/service/interfaces.go(25 行):NotifyPusher/UserInfoResolver/OnlineChecker三接口;OnlineChecker.IsOnline对齐ws.OnlineService实际签名(单bool返回)backend/go-service/app/meeting/service/meeting_service.go(165 行):MeetingService+ 8 个 sentinel error + 17 个空方法占位(返回ErrNotImplemented)backend/go-service/app/meeting/controller/meeting_controller.go(150 行):12 个 Gin handler +responseNotImplemented(501)+requireUserID辅助backend/go-service/app/meeting/router.go(35 行,扁平化:没有建router/子目录):12 条路由挂/api/v1/meeting/*并套jwtAuthbackend/go-service/app/meeting/provider.go(22 行):MeetingSet = wire.NewSet(DAO×3, Service, Controller)backend/go-service/app/provider/wire.go(改 +10 行):挂入MeetingSet+ 3 条wire.Bindbackend/go-service/app/provider/provider.go(改 +6 行):App加MeetingService/MeetingController字段backend/go-service/app/provider/wire_gen.go(自动重生成 +30 行)backend/go-service/router/router.go(改 +3 行):meetingApp.RegisterRoutes(engine, app.MeetingController, jwtAuth)backend/go-service/app/admin/provider.go(改 +6 行):存量修复 补齐MessageManage{DAO,Service,Controller}provider
- 实际检查点:
go build ./.../go vet ./.../wire ./app/provider全部零错误GIN_MODE=debug go run cmd/server/main.go启动无报错,HTTP 服务启动日志出现在:8085- gin 启动日志打印全部 12 条
[GIN-debug] ... meeting/controller.(*MeetingController).XxxRoom-fm (6 handlers) - 无 token curl
POST /api/v1/meeting/rooms/GET /api/v1/meeting/rooms/POST /api/v1/meeting/invites/:token/redeem→ 全部 401缺少认证信息,JWT 中间件生效
- 实际产出 vs 计划差异:
- 路由目录扁平化:计划写
app/meeting/router/meeting_router.go,实际为app/meeting/router.go,与项目内app/group/router.go/app/notify/router.go命名一致;RegisterRoutes(engine, controller, jwtAuth)签名保持 - provider 目录扁平化:计划写
app/meeting/provider/provider.go,实际为app/meeting/provider.go,与其他模块一致 - 新增
OnlineChecker接口(计划未列):未来业务逻辑需要判断被邀请者在线状态进行推送路由选择,提前抽象出来 - 顺手修复 admin wire 存量 bug(计划未列):Task 4 重生成 wire 时暴露了 admin 模块
MessageManage系列 provider 缺失的遗留问题,当场补上避免阻塞后续开发
- 路由目录扁平化:计划写
- 工作量:0.5 人日(实际约 0.4 人日,含存量问题修复约 0.1 人日)
Task 5:会议 REST 接口(创建/加入/离开/结束/列表/详情 + 邀请链接兑换 + 邀请)✅(2026-04-21 完成)
- 目标:填充 Task 4 骨架中的业务逻辑,完整实现设计 §6.2 的 12 个接口
- 依赖:T4
- 主要产出(全部实装并端到端通过验证):
- DTO 层:
backend/go-service/app/dto/meeting_dto.go(169 行)定义 13 个 DTO(MeetingRoomDTO/MeetingParticipantDTO/MeetingChatDTO基础 + 10 个请求/响应类型),所有请求体有binding标签 - 工具层:
backend/go-service/pkg/utils/meeting_code.go会议号生成(crypto/rand+ 3 组 3 位数字生成XXX-XXX-XXX,冲突重试 5 次)+ 邀请 Token(32 位 hex) - Service 层:
MeetingService12 业务方法 + 11 个 sentinel 错误 + 4 个辅助函数(assertIsActiveParticipant/assertIsHost/generateUniqueRoomCode/broadcastToActiveParticipants) - Controller 层:12 个 Gin 处理器 +
handleError领域错误 → HTTP 映射(404/403/400/500 四档)+ DTO 转换辅助(roomToDTO/participantToDTO/chatToDTO) - Stub 接口:新增
MediaOrchestrator接口 +NoopMediaOrchestrator(Task 7 替换);WS 广播走pubsub.PublishToUser逐人(Task 6 改为BroadcastToMeeting);NotifyPusher.PushBatch复用 Phase 2e-1 - 路径修正:
router.go将 Task 4 占位路径对齐设计:GET /rooms→GET /rooms/mine、POST /invites/:token/redeem→POST /invite-tokens/:token/redeem - DAO 契约修复:
meeting_room_dao.GetByID/GetByCode+meeting_participant_dao.GetByRoomAndUser/FindActiveByUser将gorm.ErrRecordNotFound转为(nil, nil),service 统一result == nil判定 - 密码限流:同
(user_id, code)5 次错误 → Redisecho:meeting:pwd:fail:...锁 10 分钟(ErrMeetingPasswordLocked) - 单点参会:用
meeting_participantsJOINstatus != 2判断用户是否已在其他活跃会议(ErrAlreadyInOtherMeeting) - host 自动转让:host 离会时若仍有其他活跃成员 → 自动将 host 转给"最早加入者",广播
meeting.host.changed;若无人则房间ended_reason=empty_ttl - 邀请 Token 安全:响应不返回 token,仅通过
NotifyPusher.PushBatch.Extra.invite_token定向下发;兑换后保留 60 秒冗余由 Redis TTL 自然过期 - API 文档:
docs/api/frontend/meeting.md重写为 280 行的 12 接口完整文档(路径总览 + 领域错误码映射表 + 逐接口参数/响应示例 + WebSocket 事件关联表 + 验证记录)
- DTO 层:
- 检查点(全部通过):
go build ./.../go vet ./.../wire ./app/provider零告警- 端到端脚本
/tmp/meeting_t5_test.sh用 3 用户场景覆盖:12 接口 happy path + 5 类错误路径(密码错 / 房间不存在 / 单点参会冲突 / 非 host 越权 / 邀请链接失效)→ PASS=19 / FAIL=0 - DB 侧核验
meeting_rooms.status/meeting_participants.left_at/duration/meeting_chats写入正确;Redis 侧核验echo:meeting:invite:{token}TTL=600s - 服务日志全链路 trace_id;WS 广播
meeting.member.joined/left/chat/host.changed/room.ended事件全部发出
- 实际产出 vs 计划差异:
- 密码连续错误 5 次锁 10 分钟:Task 5 已实现,与计划一致
- 容量限制:MVP 硬上限为 8(设计 D05),超过将
ErrMeetingFull;计划里误写"第 9 人加入返回 meeting_full"表述已与硬上限对齐 kick请求体:设计文档曾讨论{target_user_id, request_id}的幂等字段,Task 5 DTO 定义为{user_id}(与TransferHostRequest.target_user_id命名区分),request_id幂等保护留待 Task 6 WS 侧统一处理(WS 场景更多)- InviteUsersResponse:出于安全考虑不返回 token,仅返回
{pushed, skipped};测试时通过 Redis 获取 token - 错误码中文化:使用中文
message(与项目惯例一致)而非英文meeting_not_foundcode,前端通过 HTTP 状态码 + trace_id 区分
- 工作量:实际 1 人日(< 预估 1.5 人日,因 DTO 设计充分 + DAO 契约修复一次到位)
Task 6:WS 信令 13 事件处理器 ✅ 已完成(2026-04-21)
- 目标:实现设计 §6.3 的 WS 事件族(最终落地 13 个 = 3 房间 + 5 成员 + 5 媒体),完整对接到
ws.Hub - 依赖:T4 ✅
- 实际产出:
app/constants/meeting.go(改):WS 事件常量与设计 §6.3 对齐 +MeetingWSClientEvents白名单切片(8 个 C→S 事件)app/meeting/service/interfaces.go(重构):MediaOrchestrator扩容至 9 方法 + 5 DTO +NoopMediaOrchestrator9 占位实现app/meeting/service/meeting_broadcaster.go(新建,75 行):统一广播层BroadcastToMeeting+PublishToUser,REST / WS 共用app/meeting/service/meeting_service.go(重构):12 REST 方法改调broadcaster.*,不再直连ws.PubSubapp/meeting/service/meeting_signal_service.go(新建,430 行):8 C→S 事件业务 + Redis 资源追踪 + 资源清理 + host 权限校验app/meeting/controller/meeting_ws_handler.go(新建,200 行):薄层 controller,hub.RegisterEvent注册 + JSON 反序列化 + ACKapp/meeting/provider.go+app/provider/provider.go(改):Wire 挂入新 3 个 providerdocs/api/frontend/meeting.md(追加 2 节 +200 行):§WebSocket 信令协议(Task 6) + 验证记录
- 实际检查点:
/tmp/meeting_ws_t6_test.mjs端到端 18/18 PASS:8 C→S 白名单事件 + 3 S→C 广播 + 3 类错误路径(非 host 越权/不存在会议号/WS leave 资源清理)- 非 host 尝试
meeting.member.state.changed修改他人 → ACKcode=-1 message=仅主持人可执行此操作 meeting.room.leave→ 自动触发mediaOrchestrator.Close*清理 Redis 资源 Setgo build/go vet/wire全绿
- 偏离与说明:
- 最终事件数从实施计划的 11 个扩展为 13 个(+ 2 个业务补充事件:
meeting.chat.message+meeting.member.producer.new),与设计文档 §6.3 一致 - 权限校验入口改为在
MeetingSignalService.On*方法内部调用assertIsActiveParticipant/assertIsHost,不再依赖 handler 层前置断言,代码更易测试 - 广播 API 统一为
MeetingBroadcaster.BroadcastToMeeting(含excludeUserIDs ...int64可变参数),比计划中"Hub.BroadcastToMeeting方法" 更内聚,不污染ws.Hub通用接口
- 最终事件数从实施计划的 11 个扩展为 13 个(+ 2 个业务补充事件:
- 实际工作量:1 人日(比预估 1.5 人日节省,得益于 Task 5 已预置好 DAO / 错误链 / DTO)
Task 7:Go → Node HTTP Client 封装 ✅ 已完成(2026-04-21)
- 目标:实现设计 §6.6 的
NodeClient接口,挂接到 WS 信令流程 - 依赖:T2 + T6
- 实际产出:
app/meeting/service/http_media_orchestrator.go(新,340 行):实现MediaOrchestrator8 方法,完整覆盖 Router/Transport/Producer/Consumer 生命周期config/config.go+config.dev.yaml+config.docker.yaml:新增MediaServerConfig{BaseURL, InternalToken, TimeoutMS, CloseTimeoutMS, CloseRetry};支持环境变量ECHOCHAT_MEDIA_SERVER_*覆盖app/meeting/provider.go+app/provider/wire_gen.go:wire.Bind由*NoopMediaOrchestrator切换为*HTTPMediaOrchestrator,注入*config.Configdocs/verify/meeting_t7_verify.mjs(新,140 行):Node.js E2E 验证脚本- 错误类型:
ErrMediaResourceNotFound(404,关闭类自动幂等转 nil)/ErrMediaServerError(5xx/超时/网络错),可供上层errors.Is区分 - 关闭类指数退避:200ms → 500ms,最多
CloseRetry + 1次尝试 sync.Map本地roomCode ↔ routerID缓存,兼容设计 §6.6 "CloseRouter(roomCode)" 签名约束
- 检查点(已全部达成):
- ✅
go build ./...全绿 - ✅
go vet ./...全绿 - ✅ 端到端脚本
docs/verify/meeting_t7_verify.mjs16/16 PASS,覆盖健康检查、token 鉴权、REST 创建/加入/结束会议、WS transport.create、404 幂等关闭 - ✅ media-server 日志确认真实
router created/webrtc transport created/router closed explicitly - ✅
transport.id/iceCandidates[]/dtlsParameters.fingerprints[]均非占位,证明真实 mediasoup 链路
- ✅
- 偏离与说明:
- 文件命名由设计
node_client.go改为http_media_orchestrator.go,与 Task 6 抽出的MediaOrchestrator接口保持语义一致 - 接口方法数保持 8 个(设计 §6.6 列 9 个含
ResumeConsumer):ResumeConsumer的 Node REST 已就绪,但当前 WS 契约无对应事件,留给 Task 9 前端 mediasoup-client 接入时补齐 - 单元测试(
httptest.NewServer模拟)本次未落地,用更真实的"Go + 真 Node + Playwright-style E2E"替代,证据力更强;Task 10(可观测性)补齐单测
- 文件命名由设计
- 实际工作量:0.5 人日(符合预估)
Task 8:会议生命周期状态机(host 宽限期 + 自动转让 + 空房 TTL)✅ 已完成
- 目标:实现设计 §6.5 的状态机完整逻辑;同步修复 Task 7 遗留的"CreateRoom/JoinRoom 各自调一次
CreateRouter"行为 - 依赖:T5 / T7
- 实际产出:
backend/go-service/config/config.go+config.dev.yaml/config.docker.yaml:新增MeetingConfig{HostGraceSeconds=120, EmptyRoomTTLSeconds=300, CleanupIntervalSeconds=30, StaleRoomHours=4}backend/go-service/app/meeting/service/meeting_lifecycle_service.go(新,470 行):OnHostDisconnect(ctx, roomCode, hostID)→ 写echo:meeting:host_grace:{code}+ 本地time.AfterFunc,Redis TTL = 业务时长 +max(cleanup*2, 30s)bufferOnHostReconnect(ctx, roomCode, hostID)→DELkey + 取消 timerHandleHostGraceExpired(ctx, roomCode)→DELkey(返回 1 确认唯一处理权)→TransferHost事务(最早加入者)+UpdateHost+ 广播meeting.host.changed{auto_reason=host_grace_expired};无其他活跃成员则走OnAllMembersLeftOnAllMembersLeft(ctx, roomCode)→ 写echo:meeting:empty_ttl:{code}+ 本地 timerCancelEmptyTTL(ctx, roomCode)→DELkey + 取消 timer(新成员加入复活)HandleEmptyRoomExpired(ctx, roomCode)→DELkey →MarkEnded(reason=empty_ttl)+CloseRouter幂等 + 广播meeting.room.endedRescheduleFromRedis/ScanExpired/HostGracePrefix/EmptyTTLPrefix辅助(供 cleanup task 兜底)
backend/go-service/app/meeting/dao/meeting_room_dao.go:新增ListStaleActive(hoursAgo, limit)扫陈旧活跃房间backend/go-service/app/meeting/service/interfaces.go:MediaOrchestrator新增ResolveRouterID(roomCode) (string, bool)backend/go-service/app/meeting/service/http_media_orchestrator.go:CreateRouter入口查sync.Map命中直接返回(HTTP 层幂等防御);实现ResolveRouterID纯缓存读backend/go-service/app/meeting/service/meeting_service.go:JoinRoom移除CreateRouter,改调lifecycleSvc.CancelEmptyTTL+ResolveRouterID;LeaveRoom空房分支改调lifecycleSvc.OnAllMembersLeftbackend/go-service/app/meeting/service/meeting_signal_service.go:新增OnWSDisconnect(userID)实现ws.MeetingDisconnectHook;OnRoomJoin追加 host 重连钩子backend/go-service/app/ws/handler.go:定义MeetingDisconnectHook接口 +SetMeetingDisconnectHook,SetOnDisconnect末尾 invokebackend/go-service/app/meeting/task/meeting_cleanup_task.go(新,220 行):启动时RescheduleFromRedis;每CleanupIntervalSeconds秒扫host_grace:*/empty_ttl:*兜底 + 扫 stale active rooms →MarkEnded(reason=system_error);每小时清理 Ended 会议的聊天记录backend/go-service/app/provider/{provider,wire,wire_gen}.go+cmd/server/main.go:注入MeetingLifecycleService/MeetingCleanupTask+wire.Bind(new(ws.MeetingDisconnectHook), new(*service.MeetingSignalService))+ 启动/停止 cleanup taskmedia-server/src/app.ts:/internal/info追加stats.routers字段供 E2E 断言 Router 幂等docs/verify/meeting_t8_verify.mjs(新,320 行):5 场景 E2E 脚本
- 实际检查点(全部通过):
go build ./.../go vet ./.../ReadLints全绿(保留 Task 7 遗留 pre-existing 警告)- E2E 脚本
meeting_t8_verify.mjs20/20 PASS(含 Router 幂等断言) - 场景覆盖:
- S1:host 掉线 3s 后宽限期过期 → 自动转让给 B,
meeting.host.changed广播auto_reason=host_grace_expired,DBhost_id更新 - S2:host 掉线后 1s 内重连 →
host_gracekey DEL,身份保留 - S3:全员 leave →
empty_ttl写入 → C 加入 → key DEL + 房间仍 Active - S4:全员 leave → 3s 后
empty_ttl过期 → 房间 Ended → 再 join 被拒 - S5:
CreateRoom使stats.routers+1;JoinRoom不再触发新 Router
- S1:host 掉线 3s 后宽限期过期 → 自动转让给 B,
- 关键设计决策:
- Redis TTL 加 buffer 避免 DEL 与自动过期并发误判:E2E 调试时发现若 Redis key TTL 与本地
time.AfterFunc时长相同,本地 timer 触发时 key 已被 Redis 自动删除,DEL返回 0 被误判为"已被其他路径处理"而跳过业务逻辑;修复:Redis TTL = 业务时长 +max(CleanupIntervalSeconds*2, 30s) - 普通成员 WS 断线不动 DB(决策
q1_nonhost_disconnect=a1_keep_current):仅清理 WS/media 资源,meeting_participants记录保留;长期不活跃由 4 小时后台扫描兜底 - Router 幂等双层防御(决策
q2_router_dedup=a2_both):业务层JoinRoom不调CreateRouter+ HTTP 层CreateRouter入口查sync.Map幂等
- Redis TTL 加 buffer 避免 DEL 与自动过期并发误判:E2E 调试时发现若 Redis key TTL 与本地
- 实际工作量:0.5 人日(符合预估)
Task 9:前端 mediasoup-client 集成 + Pinia Store
- 目标:实现设计 §8.2 / §8.4 的 Store 状态与 mediasoup-client 生命周期封装
- 依赖:T2
- 主要产出:
frontend/src/utils/mediasoup-client.js:createDevice(rtpCapabilities)→mediasoupClient.DevicecreateSendTransport/createRecvTransport包装 + 事件桥接到 WSproduceAudio(track)/produceVideo(track, encodings)consume(producerId)全流程- 所有实例通过
markRaw包裹
frontend/src/store/meeting.js:- state 完整定义(见设计 §8.2)
- 10+ actions 与 WS
_on*事件响应
frontend/src/constants/meeting.js:事件名 / 类型 / 角色常量frontend/src/api/meeting.js:REST 封装frontend/src/utils/ws.js增加 meeting 事件分发桥
- 检查点:
- 手动启动前端,在控制台调用
useMeetingStore().createRoom({title: '测试'})→ 成功入会并推流 - 两个浏览器标签互相看见视频
- 关闭标签后另一端 1 秒内收到
meeting.member.left
- 手动启动前端,在控制台调用
- 工作量:1.5 人日
Task 10:前端设备预览页 + 创建页 + 加入页
- 目标:完成
/pages/meeting/{create,join,preview}.vue3 个页面 - 依赖:T5
- 主要产出:
MeetingCreate.vue:标题输入 + 密码 + 开关(入会静音 / 允许聊天) + 「立即开会」按钮MeetingJoin.vue:会议号输入(3-3-3 分组) + 密码 + 承接?code=xxx参数MeetingPreview.vue:- 左侧视频预览(
<video autoplay muted>承载 localStream) - 右侧设备列表(
enumerateDevices填充) - 音量条(AudioContext AnalyserNode 每 100ms 采样)
- 显示名称确认 + 「加入会议」按钮
- 左侧视频预览(
- 浏览器兼容性检测:不支持
getUserMedia→ 友好降级
- 检查点:
- Chrome / Firefox / Safari 手测设备选择 + 预览 + 音量条正常
- 手机浏览器(Safari iOS / Chrome Android)布局无错位
- 权限被拒绝时给出清晰引导
- 工作量:1 人日
Task 11:前端会议室主页(视频网格 + 工具栏 + 成员面板 + 响应式)
- 目标:实现
/pages/meeting/room.vue+ 6 个主要组件 - 依赖:T9
- 主要产出:
MeetingRoom.vue:主容器 + 网络质量监测 + WS 监听挂载VideoGrid.vue:响应式网格(见设计 §8.5)+ 按成员数动态布局VideoTile.vue:视频块(含静音图标、说话者流光占位)MeetingToolbar.vue:5 按钮(麦 / 摄 / 成员 / 聊天 / 挂断)+ 邀请入口MemberPanel.vue:成员列表 + host 菜单(静音 / 移除 / 转让)InviteDialog.vue:复制链接 + 复制会议号 + 选择联系人(复用 Phase 2a 组件)NetworkBadge.vue:3 档网络质量占位(具体动效 Task 15 打磨)
- 检查点:
- 4 人会议:UI 网格切换 1→2→3→4 人布局正常
- host 操作:静音他人 / 移除成员 / 转让主持 / 结束会议 全部成功
- 手机浏览器:单列主画面 + 缩略抽屉工作正常
- 工作量:2 人日
Task 12:会议内聊天面板
- 目标:实现
ChatPanel.vue+ 后端meeting_chats相关接口 - 依赖:T11
- 主要产出:
- 后端:
meeting_chat_controller.go+meeting_chat_service.go(2 接口:POST 发送、GET 历史分页) - WS 事件:
meeting.chat.new(广播给房间内所有成员) - 前端:
ChatPanel.vue(消息列表 + 发送框 + 滚动到底部) - Store 内
chat: {messages, hasMore}字段维护 - 清理任务:
meeting_cleanup_task每天扫描status=2 AND ended_at < NOW() - INTERVAL '24 hours',DELETE FROM meeting_chats WHERE room_id IN (...)
- 后端:
- 检查点:
- 两个用户互发 10 条消息,顺序正确
- 会议结束 24 小时后聊天记录被清理(可手动
UPDATE ended_at = NOW() - INTERVAL '25 hours'触发)
- 工作量:0.5 人日
Task 13:meeting_invite 通知对接
- 目标:打通
POST /rooms/:code/invite→ 通知中心 → 前端卡片跳转链路 - 依赖:T5
- 主要产出:
- 后端:
Invite()service 内调用notifyPusher.Push(ctx, receiverID, PushRequest{Type: "meeting_invite", Extra: MeetingInviteExtra{...}}) - 通知
extra结构补充(设计 §10.1) - 前端
NotifyItem.vue:meeting_invite卡片底部渲染「立即加入 / 稍后」按钮 - 前端路由跳转:「立即加入」→
/pages/meeting/preview?code=xxx;「稍后」→ 标已读 - 邀请链接复用:若
expired_at < now()灰显按钮提示"邀请已过期"
- 后端:
- 检查点:
- 用户 A 创建会议 → 邀请用户 B → 用户 B 通知中心铃铛出现未读 → TabBar「我的」红点亮起 → 点击卡片「立即加入」→ 成功入会
- 过期通知点击按钮 → 显示过期提示,不跳转
- 工作量:0.5 人日
Task 14:docker-compose 扩展 + 环境变量双态开关
- 目标:本机和公网双态部署脚本 + 文档
- 依赖:T11
- 主要产出:
deploy/docker-compose.dev.yml新增media-server服务 +coturn(profiles: [public]).env.example/.env.local.example/.env.public.example三份配置scripts/start.sh扩展media/full子命令scripts/stop.sh/scripts/status.sh同步scripts/deploy-public.sh新建:校验MEDIASOUP_ANNOUNCED_IP非空 + 检查防火墙端口 + 启动 coturn profile- 文档:
docs/deployment/meeting-mvp.md新建,涵盖本机 + 公网两种流程 + 常见问题
- 检查点:
- 本机:
scripts/start.sh full全量启动,5 分钟内全部服务就绪 - 公网(模拟):
MEDIASOUP_ANNOUNCED_IP=x.x.x.x docker compose --profile public up启动无报错 - 防火墙校验脚本能识别 UDP 40000-40199 未开放并给出提示
- 本机:
- 工作量:0.5 人日
Task 15:ui-ux-pro-max 定制 UI 打磨
- 目标:调用技能包产出 4 屏 EchoChat 原创风格,落地到代码
- 依赖:T11
- 主要产出:
- 调用:
npx openskills read ui-ux-pro-max+ 4 屏 brief(设计 §9.1) - 设计落地:
design-system/echochat/pages/meeting-home.mddesign-system/echochat/pages/meeting-preview.mddesign-system/echochat/pages/meeting-room.mddesign-system/echochat/pages/meeting-invite.md
- 代码落地:
VideoTile.vue说话者流光轮廓动效- 柔性网格:2/3 人布局的非等分样式
- 自视频浮窗四角吸附(
draggable+ 吸附计算) - 静音氛围色(工具栏底色绑定 computed
allMuted) NetworkBadge.vue3 档波浪动效
- 调用:
- 检查点:
- 视觉走查:4 屏与设计产物一致,色彩 / 留白 / 动效符合飞书简洁 + EchoChat 原创要求
- 动效性能:不影响 60fps(Chrome Performance 面板确认)
- 代码审查:
ui-ux-pro-max产物被真正使用,不留下"代码 vs 设计产物"脱节
- 工作量:2 人日
Task 16:E2E 验证 + Playwright MCP 回归 + 代码审查 + 文档同步
- 目标:端到端闭环验证 + 交付收官
- 依赖:T12 + T13 + T14 + T15 + T8
- 主要产出:
- Playwright MCP 场景脚本(保存到
.playwright-mcp/scenarios/):- 场景 1:创建会议 → 通过会议号加入第二个用户 → 互推音视频 → 结束
- 场景 2:邀请链接加入(含密码)
- 场景 3:通知中心「立即加入」按钮跳转
- 场景 4:主持人转让(主动)+ 主持人掉线(被动,2 分钟宽限)
code-reviewer子代理运行 → 出具报告,修复 P0/P1- 文档同步(设计 §十六 变更记录 + 以下文件):
docs/progress/CURRENT_STATUS.md:Phase 2e-2 状态改为 ✅docs/architecture/system-architecture.md:新增 meeting 模块docs/api/README.md+docs/api/frontend/meeting.md.cursor/rules/project-context.mdc:当前进度更新docs/plans/2026-04-20-phase2e-design.md:Phase 2e-2 段标记 ✅
- 测试报告:
test-report-phase2e-2-meeting.md落盘
- Playwright MCP 场景脚本(保存到
- 检查点:
- 4 个 E2E 场景全部通过
- 代码评审 0 个 P0/P1
- 所有文档链接可达、无 404
- 清理所有 TODO / FIXME /
console.log调试残留
- 工作量:1 人日
五、工作量汇总
| Task | 名称 | 工时 |
|---|---|---|
| 0 | mediasoup PoC Spike | 1.0 |
| 1 | media-server 项目骨架 | 0.5 |
| 2 | Node 侧 9 个 REST API | 2.0 |
| 3 | 数据库 DDL + 模型 + DAO | 0.5 |
| 4 | Go 侧 meeting 模块骨架 + Wire | 0.5 |
| 5 | 会议 REST 接口 | 1.5 |
| 6 | WS 信令 11 事件处理器 | 1.5 |
| 7 | Go → Node HTTP Client | 0.5 |
| 8 | 生命周期状态机 | 0.5 |
| 9 | 前端 mediasoup-client + Pinia Store | 1.5 |
| 10 | 前端预览/创建/加入页 | 1.0 |
| 11 | 前端会议室主页 | 2.0 |
| 12 | 会议内聊天面板 | 0.5 |
| 13 | meeting_invite 通知对接 |
0.5 |
| 14 | docker-compose + 双态配置 | 0.5 |
| 15 | ui-ux-pro-max 定制 UI 打磨 |
2.0 |
| 16 | E2E + 代码审查 + 文档同步 | 1.0 |
| 合计 | 17.0 |
说明:原 Phase 2e 路线图对 Phase 2e-2 的估算为 10-14 人日。当前 17 人日相较增加 3-7 人日的原因:
- 纳入了设备预览页(Task 10 的一部分,约 0.5 人日)
- 纳入了会议内聊天(Task 12,0.5 人日)
- 纳入了移动端响应式布局(分摊到 Task 11/15,约 1 人日)
- 纳入了邀请通知对接与 Phase 2e-1 的闭环(Task 13)
- 纳入了**
ui-ux-pro-max定制 UI 打磨**(Task 15,2 人日) - 预留了 PoC Spike 与 E2E 的显式工时(Task 0 / Task 16 共 2 人日)
该增量均是用户在 Plan 模式下的 11 项决策明确要求纳入的,已与设计文档 §2.2 对齐。
六、工作流与提交节奏
- 分支:
feature/phase2e-2-meeting-mvp(已由上游决策指定) - 每个 Task 完成后:
- 本地
go test ./app/meeting/.../pnpm test/npm run lint全绿 code-reviewer子代理小审(仅重要 Task 5/7/9/11 跑全量审)- 小粒度 commit:
feat(meeting): task-N <简短描述> - 不自动推远端,由用户显式触发
- 本地
- 每周节奏:Task 0-4 集中第一周(基础设施 + 骨架);Task 5-13 分散第二周(业务主体);Task 14-16 第三周(部署 + 打磨 + 收官)
- 阻塞处理:
- PoC(Task 0)如失败,立即暂停,与用户重议选型(livekit-server 替换 mediasoup)
- 任何 Task 工时超出估算 50% 以上,立刻停下来复盘,必要时拆子任务或推迟非关键部分
- Review Gate:每完成 3-4 个 Task 触发一次 review gate 汇报阶段进展
七、显式不做(本实施计划范围外)
- 不写 Phase 2e-3 相关代码(预约 / 提醒 / 等候室 / 锁定)
- 不写管理端 meeting 模块代码(推迟到 Phase 2f)
- 不做录制 / 屏幕共享 / 虚拟背景(二期)
- 不做多 Worker / 多 Node 实例 / Router Pipe(三期)
- 不引入 CI 流水线(接入后再由运维任务统一实施)
- 不做付费 TURN 服务接入(MVP 自建 coturn 即可)
八、关联文档
九、变更记录
| 日期 | 作者 | 变更 |
|---|---|---|
| 2026-04-21 | Agent | 首版落盘,17 个 Task 共 17 人日,含 PoC / UI 打磨 / E2E |
| 2026-04-21 | Agent | Task 0 mediasoup PoC Spike 完成:media-server/poc/ 跑通 2 浏览器互通,media-server/docs/poc-notes.md 归档压测数据与 7 项关键坑,技术栈选型锁定 |
| 2026-04-21 | Agent | Task 1 media-server 项目骨架完成:src 五件套(app/config/logger/worker/internal-auth)落盘;/healthz + /readyz + /internal/info 全部验收通过;Worker died 自动重启通过 kill -9 实测;Dockerfile 多阶段 + 非 root + HEALTHCHECK |
| 2026-04-21 | Agent | Task 1 Fastify 4 → 5 同日升级:fastify@4.28.1→5.8.5、fastify-plugin@4→5.1.0、@fastify/sensible@5→6.0.4、@fastify/websocket@10→11.2.0;src/app.ts 改用 loggerInstance: logger 消灭 pino 双实例;理由:Fastify 4 已过 2025-06-30 LTS 支持、v5 生态 GA、单实例回归;回归测试全部通过 |
文档结束