简介：基于Java语言的企业级多媒体信息发布系统设计源码，面向具备Java基础的系统开发与运维人员，用于解决跨平台终端上的图片视频轮播、滚动字幕、日期时间展示，以及设备统一管控与节目定时发布等实际需求。资源共23个文件，压缩包大小4.38MB，包含PNG界面设计图、Markdown设计文档、YAML与配置文件、Shell脚本及MySQL Dockerfile等，覆盖界面设计、服务配置与容器化部署等环节，目录结构清晰，便于按模块查阅。系统采用组件化设计，具备设备管理、监控、远程控制等后台能力，并适配Android、Windows、Linux及国产统信系统，可作企业信息发布平台的二次开发蓝本，也可用于学习终端适配与多媒体调度逻辑；其中框架图、离线镜像及加载脚本等辅料，有助于快速理解整体架构与部署流程。已有324人学习浏览，对需要构建或改造多媒体发布项目的技术人员具有直接借鉴价值。

1. 基于Java的丰富组件企业级多媒体信息发布系统：这套源码到底解决什么问题

接手公司一楼的 20 块信息屏时，你大概率会遇到同一个场景：屏幕品牌杂、分辨率不统一、素材靠 U 盘拷贝，老板还要求今天下午两点前所有屏都换成新海报。这时如果手上有一套“基于Java的丰富组件企业级多媒体信息发布系统设计源码”，核心问题就被收敛成了三件事：素材怎么管理、终端怎么管、播放计划怎么下发。它不是一个单纯的后台管理系统，而是“管理端 + 服务端 + 播放终端”的完整闭环。

适合做这件事的人有两类：一类是 Java 后端开发，想在企业级数字标牌、排队叫号、会议室门牌这类项目里直接复用；另一类是实施工程师，需要评估这套源码能不能扛住几十台到几百台终端的集中发布。下文我会按一套可落地的设计源码来拆：先定技术栈，再建表写接口，最后讲清楚转码、下发和上线避坑，让你照着能复现，而不是只看概念。

2. 企业级多媒体信息发布系统的组件选型：先定技术栈再谈功能

2.1 一条发布链路：素材、计划、终端是怎么串起来的

理解这套源码，不要从代码开始，而是先从一条发布链路开始。管理端上传一张图片或一段视频，服务端把原始文件存进对象存储，同时丢给转码服务做格式统一；等转码完成，资源状态从“转码中”变成“可用”。运营人员创建播放计划，选择素材、终端分组和生效时间段，审核通过后，调度器在计划生效时间生成发布任务；终端通过定时心跳把任务拉走，下载素材并开始播放。

这条链路决定了系统的表结构和接口风格，也决定了哪些中间件必不可少。常见的企业级实现是 Spring Boot 提供 REST API，MySQL 存业务数据，Redis 缓存终端在线状态和播放清单，RabbitMQ 做转码和发布任务的异步消息，XXL-Job 负责凌晨这种低峰期的定时调度。FFmpeg 是独立进程，可以被 Java 代码拉起进行转码。这样的拆分，让管理后台实操时不会因为一次大批量素材上传而把接口拖垮。

实际操作时建议按下面的顺序搭建：

1. 先跑通“上传素材 -> 转码 -> 终端拉取播放清单”最短链路；
2. 再补播放计划、定时发布、插播等业务能力；
3. 最后加权限、日志、监控和告警。

很多团队一上来就设计十几张表和十几个模块，结果第一周连一块屏都跑不起来。最短链路能帮你验证组件选型是否合理，比如 FFmpeg 在服务器上能不能调得通、终端按照什么样的协议回心跳。这条链路一旦通了，后续加功能都只是在这个骨架上面长内容。

2.2 组件选型对照表：这些中间件是“企业级”的底气

把这套源码称为“企业级”，不是因为代码量大，而是因为它把每个环节的组件都选到了能扛住实际生产的水平。下面这张表是我在同类项目中常用的一组选型，你可以直接当作参考基线：

为什么不是几台终端就选轻量方案？多媒体发布系统的并发压力不在管理后台，而在终端心跳和素材下载。1000 台终端每 30 秒一次心跳，就是每秒 33 个请求，虽然绝对量不大，但如果每次心跳都去 MySQL 做一次“更新最后一次心跳时间”的写操作，高峰期会产生大量行锁和慢 SQL。Redis 的价值在这里体现得最明显：心跳只写内存，定时再批量同步到数据库，接口响应时间能从几十毫秒降到个位数毫秒。

RabbitMQ 和 XXL-Job 也不是摆设。素材转码通常耗时从几秒到几分钟不等，如果用同步接口处理，前端上传一个大视频会一直等到超时。把“转码指令”丢进队列后，接口立刻返回“转码中”，由独立消费者慢慢处理，这才符合企业级系统的基本体验。定时发布同样如此，运营人员设置的是凌晨 00:00 生效，服务端不可能用后台线程去扫每秒需要执行的任务，交给 XXL-Job 分片执行才是成熟做法。

2.3 前端“丰富组件”怎么拆：播放组件与后台组件分层设计

标题里的“丰富组件”很多人以为是后台 UI 组件多，实际上更关键的是播放器端的组件。企业级多媒体信息发布系统的屏幕上有轮播图组件、视频组件、时钟组件、天气预报组件、滚动字幕组件，甚至还有自定义网页组件。这些组件需要在一个页面里组合排列，所以播放器核心要定义一套“播放单元”的 JSON 结构，服务端只下发组件类型、坐标、层级、素材地址和时长，终端负责渲染。

组件之间的通信也需要设计，常见做法是事件总线：天气组件每小时刷新、滚动字幕组件在视频结束后切换、轮播图组件按权重选片。组件通信如果做不好，会出现视频已经播完了，字幕还在等一个永远不来的事件。在企业级项目里，我会把组件消息统一收敛到播放器内部的一个调度器，每个组件注册自己的状态，调度器负责广播“视频播放完成”这类全局事件。

管理后台侧的丰富组件则主要体现在表单和可视化上。素材选择器要用到懒加载树、级联选择器、拖拽排序；播放计划编排界面要用到时间轴组件；统计报表要用到企业级数据可视化图表库。这些组件的选型不需要你从零写，Vue3 生态里 Element Plus 加 ECharts 基本够用。重点是组件的数据接口要稳定，比如终端列表组件只依赖/api/terminal/list和/api/terminal/group/tree，这样换组件库时服务端不用跟着改。

3. 落库与接口设计：照这个表结构能少改三轮需求

3.1 五张核心业务表：终端、素材、播放计划、发布任务、心跳

表结构是一套源码设计水平最直接的体现。我见过不少项目把素材的播放时长、分辨率、文件路径全部塞进一张大表里，看起来字段齐全，实际上 select 列表时会把大字段一次性拖出来，接口响应慢不说，后续扩展终端自定义参数根本没法加。常见做法是拆成五张核心表：终端表、素材表、播放计划表、发布任务表、素材-计划关联表。终端表管设备；素材表管资源；播放计划表管时间策略；发布任务表管一次实际下发；关联表表达计划里有哪些素材。

下面是一份可运行的建表参考，我重点标出关键字段：

CREATE TABLE tb_terminal ( id BIGINT AUTO_INCREMENT PRIMARY KEY, terminal_code VARCHAR(64) NOT NULL COMMENT '终端唯一编码', terminal_name VARCHAR(128) NOT NULL, group_id BIGINT DEFAULT 0 COMMENT '终端分组ID', screen_width INT DEFAULT 1920, screen_height INT DEFAULT 1080, os_type VARCHAR(32) DEFAULT 'android', status TINYINT DEFAULT 0 COMMENT '0离线 1在线', last_heartbeat_time DATETIME NULL, created_at DATETIME NOT NULL, UNIQUE KEY uk_terminal_code (terminal_code) ) ENGINE=InnoDB COMMENT '终端表'; CREATE TABLE tb_media_asset ( id BIGINT AUTO_INCREMENT PRIMARY KEY, asset_name VARCHAR(255) NOT NULL, asset_type VARCHAR(16) NOT NULL COMMENT 'image/video/audio/web/scroll', source_url VARCHAR(512) NOT NULL COMMENT '原始文件地址', transcode_url VARCHAR(512) NULL COMMENT '转码后地址', status TINYINT DEFAULT 0 COMMENT '0转码中 1可用 2失败', duration INT DEFAULT 0 COMMENT '素材时长秒', file_size BIGINT DEFAULT 0, md5 VARCHAR(64) NULL, created_at DATETIME NOT NULL ) ENGINE=InnoDB COMMENT '素材表'; CREATE TABLE tb_playlist ( id BIGINT AUTO_INCREMENT PRIMARY KEY, plan_name VARCHAR(128) NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, priority INT DEFAULT 5 COMMENT '优先级，越大越优先', status TINYINT DEFAULT 0 COMMENT '0草稿 1已发布', created_at DATETIME NOT NULL ) ENGINE=InnoDB COMMENT '播放计划表'; CREATE TABLE tb_playlist_item ( id BIGINT AUTO_INCREMENT PRIMARY KEY, playlist_id BIGINT NOT NULL, asset_id BIGINT NOT NULL, sort_order INT DEFAULT 0, play_duration INT DEFAULT 0 COMMENT '播放秒数，0则取素材自身时长', position_x INT DEFAULT 0, position_y INT DEFAULT 0, width INT DEFAULT 1920, height INT DEFAULT 1080 ) ENGINE=InnoDB COMMENT '播放计划-素材关联表'; CREATE TABLE tb_publish_task ( id BIGINT AUTO_INCREMENT PRIMARY KEY, playlist_id BIGINT NOT NULL, terminal_id BIGINT NOT NULL, task_status TINYINT DEFAULT 0 COMMENT '0待下发 1已下发 2播放完成 3失败', publish_time DATETIME NOT NULL, finish_time DATETIME NULL, retry_count INT DEFAULT 0 ) ENGINE=InnoDB COMMENT '发布任务表';

注意两张关联表的设计：tb_playlist_item把“这个计划里有哪些素材”拆出来，而不是在播放计划表里存一个逗号分隔的素材 ID 列表。逗号分隔的方案第一版能跑，但一旦出现“同一素材在不同计划里播放时长不同”的需求，就只能到处拆分字符串，那时候再改表就晚了。发布任务表则记录了一次计划对一台终端的下发情况，方便做失败重试和报表统计。

这里还要处理一个关键边界：同一台终端可能同时命中多个播放计划。比如 9:00-12:00 是商品促销，18:00-21:00 是品牌宣传，两个计划时间不重叠时还好办；一旦有重叠，终端到底播哪个？我的做法是在服务端计算播放清单时直接按优先级排序，高优先级计划播完后再切到低优先级计划，而不是让终端自己选。

3.2 服务端接口设计：上传、排期、拉流的三个关键入口

接口设计遵循一个直觉：管理端接口密集，终端接口精简。管理端需要素材上传、计划增删改查、审批、预览、报表；终端侧实际只需要三个接口，一个是注册/更新终端信息，一个是心跳拉取播放清单，一个是上报播放状态。下面这段代码是一个素材上传接口的简化版，对应 Spring Boot 后端最常见的写法：

@RestController @RequestMapping("/api/media") public class MediaController { private final MediaAssetService mediaAssetService; private final TranscodeProducer transcodeProducer; @PostMapping("/upload") public Result<MediaAssetVO> upload( @RequestParam("file") MultipartFile file, @RequestParam("assetType") String assetType) { // 1. 校验文件大小和类型 if (file.isEmpty() || file.getSize() > 5L * 1024 * 1024 * 1024) { return Result.fail("文件为空或超过5GB限制"); } // 2. 存储原始文件到本地或MinIO，返回相对路径 String sourcePath = storageService.save(file); // 3. 创建素材记录，状态为“转码中” MediaAsset asset = mediaAssetService.create(file.getOriginalFilename(), assetType, sourcePath, file.getSize()); // 4. 发送转码消息，异步处理 transcodeProducer.send(asset.getId(), sourcePath); return Result.ok(MediaAssetVO.from(asset)); } }

这段代码把“接收上传”和“处理转码”彻底解耦。storageService.save(file)是独立接口，你可以在本地磁盘实现，也可以换成 MinIO 实现，后续迁移只改一个类。transcodeProducer.send把素材 ID 和源文件路径交给消息队列，消费者拿到消息后用 FFmpeg 转码，转码完成后回调更新素材状态。

终端拉流的接口更要克制，常见的做法是让终端只传一个terminalCode，服务端返回播放清单：

@GetMapping("/terminal/poll") public Result<PlaylistVO> poll(@RequestParam("terminalCode") String terminalCode) { Terminal terminal = terminalService.getByCode(terminalCode); // 只返回当前时间点生效且该终端可见的播放内容 PlaylistVO playlist = playlistService.buildForTerminal( terminal.getId(), LocalDateTime.now()); return Result.ok(playlist); }

终端不参与业务判断，比如计划时间判断、优先级判断全部放在服务端。这种设计的优点是播放器逻辑可以保持很薄，后续如果终端从 Android 换成 Web，接口协议完全不用变，播放器只负责解析 JSON 和渲染组件。缺点是对服务端接口的并发能力要求更高，所以心跳接口必须走 Redis 缓存：终端信息、播放清单初次生成后可以缓存 30 秒，没有变化就返回短小的“无更新”响应。

3.3 数据一致性：发布任务怎么避免“只发了一半”

企业级系统最怕的是发布计划创建成功后，任务明细只生成了部分终端。比如选择 50 台终端发布，结果 30 台有任务，剩下 20 台因为数据库偶发异常漏了。要避免这个问题，创建发布任务必须放到一个数据库事务里，并且要有一个独立的“核对任务”兜底。

常见做法是创建计划时只插入tb_playlist，然后在同一事务中批量查询命中终端并插入tb_publish_task。如果批量插入过程中任何一台失败，整个事务回滚，不会出现半截数据。但事务只保证“原子性”，不保证“终将完成”，所以还要靠 xxl-job 的定时任务去扫描：当前时间在计划生效时间范围内，但还没有生成对应tb_publish_task的终端，补生成任务。这个兜底任务跑在凌晨低峰期，即使前面有极端情况漏了，也能在几分钟内补齐。

接口时序上还要注意一个坑：不要用前端调用了“发布”按钮就认为发布完成。发布接口只负责创建任务，实际下发由终端心跳触发。所以管理后台的发布状态不要做成“成功/失败”，而应该做成“待生效、下发中、已完成、部分失败”。这个语义如果不提前定好，后面统计报表一定会返工。

4. 素材转码与任务下发：把视频和图片变成屏幕上的播放清单

4.1 FFmpeg 统一转码：命令参数与 Java 封装

多媒体信息发布系统里最常翻车的就是视频播放。终端盒子支持格式五花八门：有的支持 H.265，有的只支持 H.264；有的音频编码是 AC3，到了廉价播放器上只有画面没有声音。所以服务端必须对所有视频做统一转码，不能依赖终端能力。统一转码的基准命令我一般用下面这条：

ffmpeg -y -i input.mov \ -c:v libx264 -preset veryfast -crf 23 -profile:v main \ -pix_fmt yuv420p -s 1920x1080 -r 25 \ -c:a aac -b:a 128k -ac 2 -ar 44100 \ -movflags +faststart \ output.mp4

参数说明：

• -c:v libx264：把视频编码统一成 H.264，兼容性最好；
• -profile:v main：去掉 High profile 里一些老设备不支持的编码特性；
• -pix_fmt yuv420p：强制 4:2:0 像素采样，否则部分安卓播放器出现绿屏；
• -movflags +faststart：把 moov 元数据移到文件头部，终端不用等整个文件下载完就能起播，这是大视频体验优化的关键；
• -r 25和-s 1920x1080：统一帧率和分辨率，避免播放器切素材时画面跳动。

Java 端不建议用Runtime.exec直接拼命令，因为命令行参数里容易出现空格、中文路径问题。更可控的方式是用ProcessBuilder，把命令参数拆成列表传入：

List<String> command = new ArrayList<>(); command.add("ffmpeg"); command.add("-y"); command.add("-i"); command.add(sourcePath); command.add("-c:v"); command.add("libx264"); // ... 其余参数 ProcessBuilder pb = new ProcessBuilder(command); pb.redirectErrorStream(true); Process process = pb.start(); // 设置超时时间，防止ffmpeg进程卡死 boolean finished = process.waitFor(30, TimeUnit.MINUTES); if (!finished) { process.destroyForcibly(); throw new TranscodeTimeoutException(sourcePath); }

这里最容易被忽略的是超时和日志。转码进程如果因为输入文件损坏卡住，不设置超时的话，它会一直占着 CPU 甚至占着临时磁盘空间。有了waitFor(30, TimeUnit.MINUTES)，超时后destroyForcibly把进程杀掉，再把转码任务标记为失败并放进重试队列。转码日志可以单独写到磁盘，方便排查具体是哪一帧出了问题。

4.2 播放清单生成：心跳接口为什么只返回 JSON 不返回任务明细

服务端给终端下发的不是“任务列表”，而是“播放清单”。这是一个很多源码没想清楚的点。任务列表表达的是“你要播这个计划”，播放清单表达的是“你现在这一轮要播哪些内容、每个内容播多久、位置在哪”。清单是经过服务端计算后的最终结果，终端拿到就能直接渲染，不用关心优先级、计划重叠这些复杂规则。

生成播放清单时，我一般会写成独立的 Service 方法，便于后续加缓存和做接口复用：

public PlaylistVO buildForTerminal(Long terminalId, LocalDateTime now) { // 1. 查出终端所在分组 Terminal terminal = terminalService.getById(terminalId); // 2. 查询当前时间点对该分组生效的播放计划 List<Playlist> playlists = playlistMapper.selectActive(terminal.getGroupId(), now); // 3. 按优先级排序，相同优先级随机轮播 playlists.sort(Comparator.comparingInt(Playlist::getPriority).reversed()); // 4. 取最高优先级的计划，生成播放项列表 PlaylistVO vo = new PlaylistVO(); vo.setPlanId(playlists.get(0).getId()); for (PlaylistItem item : playlistItemMapper.selectByPlaylistId(playlists.get(0).getId())) { MediaAsset asset = mediaAssetMapper.selectById(item.getAssetId()); vo.addItem(PlayItemVO.builder() .assetType(asset.getAssetType()) .url(asset.getTranscodeUrl()) .duration(item.getPlayDuration()) .positionX(item.getPositionX()) .positionY(item.getPositionY()) .build()); } return vo; }

注意第 3 步的排序：如果两个计划优先级相同，简单的固定排序会让同一个计划永远排前面，另一个计划永远不播。更好的做法是按priority排序后，对相同优先级的计划做加权轮询。实现时可以在计划表上加一个weight字段，生成清单时用随机数按权重选一个，这样屏幕内容不会永远集中在某几个素材上。

播放清单返回后，ttl一般设置 30 到 60 秒。终端在这段时间里不需要重复请求接口，即使服务端突然重启，终端也能继续播完当前清单。这个设计也是为了让终端在弱网环境下降级成“播缓存”，而不是直接黑屏。如果终端 3 次心跳失败，服务端将其标记为离线，并在管理后台告警。

4.3 终端离线补拉与插播：企业级常见的设计补丁

离线补拉是很容易被忽略的场景。终端可能因为断电、网络波动离线几小时，恢复后必须能自动补齐错过的任务。实现上不需要服务端做太多事，只要终端每次心跳带上自己当前播放的清单 ID，服务端对比后发现不是最新的，就返回“需更新”。终端拉取新清单按顺序播放即可，不需要支持断点续传级别的任务队列。

插播则是另外一种常见需求：火灾预警、领导讲话、紧急通知需要立刻盖住当前计划。处理插播最简单的方式是把插播计划优先级拉满，并设置一个很短的生效时间窗。服务端生成播放清单时发现插播计划存在，返回给终端的priority是 99，终端播放器中断当前内容，先播插播内容。插播结束后终端回到常规计划，这个回退动作同样由播放器根据清单里的“计划 ID”判断。

插播的坑在于认证：如果插播接口被滥用，任何终端都能发插播请求，屏幕会被恶意内容覆盖。企业级做法是插播接口单独走管理端审批，并且必须携带管理员 token，不能放到终端心跳接口里。考虑到操作人员的紧急程度，审批可以做成“一键通过”，但一定不能绕过。

5. 源码落地避坑：企业级多媒体信息发布系统最容易翻车的五个地方

5.1 上传的 MP4 在终端黑屏：转码参数没有统一

现象：管理后台上传了一个 1080p 的 MP4，列表里能看到预览，但终端拉取后播放只有声音没有画面，或者直接黑屏。换个终端品牌又正常，很难用“素材损坏”来解释。

原因：终端播放器对视频编码的兼容性参差不齐。原始 MP4 可能是 H.265 编码，也可能视频流包含high profile特性；还有一部分视频的音频是 AC3，播放器不支持音频解码，导致播放器直接进入错误状态。最隐蔽的情况是某些手机录制的视频用了bt2020色彩空间，旧安卓盒子渲染不出来。

解决：所有视频素材必须通过第 4.1 节的统一转码，并且转码完成后还要做“抽帧验证”：用 FFmpeg 转码后的文件抽取第一帧生成 JPEG，能抽出来说明转码过程没坏。转码状态只有从“转码中”变成“可用”之后，素材才能被选入播放计划。这条规则要在源码里强制，不要依赖运营人员上传时就给标准格式。

5.2 定时发布半夜不生效：时区和 cron 设置双保险

现象：运营人员设置播放计划 00:00 生效，第二天早上到公司发现屏幕还在播前一天的内容。看发布任务表，发现任务的publish_time是当天下午的时间，等于晚了一整天。

原因：服务器操作系统时区是 UTC，MySQL 连接串里没有设置serverTimezone，导致 Java 里的LocalDateTime写入数据库时被当成了 UTC 时间。XXL-Job 的 cron 同样受服务器时区影响，凌晨 00:00 实际上要等 UTC 00:00，也就是北京时间早上 08:00 才触发。

解决：服务器时区统一改为Asia/Shanghai，MySQL 连接串加上serverTimezone=Asia/Shanghai&useLegacyDatetimeCode=false。业务接口里所有时间参数统一用时间戳或LocalDateTime接收，数据库统一存东八区时间，不让前端传字符串让后端猜格式。再加一个最简单的漏跑检测：每次定时发布执行后，向监控表写一条执行记录，第二天检查预期次数和实际次数是否一致。

5.3 终端掉线，数据库连接数被打满：心跳不能走普通插入

现象：上线第一天还好，第二天接入 500 台终端后管理后台频繁卡死，数据库连接池报HikariPool-1 - Connection is not available, request timed out，终端在线状态显示大面积离线。

原因：终端心跳接口每 30 秒一次，每次都要UPDATE tb_terminal SET last_heartbeat_time=now() WHERE terminal_code=?。这个更新虽然单条很快，但集中在一个固定时刻发来会让数据库线程直接打满。更糟的是有些源码在心跳接口里顺带查询了一堆终端详情，慢 SQL 把连接占住不放。

解决：心跳接口先只更新 Redis，比如SET terminal:online:{code} {timestamp} EX 90，然后让终端状态接口从 Redis 读在线状态。数据库的last_heartbeat_time改为异步批量更新，比如每分钟收集 Redis 里变化过的终端，用一条INSERT ... ON DUPLICATE KEY UPDATE批量写入。这样数据库每秒的写放大从几百次降到几次，连接数自然回落到正常水位。

5.4 转码进程假死，素材库里一堆“转码中”

现象：素材管理页面里突然出现大量“转码中”状态，数据一动不动持续几个小时。查看服务器进程，发现十几个ffmpeg进程都处于 D 状态，CPU 不高但磁盘 IO 高到异常。

原因：多个转码任务同时启动，FFmpeg 进程数超过了 CPU 核心数，系统上下文切换严重，进程互相争抢磁盘 IO 导致卡死。还有一种是输入文件本身有损坏帧，FFmpeg 在某一帧上重试，长时间没有输出。

解决：转码执行线程池的线程数不要超过 CPU 核心数减一，同时每个进程加超时。我用的是ThreadPoolExecutor配置 4 到 8 个线程，队列放 200 个任务，再多就到 RabbitMQ 里排队。每条转码消息必须记录开始时间和转码进程 PID，定时任务每 10 分钟扫描一次，发现“转码中”超过 30 分钟就杀掉进程并把消息重新入队。不要小看这个保护逻辑，生产环境 90% 的“转码中卡死”都是因为没有这个兜底。

5.5 后台列表筛选越来越慢：大字段和 N+1 是元凶

现象：素材列表刚打开时很快，加了筛选条件后越来越慢，尤其是选择“视频”加“已转码”之后，接口要好几秒才能返回。数据库 CPU 不高，但接口响应就是慢。

原因：列表接口直接把tb_media_asset全部字段返回，其中source_url、transcode_url这种 512 字节的字段都还好，问题出在列表里还连查了tb_playlist_item，每个素材都查一次数据库，产生了 N+1 查询。筛选条件没有索引也是雪上加霜。

解决：列表接口只查列表必需字段，详情字段单独接口返回。关联查询改成一次查出所有playlist_item，然后在内存里按asset_id聚合，不要循环单查。给tb_media_asset加上(asset_type, status, created_at)联合索引，筛选时走索引。还有一条很直接的经验：管理后台列表默认只查最近 30 天数据，历史素材走归档查询，这样无论数据量涨到多少，列表都能保持在一个可控的响应范围。

6. 用模拟终端验证这套发布系统：从代码到上线前最后一步

6.1 30 行脚本模拟终端心跳，验证下发链路

如果你手头没有真实的安卓盒子，不要等硬件到位再测。用一个 Python 脚本模拟终端心跳，就能把整套链路验证完：上传素材、创建计划、终端拉取清单、上报状态。脚本很简单，每分钟向心跳接口请求一次播放清单，并把返回的素材 URL 打印出来。

import requests import time while True: resp = requests.get( "http://localhost:8080/api/terminal/poll", params={"terminalCode": "T-001"}, timeout=10 ) data = resp.json().get("data") if data and data.get("items"): print(time.strftime("%H:%M:%S"), "拉取到", len(data["items"]), "条播放项") for item in data["items"][:3]: print(" ", item["assetType"], item["url"]) else: print(time.strftime("%H:%M:%S"), "无更新") time.sleep(30)

把终端编号固定成T-001，在管理后台也注册一台相同编号的终端并分组，然后给它创建一个播放计划。脚本不断打印播放项，说明素材转码、播放清单生成、终端心跳接口这几个核心模块都正常工作。模拟终端可以多开几个，验证不同分组的终端拉取到的内容是否互相隔离。

6.2 上线前看三个数：下发成功率、心跳率、转码积压

模拟终端跑通后，还要在真实环境验证三个指标。第一个是任务下发成功率：已生效的发布任务里，最终被终端确认播放的数量占比，低于 95% 就要去查任务重试逻辑。第二个是终端心跳率：单位时间内发来心跳的终端数除以在线终端总数，低于 80% 说明网络或心跳接口有瓶颈。第三个是转码队列积压数：RabbitMQ 里待转码消息数量，高峰期积压超过 100 条就要扩容转码线程或者优化转码码率。

我习惯在源码里加一个轻量监控接口，把这三个数暴露出来，配合告警做日报。不要等用户投诉了再查黑匣子，监控界面哪怕只有三行数字，也能让你在上线初期快速定位绝大多数问题。这套系统最怕的不是功能多，而是素材上传后没人确认转码结果、计划发布后没人确认终端有没有收到。用模拟终端跑一晚，再盯着三个指标看三天，比你在 IDE 里反复读代码有用得多。希望我的这些踩坑经验能帮你少走一段弯路，也希望你的屏幕墙从第一天起就能顺利亮起来。

本文还有配套的精品资源，点击获取