我开始做直播系统重构时，没有先急着写新功能。旧系统已经跑过一段时间，留下了真实访问、直播场次、评论和在线人数数据。对我来说，这些运行痕迹比新的技术选型更重要。

重构最怕的是只换技术栈。页面变新了，代码变整齐了，但旧问题没有被理解，新系统也只是更漂亮地重复一遍。

先看真实运行过什么

旧系统能告诉我很多事情：哪些页面常用，哪些入口会出问题，哪些统计不准，哪些后台操作让人绕，哪些能力其实没人用。

这些信息不在需求清单里，但它们决定重构优先级。如果用户主要从移动端进入，观看端就不能只按桌面设计；如果直播评论和在线人数经常被运营关注，它们就不是可有可无的小功能；如果后台维护成本高，新的后台边界就要更清楚。

重构不是重新做一遍

我不把重构理解为“把旧功能全部用新技术写一遍”。重构应该回答旧系统哪里撑不住。

是成本不可控，还是代码边界混乱？是观看端和后台耦合太重，还是实时能力不可靠？是统计口径不清楚，还是部署维护越来越难？

如果这些问题没有拆开，新系统很容易在早期看起来顺利，后面又回到原来的状态。

前后端边界要重新划

旧系统里很多功能可能长在同一个应用里，早期这样很快。但到了重构阶段，我会重新看哪些能力应该留在后端，哪些应该成为独立观看端，哪些 API 要稳定下来。

直播系统里，后台管理、观看页面、评论、在线状态、房间配置、推流回调和历史记录都有不同的变化频率。把它们全部绑在一起，后续维护会越来越重。

边界划清楚以后，后端可以更专注房间、权限、事件和数据，前端可以更专注播放体验、移动端访问和互动。

旧数据是重构的依据

我越来越不相信只靠想象做重构计划。旧系统的访问量、场次、用户行为和维护问题，才是新系统应该解决什么的依据。

这些数据不一定完整，但比空白假设更可靠。它们能告诉我哪些地方值得重做，哪些地方只需要保留，哪些功能看起来重要但实际很少被用到。

重构的第一步是克制

直播系统重构让我再次确认，重构开始时最重要的是克制。

先看旧系统，不急着加新功能；先确认真实问题，不急着换框架；先稳定核心链路，不急着做展示效果。这样重构才更像一次系统升级，而不是一次重新装修。