WebSocket连接后收不到弹幕，主因是Session被意外关闭；需检查isOpen()、避免异步未发送、禁用轮询改用SimpMessagingTemplate；弹幕时间应服务端归一化为offsetMs；高并发广播改用CopyOnWriteArraySet；XSS防护须后端白名单过滤。
WebSocket 连接建立后收不到弹幕消息？检查 Session 是否被意外关闭
Java 后端用 WebSocketHandler 或 @OnMessage 接收前端消息时，常见问题是连接看似建立成功，但后续发来的弹幕数据根本没进处理逻辑。核心原因往往是：Spring 的 WebSocketSession 在 handler 执行完方法后被自动关闭，尤其在用了异步操作（比如往 ConcurrentHashMap 里写入后没主动调用 session.sendMessage()）或未捕获异常时。
- 确保每次广播弹幕前，先用
session.isOpen()判断连接状态，避免IllegalStateException: The session is closed - 不要在
@OnOpen里启动线程池轮询推送；改用SimpMessagingTemplate.convertAndSend()或直接调用session.sendMessage() - 若用
TextMessage发送 JSON，注意字符编码：必须用new TextMessage(jsonString.getBytes(StandardCharsets.UTF_8))，否则中文变乱码
前端弹幕飞过太快看不清？服务端别直接透传原始时间戳
很多实现让前端自己解析 timestamp 并计算入场位置和持续时间，结果不同设备渲染帧率不一致，弹幕速度忽快忽慢。真正可控的做法是：服务端统一做时间归一化，把“发送时刻”转成相对当前服务端时间的偏移毫秒值，并限制最小间隔。
- 发弹幕时，后端记录
System.currentTimeMillis()，减去客户端传来的clientTime得到网络延迟补偿值 - 实际推送给所有客户端的弹幕对象里，用
offsetMs字段代替绝对时间，前端只负责按这个 offset 做延时入场 - 对同一用户连续发送的弹幕，服务端应拦截
interval 的请求（单位毫秒），防止刷屏
大量并发连接下 CPU 占用飙升？慎用 synchronized 包裹广播逻辑
当在线人数超千级，用 synchronized (broadcastLock) { sessions.forEach(...); } 做群发，会形成强竞争点，导致线程阻塞、吞吐骤降。这不是锁粒度问题，而是设计层面没避开共享状态。
- 改用
CopyOnWriteArraySet<websocketsession></websocketsession>存储活跃会话，遍历时无需加锁 - 广播前先用
sessions.stream().filter(WebSocketSession::isOpen).toList()过滤，避免反复调用isOpen()触发底层心跳检测开销 - 如果用 Netty 实现自定义 WebSocket 服务，务必禁用
ChannelOption.AUTO_READ默认行为，改用手动channel.read()控制读取节奏
弹幕内容含 HTML 标签被 XSS 攻击？过滤不能只靠前端 textContent
有开发者觉得“前端用 textContent 渲染就安全”，但攻击者可在连接建立阶段发恶意 payload，比如通过 WebSocket 消息注入 <script>fetch('/admin/api')</script>，一旦后端没过滤就存库或透传，后续任何页面加载该历史弹幕都会触发。
立即学习“Java免费学习笔记（深入）”；
- 后端收到弹幕文本后，必须用白名单方式清洗：只保留字母、数字、常用标点、Emoji Unicode 范围（
\u1F600-\u1F64F等），其余一律替换为空格或删除 - 避免用正则删
<script></script>—— 绕过方式太多；推荐用Jsoup.clean(input, WHITELIST)，其中WHITELIST是自定义的空策略（即不放行任何标签） - Redis 缓存弹幕时，字段名别用
danmaku:{id}这种裸拼接，防止注入；统一走danmaku:content:{md5(content)}
弹幕系统真正的难点不在连接维持，而在于消息生命周期管理：从接收、校验、缓存、广播到前端渲染控制，每个环节的时间窗口和状态边界都得卡准。最容易被忽略的是客户端时钟偏差带来的 offset 漂移，以及高并发下 session 集合迭代时的弱一致性——这两处出问题，现象都是“偶尔丢几条弹幕”，查起来特别费时间。
