1. 项目概述与功能边界
接手“忘忧传媒直播管理系统”这个项目时，我第一反应是：这不就是又一个增删改查的毕业设计嘛。但仔细把需求过了一遍之后发现，直播管理系统远没想象中那么简单。虽然它有明显的教学和展示属性，核心架子是Java+SpringBoot+SSM这套经典组合，但它内部的业务链路足够长——从主播入驻、直播间创建，到用户送礼物、平台分成结算，再到内容审核和数据统计，每一步都涉及真实业务场景里的痛点，做得好不好，差别很大。
这套系统最适合两类人参考：一类是正在做Java毕业设计或课程设计的学生，需要用SpringBoot+SSM做一套功能完整、逻辑清晰、有答辩亮点的项目；另一类是刚开始接触企业级Web开发的初级工程师，想通过一个完整项目理解权限设计、订单结算、状态机流转这类真实开发中的高频问题。它的典型使用场景是模拟一个传媒公司管理旗下主播和直播间的后台系统，包含前台展示、用户操作、后台管理三端能力，覆盖从注册登录到营收统计的闭环链路。对学习者来说，能够从这套系统中看到主播合同如何抽象成数据模型、礼物打赏如何折算成平台收益、管理员如何分级管控，这就是它最大的价值。
我不会把这篇博文写成教科书式的说明书，而是从我做这个项目时的真实思考路径出发，把技术选型、数据建模、核心流程、部署调试、踩坑实录全部拆开讲。文中用的步骤和方案以我的实际开发经验为主，你拿去做自己的项目时，遇到不合理的地方完全可以根据自己的场景调整。有一点我要先说明：这个项目的技术栈选型——SpringBoot+SSM——是典型的过渡期组合方案，它不是最前沿的，但在教学项目和企业旧系统维护场景里依然大量存在，理解它的设计逻辑，比单纯追新框架更有实际用处。
2. 技术选型与整体架构思路
2.1 为什么是SpringBoot+SSM而不是别的组合
做直播管理系统这种业务密集型项目，第一步不是写代码，而是想清楚技术栈。标题里明确写的是Java+SpringBoot+SSM，这套组合的含义是：SpringBoot作为整个应用的启动框架，SSM（Spring+SpringMVC+MyBatis）作为底层的Web和持久层框架。你可能会问，SpringBoot本身已经简化了配置，为什么还要强调SSM？这里有个很实际的背景——SpringBoot本来就是一个“去XML化”的Spring应用框架，它自动装配的底层仍然是Spring、SpringMVC、MyBatis这些组件。所以严格来说，你写一个SpringBoot项目，就已经把SSM三大件全部用上了，只是通过启动器和自动配置把它们“藏”在了后面。
那为什么不直接用SpringBoot+MyBatis-Plus，或者干脆上微服务？我的判断是：这套系统的核心诉求是稳定、可讲解、易部署。SpringBoot内置Tomcat，能做到一个jar包跑起来，对答辩和演示特别友好；SSM则是经典的三层架构——Controller层接收请求、Service层处理业务、Mapper层操作数据库，每一层职责清晰，哪怕你是刚学完JavaSE的学生，也能很快看懂项目结构。微服务在这个量级下纯属过度设计，一个直播管理系统用单体应用完全撑得住，也省去了注册中心、网关、配置中心这些复杂组件给新手带来的干扰。
提示：如果你想把项目做得更有亮点，可以保留SpringBoot+SSM作为主框架，然后引入Redis做热点数据缓存、WebSocket做弹幕推送。这样既保留了经典组合的教学价值，又增加了现代企业级开发中常见的中间件应用场景，答辩时能说的话题会多很多。
2.2 核心业务域拆解与模块规划
拿到需求后，我没有急着建表，而是先把直播管理系统拆成了六个业务域。第一个是用户域，覆盖注册、登录、个人信息维护，同时需要支持普通用户和主播身份的切换或绑定；第二个是直播域，包括直播间的创建、编辑、上下线、直播计划的排期管理；第三个是互动域，也就是弹幕、点赞、礼物打赏，这部分是直播业务的核心流量入口；第四个是交易域，处理金币充值、礼物购买、打赏流水、主播收益分成结算；第五个是内容域，包含直播间封面图、公告、敏感词过滤、违规记录；第六个是统计域，汇总在线人数、开播时长、礼物收入等运营指标。
这六个域对应到项目工程上，就是标准的MVC分层加上模块化包结构。我当时是按controller、service、mapper、entity、dto、vo这六个基础包来组织代码的，其中dto用于接收前端传入的参数，vo用于返回给前端展示的数据，二者分开能有效避免实体类直接暴露给接口调用方。这种结构对一个单体管理系统来说是最省力的，既不显得杂乱，又能支撑后续功能扩展。
工程的模块划分我建议按业务走，而不是按技术层走。什么意思呢？比如com.wangyou.admin包放后台管理相关的Controller，com.wangyou.user放前台用户相关的Controller，com.wangyou.live放直播业务，com.wangyou.order放订单和结算。如果你把所有Controller堆在一个包里，项目规模一大就会非常难找文件。合理的包结构本身就是在降低维护成本，这也是面试官和答辩老师很看重的一个细节。
2.3 数据存储与经济模型
直播管理系统最核心的数据不是用户信息，而是“钱”和“内容”的流转。我的设计原则是：金额一律用整数分存储，不用浮点；状态一律用整数状态机，不直接存中文字符串；凡是涉及外部展示的文本字段都要有长度上限校验，防止脏数据。
围绕直播的经济模型，我把收益链路设计成三个表：商品（或者叫礼物）、充值订单、打赏记录。礼物表保存基础价格和状态；充值订单表记录用户充值的流水；打赏记录表则关联用户、主播、直播间、礼物，形成一条完整的金额流转链路。分成结算的逻辑放在Service层——平台先抽取固定比例的服务费，剩余部分乘以主播分成比例就是主播的收入，这个计算过程不能出现在数据库SQL里，因为不同的活动可能临时调整比例，放在Service层里便于修改和写单元测试。
数据库选型上我用的MySQL 5.7+，字符集utf8mb4。这里有一个比较隐蔽的问题：如果只建表不指定字符集，MySQL默认可能是latin1，导致中文乱码。建表时一定要显式加ENGINE=InnoDB DEFAULT CHARSET=utf8mb4，InnoDB支持事务，对订单和打赏这类需要原子性操作的场景是必须的。
3. 核心功能模块设计与数据建模
3.1 用户角色与权限体系设计
直播管理系统里天然存在四种角色：平台管理员、运营人员、主播、普通用户。如果只做一张user表然后塞一个role字段，确实最简单，但会带来一个管理问题——不同角色的菜单权限和操作权限完全不同，比如运营人员能审核直播间但无法修改平台分成比例，主播能查看自己的收益但不能查看平台整体营收。因此在权限设计上，我选择了RBAC模型，即用户-角色-权限三层结构。
具体的表结构我是这样设计的：
- sys_user：用户主表，字段包括user_id、username、password、phone、avatar、status、create_time。密码用BCrypt加密存储，绝不存明文。
- sys_role：角色表，角色编码admin、operator、anchor、user。
- sys_user_role：用户角色关联表。
- sys_menu：菜单表，记录每个可点击的菜单项和按钮。
- sys_role_menu：角色菜单关联表。
实际开发里，我不推荐一上来就去集成Spring Security那一套重型的权限框架（当然，项目要求用Shiro或Security另说），因为那会让项目多出很多配置和概念，学习成本陡增。自己做一套基于拦截器+注解的轻量级权限控制反而更直观。核心思路是：定义一个@RequireRole注解，标注在Controller方法上，拦截器在请求进入时读取当前登录用户的角色，和注解要求比对，不匹配就返回401。这样代码直观，答辩时讲起来也更清楚。
3.2 主播管理与直播间生命周期
主播不是一个独立的用户类型，而是用户在platform_anchor表中多了一条“主播认证”记录。这个设计的好处是一个用户既可以作为普通用户看直播，也可以申请成为主播开直播，身份天然兼容。主播表我保留了这些关键字段：
- user_id：关联用户主键
- anchor_name：主播昵称
- real_name：真实姓名，用于结算
- id_card：身份证号（演示时可写脱敏示例）
- audit_status：审核状态，0待审，1通过，2驳回
- commission_rate：分成比例，小数0.3表示平台拿30%的固定比例
- level：主播等级，由平台根据开播时长和收入动态计算
直播间的生命周期我是用状态机管理的。直播间表live_room的status字段按照0新建待审 -> 1审核通过待开播 -> 2直播中 -> 3已结束 -> 4违规封禁流转。为什么一定要状态机？因为直播间的状态不是可以随便跳的，比如一个违规封禁的房间不允许再进入直播中状态，一个正在直播的房间也不能被简单地编辑封面和标题。把整个生命周期画成一个有向图，每个状态定义出合法的流转路径，代码里只放行合法流转，这样就能把业务规则固化下来，避免脏状态出现。
3.3 礼物、金币与分成结算设计
礼物和金币是直播平台最主要的变现方式。我没有把人民币直接作为直播间里的打赏单位，而是设计了两层结构：用户用人民币充值获得金币，再用金币购买礼物送给主播。这个中间层的设计非常关键，它把支付和打赏解耦开了，后续做首充赠送、打折活动都在这层展开。
具体的数据流是这样的：
- 用户点击充值，生成recharge_order订单记录，订单状态为0待支付。
- 调用演示环境的支付模拟接口，把状态更新为1已支付，同时调用user_account里的金币余额更新，这里需要事务保证。
- 用户赠送礼物时，创建gift_record打赏记录，扣减自己的金币，增加主播账户的待结算金额。
- 平台和主播的收益，按“（礼物人民币价格-平台服务费）× 主播分成比例”公式计算，划入anchor_wallet表。
这里最主要的一个设计原则是“一切金额变更都要有流水”。我建了account_change_log表，任何金币变动、余额变动都插入一条流水记录。这样即使哪天账不平，也能通过流水回溯，这也是企业级系统里账务设计的基本功。
3.4 弹幕交互与公告系统
弹幕功能如果做得简陋一点，最简单是前端定时轮询接口获取最新消息，每3秒请求一次，压力可以接受，实现也非常简单。如果做得高级一点，也是我推荐的方式，就是用WebSocket推送。SpringBoot里使用WebSocket只需要引入spring-boot-starter-websocket，实现一个TextWebSocketHandler的处理器，把在线会话存在ConcurrentHashMap中，收到弹幕消息后群发给当前直播间的所有连接即可。
为了降低WebSocket的复杂度，我在项目里做了折中方案：弹幕发送接口保留为HTTP POST，后端把消息写入数据库后，再通过WebSocket把这条消息推送给直播间的在线用户。也就是说，WebSocket只负责“推送”，不负责“接收业务请求”。这样的好处是弹幕消息也会写入数据库留痕，而不是只存在于内存中，后续做弹幕过滤、历史弹幕查询就很容易。
公告系统就比较常规了，一张notice表，字段包括title、content、publish_time、status，管理员在后台发布，前台直播页面拉取最新的公告展示。真正要留意的是公告内容的XSS问题，比如富文本里嵌入script标签。我在后端做了简单的HTML标签过滤，把
