直播系统重构到观看端时，我重新想了一次前后端边界。

早期把观看页面和后台放在一起很方便，路由、权限、数据都在同一个应用里。但当观看体验、移动端适配、播放器、评论和实时能力逐渐变重要，观看端继续跟后台绑在一起，就会影响迭代速度。

观看端首先是用户界面

后台关注管理效率，观看端关注用户体验。两个系统的节奏不同。

观看端要关心首屏加载、播放器状态、移动端手势、评论输入、登录或 token、异常提示和直播结束后的状态。后台更关心房间配置、用户管理、统计、权限和维护。

这些关注点混在一起时，代码很容易互相牵制。把观看端拆出来以后，前端可以更直接地围绕用户体验设计。

API 要提供稳定边界

独立观看端不是把所有逻辑搬到前端。它需要后端提供清楚、稳定的 API。

房间信息、播放地址、评论列表、发送评论、在线状态、用户身份、封面图，这些数据都需要有明确边界。前端不应该知道后台内部怎么存房间，也不应该直接依赖后台页面结构。

我更希望前端拿到的是观看场景需要的数据，而不是后台数据库的影子。

播放器不是孤立组件

HLS 播放器看起来是一个组件，但它会牵动很多状态。

直播是否开始，流是否可用，网络是否失败，用户是否在移动端，页面是否需要静音自动播放，评论是否跟播放器区域冲突，这些都会影响观看体验。

所以我不会把播放器当成单独技术点。它应该和房间状态、错误提示、评论区和移动端布局一起设计。

拆分以后责任更清楚

观看端独立后，前端和后端的责任反而更清楚。

后端负责房间、权限、播放地址、评论数据和实时事件；前端负责把这些能力组织成稳定的观看体验。两边通过 API 和事件协作，而不是通过同一个页面模板互相依赖。

这也让后续维护更容易。观看体验需要调整时，不一定动后台；后台管理变化时，也不一定影响观看端。

边界清楚以后才能快

这次拆分让我再次确认，系统变快不一定来自把东西放在一起。

早期放在一起确实快，但业务复杂后，清楚的边界会更快。观看端、后台、API 和实时事件各自稳定，迭代时才不会每改一处都担心影响另一处。