项目背景
这个项目不是单一的视频房间页面，而是一套完整的实时会议产品：管理端负责会议与权限，Web 端承担浏览器入会和观看，Android 与 iOS 负责移动参会和屏幕共享，后端统一管理会议生命周期、访问控制、消息、审计与媒体策略，自建 LiveKit SFU 负责实时音视频转发。
项目真正困难的地方，是让多端在同一套业务规则下稳定协作。摄像头正常并不代表屏幕共享一定流畅；手机采集、编码器、跨境上行、SFU、观看端网络和浏览器解码，任何一段出现短时拥塞，都可能表现为花屏、冻结或恢复缓慢。
我的工作
梳理超级管理员、子管理员、参会者和游客的权限与数据范围。
完善会议创建、标题预填、创建来源、会议列表、结束与清理等生命周期。
打通 Web、NestJS、PostgreSQL、Redis、LiveKit、Android 和 iOS 的完整链路。
建设移动端屏幕共享、设备音频、聊天、快捷互动、参会者控制与异常恢复。
为 Android 建立 Release/R8 生产模板、签名校验与 APK 交付流程。
建立 QoS 与 RTC 诊断思路，区分发布端、观看端、屏幕轨和摄像头轨。
完成 Docker 生产部署、健康检查、数据卷保护、备份清单与生产包交付。
核心难点
屏幕共享卡顿最终不能用“服务器带宽够不够”一句话解释。项目审计发现，真实问题可能同时来自 TCP 退化、高 RTT 下的队头阻塞、iOS ReplayKit 的软件 JPEG/IPC 管线、单层编码缺少订阅自适应，以及统计采样无法捕捉 1～3 秒的突发冻结。
因此处理方式不是盲目调整 SFU 参数，而是建立端到端证据链：采集屏幕轨的编码帧、码率、NACK/PLI、冻结、抖动、候选协议和解码数据，再判断问题发生在采集、编码、上行、SFU、下行还是解码阶段。移动端策略也收敛到更稳定的画质上限，并避免在会议中反复重建媒体轨道。
交付结果
后端自动化测试：100 项通过。
全功能回归：18 项业务链路通过，临时数据与文件完成清理。
Android 真机覆盖安装、匿名入会、摄像头/麦克风切换、屏幕与设备音频共享、前后台切换、断网恢复和异常重启。
全新 Docker 重建后，PostgreSQL、Redis、LiveKit、API、Web 与网关六个服务正常运行。
生产包仅保留编译产物、部署脚本和必要模板，不包含前端/后端/移动端源码与 Source Map。
项目价值
这个项目最有价值的不是“做出一个会议页面”，而是建立了一条从产品权限、跨端媒体、弱网诊断到生产交付的完整工程链路。核心版本已经完成并验收；最新架构审计中识别出的 UDP 恢复、iOS 管线和 QoS v3 属于持续性能优化方向，不冒充已经完成的结果。