直播业务后台开发

项目背景

这是一套粉丝与直播运营平台，2 个仓库。前端运营台用 Vue 写，189 个 Vue 文件；后端用 Java，394 个 Java 文件，另有 4 个测试文件。最后提交在 2026 年 4 月。平台的作用是把粉丝运营和直播场次管理放在一套系统里，而不是散在各个运营工具中。

客户当时的状态

粉丝运营最常见的状态是「动作做了，但说不清有没有用」。分层靠人工打标签，标签越打越多、标准越来越乱；一场直播挂了哪些商品、哪些活动，事后靠翻记录和聊天截图来复盘；运营动作发出去之后，效果好不好没有统一口径。问题不在缺功能，在于每个环节的数据不连通。这些环节原本各自有各自的记录方式，运营人员习惯了以后也不觉得有问题，直到需要复盘或者交接，才发现数据根本拼不到一起。

我们的做法与取舍

第一个取舍是把粉丝分层与标签做成系统里的数据，而不是运营人员各自记。标签有统一口径才能做后续的分层动作，否则标签本身就是噪音。

第二个取舍是直播场次作为一条主记录，商品与活动挂在它下面。场次是天然的容器，把当场的挂载对象挂上去，复盘时才有完整的上下文。

第三个取舍是让运营动作可回溯。动作发出去要能对上后面的数据变化，哪怕只能看出趋势，也比完全凭感觉强。

系统怎么承载这条链路

后端承载粉丝、标签、场次与挂载关系，前端运营台承载操作与查看。数据在同一条链路上：粉丝分层 → 直播场次 → 商品与活动挂载 → 动作与效果回溯。各部分共用一套标签与场次定义，不各写一套。运营台这一层的价值是让运营人员不用在多个工具之间切换，标签、场次与动作在同一个界面里完成，数据从产生的那一刻起就是打通的。

交付状态与边界

代码处于维护状态，最近一次提交在 2026 年 4 月。边界说明：平台提供的是运营数据与流程的承载能力，不承诺运营效果，效果受内容、时机与平台规则影响；与外部直播平台的数据对接以实现时的接口情况为准，对方接口变更会带来适配工作；后端现有 4 个测试文件，测试覆盖不是这套工程的强项，这一点如实说明。