Wong Kosheng第一次看到“springboot小程序led广告屏app”这种项目需求时，我第一反应是：需求方通常把一整套系统理解成了一个普通App。做下来之后才发现，真正要交付的是四样东西的协同——后端用springboot提供接口和调度能力，小程序给广告主或管理人员做移动入口，LED广告屏是终端执行设备，而“app”往往不是给普通用户下载的客户端，而是跑在屏端主板上的播放器，或者给运维人员用的巡检工具。
这四条线只要理顺了，这套系统就成功了一半。怕就怕一上来就急着写页面、调接口，结果业务模型没立住，后面每加一块屏幕都是灾难。
这篇文章我就按自己做过的类似项目来拆解，把业务参与方、springboot骨架、设备接入、内容下发链路、小程序和App的职责边界，以及部署时会踩的坑全部过一遍。看完以后，即使你手里的客户需求还比较模糊，也至少知道该怎么去问、怎么去设计、怎么排优先级。
1. 四端协作的业务到底在说什么：屏、后台、小程序和App各管哪一段
LED广告屏这个行业看上去是硬件生意，实际做软件方案时，会同时撞上好几类需求：屏主想知道自己那几块屏现在是否正常播放；广告主想自己上传素材、选屏、定时长；运营方要做内容审核，要看到屏端的播放日志；维修人员又盼着能远程判断设备是大屏坏了还是网络断了。
如果你只做一个小程序给所有人用，体验一定很差。广告主不需要看到设备电压和信号强度，维修人员也不关心素材排期，强行塞进同一个页面只会互相干扰。所以在动工以前，必须先把角色拆出来。
1.1 一个看似简单的广告屏项目，背后至少有三个参与方
第一类是屏主或者物业。他们关心设备在不在线，播放是否正常，屏幕被砸了或者断电了能不能第一时间发现。这类需求对应的是设备管理和告警能力，像心跳超时、离线提醒、远程重启指令这类功能，都会在这一层出现。
第二类是广告投放方。可能是门店市场部的人，也可能是本地小商家。他们不会关心技术实现，只想知道：把图片或短视频传上去，选一块人流量大的屏，选个时间段，付完钱就完事。这类需求对应的是素材管理、屏位选择、投放时段和订单状态。
第三类是平台运营方。他们要审核广告内容是否违规，要处理极端情况下的紧急插播，还要按月给客户出播放报告。广告屏不像手机App可以随时强更，内容一旦播出去影响是实打实的，所以审核和日志回放这两件事，在技术方案里不能省。
1.2 为什么最后会拼成“springboot+小程序+App”的形态
小程序的价值是获客和登录成本低。广告主在微信里扫码就能打开，不用另外装App，素材上传、订单查询、历史投放记录都在里面完成；运营人员也可以在审批消息里点开小程序进行快速审核，这是原生App很难替代的便利性。
但小程序不适合做屏幕端的常驻播放器，因为微信生态对后台播放、视频无缝循环、开机自启这些能力限制很严格。LED屏的播放器需要长时间不熄屏、断网自动重连、定时重启，必须有一个独立App装在屏端安卓主板上才行。
springboot后端在这里其实是“总调度室”。设备列表、素材元数据、播放任务、播放日志、账号权限，这些公共数据不能散落在小程序或App各自的本地存储里。尤其当屏端数量变大之后，后端的设备管理能力和任务调度能力，直接决定了系统能不能规模化。简单来说：小程序负责入口，App负责执行，springboot负责把两边串起来。
1.3 核心数据表先设计好，后面能省掉一大半返工
没有项目正文的情况下，我只能按最常见的业务模型来设计，但如果你拿着这套表结构去和客户对齐需求，十有八九对方会说“对对对，就是这个意思”。LED广告屏管理系统的核心表大概是这些：
| 表名 | 作用 | 关键字段 | 说明 |
|---|---|---|---|
| device_info | 屏幕设备档案 | 设备编号、屏名、分辨率、经纬度、商圈、心跳时间、状态 | 一张屏对应一台安卓播放盒子 |
| material_info | 广告素材 | 文件名、素材类型、大小、时长、md5、URL、审核状态 | 图片或视频，建议都算md5避免重复存储 |
| play_task | 播放任务 | 任务编号、设备ID、素材ID、生效开始/结束时间、优先级、审核状态 | 一条任务至少要绑定一个屏和一个素材 |
| ad_order | 广告订单 | 订单号、广告主账号、任务ID、金额、支付状态 | 如果只是内部自用，可简化成投放记录 |
| play_log | 播放日志 | 任务ID、设备ID、素材ID、计划播放时间、实际上报时间、播放时长 | 所有的统计报表都从这里出 |
| account_info | 账号信息 | openid、unionid、昵称、手机号、角色类型 | 把小程序的微信身份和服务端账号做关联 |
需要提醒一点：play_task里冗余了device_id和material_id，这在数据库设计上不是最简范式，但业务上非常实用。因为查询“某块屏当前该播什么”的频率远高于其他查询，冗余字段可以少写很多关联SQL。
表之间的关系也简单：一个广告主可以下多个订单，一个订单会生成多个播放任务，一个素材可以被多个任务引用，但任务最好拆细到“某一台屏、某一个素材、某一段时间”。刚开始我只建了订单表，结果客户说同一个素材在周末和平时播放的时段不同，不得不加任务子表去解。现在回头看，任务表一步到位是最省事的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. SpringBoot后端的骨架搭建与设备管理实现
springboot在这个项目里承担的工作，说出来并不神秘：提供REST接口给小程序端和App端调用，保存设备、素材、任务数据，下发控制指令，定时扫描过期任务和离线设备。但这些常规工作在广告屏场景下有几个容易被低估的点，值得单独拿出来讲。
2.1 版本选型别贪新：springboot版本太高会带来一串连锁问题
如果团队技术栈还停留在JDK8，千万别直接选最新版springboot。Spring Boot 3.x要求JDK17起步，并且把javax.servlet这一整套命名空间迁到了jakarta.servlet，如果项目里用了老版本的MyBatis、Druid或者一些第三方SDK，升级后会遇到编译不过或者某些拦截器失效的怪问题。
我个人的建议是这样：
| 场景 | 推荐方案 |
|---|---|
| 全新项目，服务器可以装高版本JDK | Spring Boot 3.x + JDK17 + MyBatis-Plus 3.5.3以上 |
| 团队现有JDK8，想先用老一套稳定跑 | Spring Boot 2.7.x + JDK8，依赖基本不会踩坑 |
| 需要集成比较老的硬件厂商SDK | 先确认SDK是否兼容Jakarta命名空间，不兼容就留在2.7 |
项目结构上，后台管理界面如果要用Vue做前后端分离，那springboot只做接口层即可。模块上我习惯按`controller/service/ma