微信小程序中video组件弹幕需用cover-view实现，因原生video层级最高导致z-index失效，且videoContext.sendDanmu在小程序端静默失败；须平台判断、对象池复用、requestAnimationFrame驱动并监听服务端回推防重复。

微信小程序里用 video 组件加弹幕，最常遇到的问题不是“怎么发”，而是“发了看不见”——根本原因是原生 video 组件层级最高，z-index 失效，普通 view 根本盖不到它上面。

为什么 videoContext.sendDanmu 在微信小程序里无效

这个 API 看似官方支持，但仅在 H5 和 App 端生效；微信小程序中 videoContext.sendDanmu 调用后无报错、无渲染、无回调，属于「静默失败」。官方文档未明确标注平台限制，开发者容易踩坑。

• 微信小程序真机环境不支持 videoContext.sendDanmu 方法，模拟器可能误报成功
• uni-app 编译到 mp-weixin 时，该方法会被忽略，不会触发任何弹幕渲染逻辑
• 若项目同时兼容 H5/App/小程序，必须做平台判断：uni.getSystemInfoSync().platform === 'mp-weixin'

微信小程序必须用 cover-view + cover-image 叠加弹幕

因为 video 是原生组件，唯一能盖在其上的只有 cover-view 及其子组件。但 cover-view 有严格限制：不能写 scroll-view、不能嵌套普通 view、不支持 Flex 布局（部分基础属性可用），动画也受限。

微信公众号发文助手

微信公众号产业研究发文助手，支持原文读取、分层摘要、产业链标的梳理、image2 海报与封面生成、正文排版、微信草稿保存、回读校验和发布前确认。

下载

• 弹幕容器必须是 <cover-view class="barrage"></cover-view>，且需设固定宽高（如 width: 100%; height: 100%;）
• 每条弹幕用 <cover-view class="danmu-item"></cover-view>，不能用 div 或 view
• 颜色、字体大小等样式只能通过内联 :style 控制，class 中的 color 在某些基础库版本下会失效
• 避免在 cover-view 内使用 v-for 渲染大量弹幕，建议控制在 20 条以内并手动回收旧弹幕

如何让弹幕从右向左滚动且不卡顿

靠 CSS 动画（animation）实现滚动在 iOS 微信上容易掉帧，尤其当弹幕密度高时。更稳的方式是用 requestAnimationFrame 手动更新 transform: translateX()，配合对象池复用。

• 每条弹幕初始化时预设 speed（如 8 px/frame）和 position（起始 X 坐标 = 屏幕宽度）
• 用 requestAnimationFrame 每帧更新所有活跃弹幕的 position -= speed，当 position 时标记为可回收
• 提前创建 3–5 个弹幕对象池（danmuPool = [{id: 1, text: '', position: 0, color: ''}, ...]），避免频繁 new 和 GC
• 不要用 setTimeout 或 setInterval 驱动，iOS 下容易被节流或暂停

发送弹幕后如何实时同步到 UI 并防重复

弹幕本质是消息流，不是单次动作。直接调用发送接口后，必须确保 UI 渲染与消息接收逻辑解耦，否则会出现“自己发的看不到”或“同一条弹幕刷两遍”。

• 发送端调用 sendTextMessage 后，**不立即 push 到本地列表**，而是等待服务端广播回推（即监听 messageList 变更）
• 使用 watch(messageList, ...) 时，注意 deep 选项：默认浅监听，若后端返回的是新数组引用，必须加 { deep: true }
• 自己发送的弹幕，服务端应带 isSelf: true 字段，UI 可据此加特殊样式（如右对齐、金色边框）
• 防抖发送：连续快速点击发送按钮时，用 clearTimeout + setTimeout 限制最小间隔（如 500ms）

真正难的不是让字动起来，而是让字在不同平台、不同机型、不同微信版本下都稳定出现在视频上——cover-view 的渲染边界、iOS 的 transform Z 轴偏移、安卓低端机的 RAF 掉帧，这些细节一旦漏掉，弹幕就只活在 console 里。