前言

最近在继续做 @dan-uni/dan-any 的弹幕解析支持，发现网上没什么人对爱奇艺的弹幕格式有详细研究，故将研究过程公开，方便后人查阅资料。

关于爱奇艺的弹幕获取可以自行网络搜索，这个的文章还是挺多的。

正文

大量网络资料调研

请参考对话记录

统计学研究

基于该仓库提供的大量弹幕数据

得到以下总结文档：

统计范围：jxnd_XML/*/*.xml

• XML 文件数：411
• 解析错误：0
• bulletInfo 总数：139,463
• 分集数：43
• 单集弹幕数范围：1,537 - 7,548
• showTime 范围：1 - 2,735 秒，符合约 43-46 分钟剧集长度
• contentId 唯一率：100%，前 13 位可解释为毫秒时间戳，范围约为 2021-02-01 到 2021-06-16

字段出现情况

每条均出现的字段：

contentId, content, parentId, showTime, font, color, opacity, position, background, isReply, likeCount, plusCount, dissCount, isShowLike, userInfo, contentType, subType, src, spoiler, halfScreenShow, scoreLevel

几乎每条均出现：

• emotionType：139,453 / 139,463，缺失 10 条

稀有额外字段：

• minVersion：1,018 条，含 iPhone/iPad/GPhone/GPad，值均为 9.6.0
• songId：43 条
• mentionedTitle / mentionedTvid：6 条

未在样本中出现的接口字段：

• variableEffectId
• isShowLikeTest
• isShowReplyFlag
• replyCnt
• imageEmotionType

主要字段统计与推断

嵌套 userInfo

额外字段

修正建议

原接口注释里有几处可以按数据修正：

• parentId 不是恒为 0；约 0.71% 是回复，值指向父弹幕 contentId。
• position 不只有 0/1/2；本数据出现 0/1/2/3/4/100/200。100/200 比 1/2 更常见，且与特殊展示相关。
• opacity 虽为 0-10，但与 font 强相关，不宜直接写死为“百分比透明度”。
• contentType 不只有 0；出现 100、200。
• subType 不只有 0；20 明确对应提及剧集，25 明确对应音乐/BGM。
• src 不只有 0；出现 7、10。
• spoiler 在本数据中全为 false，只能说明当前样本无剧透弹幕，不能证明字段恒 false。
• imageEmotionType、variableEffectId、replyCnt 等在当前 XML 样本中未出现，建议接口类型中标为可选字段。

font / opacity / position / scoreLevel 细分解析

说明：未找到可验证的爱奇艺公开字段枚举文档，因此下面把“数据事实”和“含义判断”分开。能由字段共现稳定确认的标为高置信；样本过少或只可推断的标为低置信。

font

font 在本数据中不是单纯字号。它与 opacity、color 大小写体系、position 强绑定，更像“客户端弹幕样式/字号档位编码”。

结论：如果要建类型，建议不要把 font 注释成字号。更合适的是：

opacity

opacity 取值为 0-10，但它不适合直接理解为百分比透明度。原因是它与 font 高度绑定：font=14 永远是 5，font=20 几乎永远是 1，font=0 永远是 0。

结论：可以说它是“透明度等级/样式透明度档位”，但不能写成 0-10 对应 0%-100%，当前数据不支持这个线性解释。

position

position 是位置或展示类型编码。它确实包含常见弹幕协议里的 0/1/2，但爱奇艺样本中还出现 3/4/100/200。

关键判断：

• position=0 可确认是默认普通弹幕。
• position=100/200 与 contentType=100/200、halfScreenShow=0 强绑定，更像爱奇艺客户端特殊展示类型，不应映射为“顶部/底部”。
• position=1/2/3/4 样本只有 13 条，且都绑定 font=30。虽然常见弹幕协议里 1=顶部、2=底部，但当前爱奇艺数据不足以实证确认。

建议类型注释：

scoreLevel

scoreLevel 只出现 1/2/3。它不像样式字段，因为各类 font/position/color 中都分布。它和点赞数有明显关系：scoreLevel=1 的点赞中位数显著高于 2/3。

注意：这里的数字方向和直觉可能相反。按样本统计，scoreLevel=1 更常见于高赞弹幕，scoreLevel=3 更常见于普通低赞弹幕。因此如果把它理解成“评分等级”，更像是：

• 1：高权重/优先展示/精选倾向
• 2：中间等级
• 3：普通默认等级

但它也可能是服务端排序或审核打分等级，不一定直接展示给用户。建议注释为：

PC Web 播放器逆向

渲染管线 基于 2026-06-29 抓取的页面和静态资源，页面版本是 17.063.25642，核心入口为：

• 页面：用户给的 https://www.iqiyi.com/v_19rrntxeew.html?...
• 播放器：https://static.iqiyi.com/js/player_v3/pcweb.wonder.17.063.online.js
• 主要 chunk：
• https://www.iqiyi.com/static/js/common-pcwPlayer_d91a9049.39e537cd.js
• https://www.iqiyi.com/static/js/common-pcwPlayer_7bd12dde.7156f81c.js
• https://www.iqiyi.com/static/js/common-pcwPlayer_9f650d08.98931572.js

管线大致是：

1. HTML 加载 pcweb.wonder 和 pcwPlayer 相关 chunk。
2. React 播放器渲染视频层，同时创建弹幕容器 #pcaBarrageContainer。
3. Barrage XPlayer 构建 barrageBridge，把 tvid / vid / cid / aid / duration / paused / currentTime / videoAreaWidth / videoAreaHeight 传给弹幕层。
4. Barrage Player 根据 bridge 参数实例化真实弹幕 SDK：new BarrageClass(params)。
5. 播放器生命周期通过 bridge 驱动 SDK：play / pause / timeUpdate / switch / switchQuality / show / hide / clear / close。
6. JSBarrageAdapter 负责把 SDK 的设置、屏蔽词、发送结果、模式切换接到播放器 UI。
7. 实际“弹幕列表请求、单条字段解析、轨道布局、DOM/canvas 绘制”在被 import 为 56418 的 SDK 模块里；当前抓到的页面公开 chunk 里只看到引用，没定位到该模块定义，所以单条 font/position/scoreLevel 的官方枚举还不能 100% 反编译确认。

关键反推 网页 UI 的“字号设置”不是 XML 里的 font。播放器设置面板中有独立的 fontSize 档位：

这说明 XML 的 font=14/20/30/0/1/2/3/4/99999/10000x 不是简单字号，而是弹幕内容自身的样式编码。网页全局设置只是在 SDK 层整体缩放/覆盖显示字号。

字段结论 font：样式/字号档位编码，不建议注释为纯字号。统计中常见值为 14,20,2,0,30,1,3,4，另有少量 99999/10000x 特殊样式。14、20、2、0 分别和固定 opacity 强绑定，说明它们是不同客户端或不同样式体系的编码。

opacity：取值 0-10，但不是可直接线性换算的百分比。比如 font=14 永远配 opacity=5，font=20 几乎永远配 1，font=0 永远配 0。更准确是“透明度/样式透明度档位”。

position：0 高置信是普通滚动弹幕。100/200 和 contentType=100/200、halfScreenShow=0 强绑定，更像爱奇艺特殊展示弹幕，不应映射成顶部/底部。1/2/3/4 样本极少，且全配 font=30，只能判断为固定/特殊轨道，无法可靠确认每个值的真实 UI 位置。

scoreLevel：不是样式字段，更像服务端权重/质量/排序等级。样本中方向是反直觉的：scoreLevel=1 的点赞和展示倾向最高，3 最普通。所以建议理解为 1=高权重/精选倾向，2=中间，3=普通默认。

建议把接口注释改成：

可以。逆向到当前爱奇艺 PC 网页播放器后，font 和 position 的结论比单纯统计 XML 更明确：

结论 font 在当前 PC 网页播放器里基本不是“单条弹幕实际字号”。播放器会把拉取到的弹幕统一覆盖成全局字号设置。

实际渲染管线里，弹幕进入轨道前会被设置为：

然后 DOM 样式使用：

也就是说，XML 里的：

更像是服务端/历史客户端/样式来源字段，而不是当前 PC 网页逐条弹幕的最终字号。

当前 PC 网页端可确认的实际字号来源是播放器设置：

默认长视频字号约为 24px，迷你/悬浮场景可见默认 14px。所以更准确地说：

所以如果你的目标是“复刻当前网页版播放器显示”，不要按 bulletInfo.font 逐条设字号，而应使用播放器全局字号档位。

position 的精确对应 这里可以确认得更准。当前 PC bundle 里定义了弹幕类型枚举：

你的 XML 里 position=100/200 基本也同时出现 contentType=100/200，这和播放器枚举完全吻合。因此可以把它们解释为：

但要注意一个关键点：当前 PC 网页渲染主要按 contentType 选择弹幕类型，position 更像随数据一起保留的并行字段。XML 里二者一致时可以放心使用；如果冲突，复刻 PC 网页时应优先信 contentType。

至于你数据里的：

当前 PC 网页播放器没有找到这些数字的现代枚举定义。结合统计，它们数量极少、全部集中在 font=30、contentType=0，更像旧客户端遗留的位置/模板编号。按当前 PC 网页逻辑，它们大概率不会被当作顶部/底部枚举处理，而是落回普通弹幕路径。

参考逆向来源：

• https://www.iqiyi.com/static/js/iqiyi-pcw-ui.aee16f12.js
• https://www.iqiyi.com/static/js/common-pcwPlayer_7bd12dde.7156f81c.js
• https://www.iqiyi.com/static/js/common-pcwPlayer_d91a9049.39e537cd.js

最终建议的接口解释可以改成：