M3U8分片下载与油猴脚本实战：HLS抓取、合并与排错

前段时间帮一个做在线课程运维的朋友处理了个挺典型的问题:他自己录的直播回放挂在自家页面上,学员抱怨想下载到本地反复看,右键另存为存不下来,他自己也试了半天,另存出来的只有一个几 KB 的小文件。打开一看,里面全是文本,列着一堆.ts结尾的地址——这就是 M3U8 播放列表。类似场景其实很多:自己录的直播、单位内部培训视频、公开课回放、需要离线复习的讲座。这些内容被切成几百上千个小分片,浏览器一段一段地请求播放,你压根找不到一个完整视频文件可存。这时候大家通常会搜到油猴脚本 M3U8 下载助手这套组合——用户脚本管理器装一个脚本,页面上直接多出一个下载按钮或者一层面板,把分片挨个拉下来再拼回去。这篇就从原理到实操把这条链路讲透:分片是什么、脚本在中间到底干了哪几件事、参数怎么调、下载完之后一堆几百 KB 的碎片怎么合并成一个能正常拖进度的视频,以及我这两年踩过的坑。适合完全没接触过流媒体的新手动第一遍,也适合已经能下但总在合并、音画同步、断点续传上翻车的人对照排查。1. M3U8 与油猴脚本:把问题拆开看1.1 M3U8 是一份清单,不是视频文件先把最容易混淆的概念掰正。M3U8 本质上就是一个 UTF-8 编码的纯文本文件,后缀虽然带个 8,但它跟视频编码、清晰度没有任何直接关系。它是一份播放索引,告诉播放器:这个片子被切成了几段、每一段叫什么名字、每段多长、按什么顺序播。你随便找个文本编辑器打开就能看见内容,典型长这样:#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:6 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:6.000, seg-00001.ts #EXTINF:6.000, seg-00002.ts #EXTINF:6.000, seg-00003.ts #EXT-X-ENDLIST看懂这几行就够用了。#EXTM3U是文件头标识,少了这行很多解析器直接判废;#EXT-X-TARGETDURATION声明目标分片时长,一般是 4 到 10 秒;每条#EXTINF描述紧随其后那个分片的实际时长;#EXT-X-ENDLIST表示到这儿就完了,是点播内容的标志——如果结尾没有这行,说明这是直播列表,内容还会继续追加,那种情况脚本的处理逻辑完全不一样。分片文件本身通常是 MPEG-TS 封装,一小段一小段独立可解码,这也是为什么你能随便丢一段进播放器都能放出几秒钟画面。搞明白清单 分片这个结构,后面所有操作都顺了:下载助手干的事,无非是把清单拉下来、按顺序把分片全下下来、再拼成一个整体。1.2 为什么要切片:HLS 的设计取舍不少人第一反应是好好的视频为什么要切碎,不是自找麻烦吗。这个设计其实是流媒体分发的必然结果,主要解决四件事。第一是启动速度。一个两小时的视频如果做成单文件,播放器得先下载到足够多的数据才能起播,或者依赖服务端做范围请求。切成 6 秒一段之后,播放器只要拿到前两三段(大约十几秒数据)就能立刻开播,后面的边播边下。用户在弱网环境下也能秒开,体验差距非常明显。第二是码率自适应。真正完整的流媒体结构是两级:顶层那份 M3U8 是主列表,里面用#EXT-X-STREAM-INF列出好几档清晰度,每一档再指向自己那份媒体列表。播放器根据当前带宽和缓冲情况,可以在不同档位之间动态切换——网速掉了就切低码率分片,网速恢复了再切回来。这种无缝降级能力是单文件模式做不到的。第三是缓存与分发。分片是天然的可缓存单元。多数用户看同一个片子都会经过开头那几段,缓存命中率极高,回源压力小。反过来,如果是一个巨大的单文件,每次范围请求都可能穿透到源站。代价当然也有:一次播放变成几十上百次 HTTP 请求,连接开销、请求头开销都上来了;对下载一方来说,你必须处理几百个文件这种局面,以及顺序、完整性、失败重试这些麻烦事。油猴脚本存在的意义,基本上就是把这份麻烦封装掉。注意:主列表和媒体列表长得像但不是一回事。主列表里通常没有#EXTINF,只有一串带清晰度标注的地址;媒体列表里才有#EXTINF和具体的.ts。抓错层级是新手最常见的坑,表现为下了半天只有一个几十行的文本文件。1.3 明明在播,为什么右键另存不下来这个问题问的人最多。你在页面上右键,发现根本没有视频另存为,或者存下来是个几 KB 的怪文件,原因有两层。浅层原因是页面用了blob:开头的地址。现代播放器基本都走 MSE(Media Source Extensions)这条路:浏览器把video的src设成一个 Blob URL,真正的数据由 JavaScript 通过SourceBuffer一段段喂进去。这个 Blob URL 只在当前页面会话里有效,你把地址复制到新标签页打开,大概率是空白。所以你在元素面板里翻到的src并不是真实地址,它只是个指向内存缓冲区的句柄。深层原因是,分片请求是播放器内部发起的,时机、顺序、重试都由播放逻辑控制。你没法暂停一下让我把所有分片存下来,因为一旦暂停,某些已缓冲的分片可能已经被回收,而后续分片根本没请求过。想让浏览器老老实实把几百个分片全部走一遍,要么让它完整播放一遍(还得盯着别漏),要么就在网络层动手——这正是脚本最擅长的地方。1.4 油猴脚本补上的那一环油猴脚本这套东西,正式叫法是用户脚本,运行在浏览器扩展或者浏览器内置的脚本支持机制提供的沙箱里。它有两个关键能力决定了它适合干这活:能在目标页面上注入自己的代码,以及能在页面发起网络请求的那一刻插一脚。注入能力让脚本能在播放器旁边挂一个悬浮按钮、一层列表面板,让你看得见它在干什么。网络劫持能力让它能读到页面内部发出去的那些.m3u8和.ts请求——播放器自己发出了这些请求,脚本只是顺手抄了一份地址记下来,不需要去猜、去逆向播放器逻辑。这两点合起来,就构成了下载助手的核心:监听页面请求,把出现的 M3U8 地址和分片地址记进内存;把地址展示给你,或者自动解析主列表拿到媒体列表;按你设定的并发数批量下载分片到本地(或者压成一个包);按索引顺序拼接,必要时去掉加密、转封装成 MP4。这四步每一步都有坑,后面逐个拆。先把环境准备好。2. 动手前的准备:环境与合规边界2.1 脚本管理器的两种形态与选型目前装用户脚本有两条路。一条是装一个专门的脚本管理器扩展,它提供一个可视化管理界面,能装、能停用、能配菜单、能看日志,对新手最友好;另一条是部分浏览器内置了脚本支持,不需要额外装东西,但功能相对克制,调试信息也没那么全。两种形态的取舍我一般这么看:对比项扩展形态的管理器浏览器内置脚本支持安装门槛需要装一次扩展零安装,直接开脚本管理界面有完整列表、开关、编辑简化,通常只有开关调试信息控制台日志、错误定位齐全日志较简略跨浏览器一致性各主流浏览器都有对应版本只在特定浏览器可用自动更新脚本支持一般不自动新手建议直接用扩展形态,理由很实际:第一次跑脚本你大概率会失败,而失败的时候你需要看控制台报错、需要临时改脚本里的一行打印、需要把自己写的调试代码塞进去。这些在完整的管理器里都是点两下的事,内置脚本支持往往做不到。等流程跑顺了,再考虑换成轻量方案。有一点务必注意:装了脚本管理器之后,页面上任何脚本都会以页面身份运行,它能看到你在那个站点上的登录态。所以别见脚本就装,装之前至少扫一眼代码,看看有没有把 cookie、localStorage 内容往外发的行为。这一条比什么参数调优都重要。2.2 辅助工具:合并、检查和兜底脚本通常只负责把分片拉到本地,合并这一步它不一定能做得优雅——尤其是几百个分片要拼成一个文件的时候。所以本地最好备一套工具。命令行多媒体工具是必须的。社区里用得最多的是 ffmpeg,它既能做 TS 的无损拼接(直接用 concat 协议),也能把 TS 转封装成 MP4、还能顺带修时间戳。这玩意儿是全命令行,但常用的就那么几条,后面我会把完整命令贴出来,你能直接抄。一个趁手的文本编辑器。用来打开 M3U8 看结构、核对分片数量、临时改个前缀。别用系统自带的记事本,它保存时可能加 BOM 头,反而把文件搞坏。浏览器开发者工具。这个是定位地址的核心武器,不用它你根本不知道页面在请求什么。重点是网络面板的筛选和保留日志功能。至少两个播放器。一个用来验证合并后的文件能不能正常播、能不能拖进度条,另一个当备用——某些封装的 TS 在一个播放器里放不出来,换一个可能就好了,这有助于你判断到底是文件坏了还是播放器挑剔。2.3 能用和不能用的边界,先划清楚这条得放前面说清楚,省得白忙活。可以处理的:你自己录制或拥有版权的音视频、明确提供下载权限的公开课和讲座、单位内部授权你离线保存的培训材料、公开测试用的示例流、以及你自己搭建测试环境生成的 HLS 内容。这些场景下,把分片下载下来本地保存,和把文件复制到自己的硬盘性质上没差别。不要碰的:需要付费或登录才能观看、但条款明确禁止下载的内容;带有版权保护机制的流媒体;以及任何你在法律上或合同上无权复制的东西。技术上能做到和可以这么做是两回事,这个区分从业者心里得有一条线。还有一个常见误区:有人觉得加密的分片也能解,所以我就解。这里要说清楚,HLS 标准里有一种 AES-128 的分片加密,密钥地址就明明白白写在同一份播放列表里,这是协议自带的能力,内容提供方用它主要是防止分片被随意盗链,不是作为访问控制手段。我在本文只讨论这种密钥在列表里公开声明的标准情形,用来处理自己有权访问的内容;涉及访问控制和版权保护机制的,一律不讨论也不建议尝试。3. 脚本的核心工作原理拆解3.1 地址是怎么被抄出来的三种常见做法,脚本作者一般至少用其中一种,靠谱的会用两种做兜底。第一种,钩住页面的网络请求。脚本在页面加载前就把XMLHttpRequest和fetch包一层,原样转发调用,但在响应回来的地方顺手检查一下:这个 URL 是不是.m3u8结尾、响应体是不是以#EXTM3U开头。命中了就把地址记进一个集合里。这种做法优点是很准,只要播放器是通过这两个 API 请求的(现代播放器几乎全是),就一定能抓到。缺点是必须在播放器发请求之前完成钩子安装,所以脚本的注入时机很重要,一般要求document-start。第二种,监听 video 元素的事件。页面里一旦出现video或者audio标签,脚本挂上loadedmetadata、play、timeupdate这类事件,在事件回调里检查当前src和页面上的其他线索。这招对 blob URL 无效,但有时候能从播放器实例上摸到它内部的配置对象,里面有原始地址。第三种,正则扫页面源码和内存。把页面 HTML 和已经加载的脚本内容过一遍,找https?://...\.m3u8[^]*这种模式。兜底用的,命中率不高但偶尔能捡漏——尤其是那些把地址写在初始化 JSON 里、却因为某种原因没真正发请求的情况。从实操角度看,你不需要自己实现这些,但必须知道脚本是靠哪种方式工作的,因为它直接决定抓不到地址时该怎么排查。比如脚本用的是钩子法而你装得太晚(页面早加载完了),那就是抓不到;这种时候刷新一次页面让脚本先跑起来就行,这个技巧能解决大概六成的脚本没反应。3.2 两级列表:主列表往下挖一层抓到地址之后,第一件事是判断你手上这份是主列表还是媒体列表——判断方法很简单:打开看看有没有#EXTINF。有就是媒体列表,直接可以下分片;没有,那就是主列表,得先解析出各档清晰度对应的子列表地址。主列表的结构大概这样:#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH1280000,RESOLUTION1280x720 hd/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH640000,RESOLUTION854x480 sd/index.m3u8BANDWIDTH是带宽估算值(单位 bit/s),RESOLUTION是分辨率。脚本一般会让你选一档,或者默认选码率最高的。这里有个容易被忽略的细节:相对路径要基于当前列表的 URL 来解析。上面那个hd/index.m3u8是相对地址,实际请求得拼成https://example.com/path/hd/index.m3u8。脚本如果拼接逻辑写得不严谨,就会 404,表现是能选清晰度但一下载就全部失败。还有一个变体叫多码率变体流(master media 各一份),以及带#EXT-X-MEDIA的音轨分离结构——音频是单独一份列表。这种结构下如果脚本只下视频不下音频,合并出来的文件就是无声的。判断方法:主列表里出现#EXT-X-MEDIA:TYPEAUDIO这样的行,就说明音轨是独立的,得把那条URI也一起下下来。3.3 并发下载与顺序落盘分片下载是典型的IO 密集 数量多任务,串行下载一个两小时的片子可能要十几分钟甚至更久,并发是必须的。但并发带来一个新问题:回来的顺序和发出的顺序不一致,而拼接必须严格按索引顺序。成熟脚本的做法是并发下载、按索引落位。给每个分片分配一个从 0 开始、补零到固定位数的编号,比如00001.ts、00002.ts,下载完成一个就按它的索引写盘,不管它第几个回来。补零这一步很关键,因为大多数文件管理器排序是按字符串而非数值,10.ts会排在2.ts前面,补零之后00010.ts就老老实实排在00002.ts后面,后续批量处理时不会乱序。并发数怎么定,后面第 6 节会细讲,这里先给个结论:8 到 16 是绝大多数场景的甜点区。低于 8 太慢,高于 24 时收益急剧下降,而且很容易触发服务端的频率限制,表现是一批分片返回 429 或者 403,反而更慢。还有一个容易忽略的点是超时。分片本身只有几百 KB,正常网络下几百毫秒就下完了,设个 10 到 15 秒的超时足够;但如果某个 CDN 节点抽风,单个请求挂住不返回,整个任务就会卡在还剩 3 个这个状态上一直转圈。好的脚本会有超时中断和重试队列,没有的话你得手动盯着。3.4 解密、合并与转封装分片全下完之后,到本地还有三步要走,顺序不能乱。第一步,解密(如果列表里有#EXT-X-KEY)。标准结构是这样的:#EXT-X-KEY:METHODAES-128,URIkey.bin,IV0x1a2b3c...脚本会先去请求key.bin拿到 16 字节密钥,然后用 AES-128-CBC 逐片解密。如果列表里没写 IV,那么 IV 默认等于该分片的媒体序列号(按大端序补到 16 字节)。很多解密失败的情况,根源就在这个默认 IV 的处理上——某些工具默认用了全零 IV,结果解出来的第一段是花的,后面倒是正常。这是判断是 IV 问题还是密钥问题的一个小窍门:如果只有开头一段花屏、后面都好的,基本就是 IV 用错了。第二步,按顺序拼接。MPEG-TS 有个很好的特性:它是定长包结构(每包 188 字节),单纯的字节级拼接就能得到一个合法文件。这也是为什么用cat a.ts b.ts out.ts在某些情况下也能work——当然前提是所有分片编码参数一致。不过我不建议用cat,原因有两个:一是没法处理中间缺片的情况,二是不同分片的时间戳(PTS/DTS)可能不连续,直接拼出来的文件在某些播放器里会卡顿或者拖不动进度条。第三步,转封装。用命令行工具做 concat 的时候,工具会重新读取每段的时间戳并重建索引,顺便可以把 TS 转成 MP4。TS 转 MP4 通常不需要重编码,只是换个容器,几秒钟就能搞定,而且换来的是更好的兼容性(某些手机、某些播放器对 TS 支持不佳)。4. 实操:从零跑通一次完整下载4.1 第一步,手动定位真实的 M3U8 地址这一步先别依赖脚本,自己手动抓一次。搞懂这一步之后,脚本失效你也有兜底方案。打开目标页面,按下 F12 打开开发者工具,切到网络面板。这里有两个必须操作的开关:勾选保留日志,不然页面一跳转请求记录就清空了;然后在筛选框里输入m3u8,把其他请求过滤掉。接着刷新页面,点播放,等几秒钟。正常情况下你会看到一两条命中的请求。注意区分:如果命中的是那种只有十几行、包含#EXT-X-STREAM-INF的,那是主列表;如果里面有大量#EXTINF,那是媒体列表。两种都记下来,点开响应标签页可以直接看内容,右键复制链接地址拿到完整 URL。如果一条都没有,按顺序排查:筛选框是不是输错了(有的大小写敏感);是不是请求发生在你打开面板之前(那就勾保留日志后刷新);是不是用了别的扩展在拦截(临时停用其他扩展试一次)。还有一种情况是地址不带.m3u8后缀,比如.../playlist?typehdtokenxxx,那就改成按media或者按响应类型 MIME 过滤,类型一般是application/vnd.apple.mpegurl或application/x-mpegURL。拿到地址之后,直接在浏览器新标签页里打开它。能正常显示文本内容就说明地址可用、没绑死会话;如果提示 403,那可能是带了防盗链校验,需要在请求头里补 Referer,这个放到后面排查章节讲。4.2 第二步,安装并配置脚本装好脚本管理器之后,把 M3U8 下载助手的脚本装进去,然后回到目标页面刷新。正常情况下页面角落会多出一个悬浮图标或者面板,显示检测到 1 个媒体地址之类的提示。配置项看着多,真正影响结果的其实就几个:参数作用推荐值调整逻辑并发数同时下载的分片数8~16报 429/403 就降到 4~6单请求超时单个分片的等待上限10~15 秒跨境访问或弱网可提到 20 秒重试次数单片失败后的重试2~3 次重试仍失败说明是源问题,别硬加分片命名落盘文件名的编号格式补零 5 位分片超过 99999 时才需要 6 位自动合并下完是否自动拼成一个文件建议关先用原片验证,确认完整再合保存目录落盘位置单独建个空目录别和已有文件混放,便于整体处理自动合并这个开关我建议先关掉。理由很实际:一旦合并完,你很难判断中间是不是漏了片、是不是有某几段解出来是坏的。先让原始分片老老实实躺在目录里,总数能对得上、抽几段能正常播、再合并,出问题时有得查。等流程熟了再打开这个开关。另外有个细节值得留意:面板上显示的分片总数一定要和播放列表里的#EXTINF行数对上。对不上就说明列表没解析完整,可能是被截断了(直播流常见),也可能是主列表和媒体列表混了。这个数字是后面所有校验的基准,记下来。4.3 第三步,下载与合并的完整命令分片下载到本地之后,目录结构大概是这样(我自己习惯让脚本按 5 位补零):download/ seg-00001.ts seg-00002.ts ... seg-00412.ts key.bin index.m3u8先做个完整性检查。数一下文件个数,和列表里的分片数对照;再抽头尾各一段用播放器打开,能正常出画面和声音就说明没有系统性错误。如果脚本顺手把index.m3u8也存下来了,那最好——直接用它做合并的输入,比手搓文件列表可靠得多。合并命令,用列表文件驱动的方式最稳:ffmpeg -allowed_extensions ALL -i index.m3u8 -c copy -bsf:a aac_adtstoasc output.mp4逐段解释一下这几个参数到底在干什么,别当黑盒抄:-allowed_extensions ALL是放开扩展名白名单,因为默认只允许.m3u8/.ts这类,本地相对路径引用时需要它;-i index.m3u8把播放列表当输入,工具会自己去解析#EXTINF顺序、#EXT-X-KEY密钥、以及分片地址;-c copy是关键,表示不做重编码,直接流复制,速度极快而且画质零损失;-bsf:a aac_adtstoasc处理的是 ADTS 到 ASC 的音频头转换,TS 里的 AAC 是带 ADTS 头的,装进 MP4 容器之前得去掉,不加这个参数大概率会出现合并成功但没声音或者音频报错。如果手头没有index.m3u8,只有一堆.ts,那就走拼接清单的方式:for f in seg-*.ts; do echo file $PWD/$f; done list.txt ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4第二条命令里的-safe 0是必须的,因为默认的安全模式会拒绝绝对路径,而上面的循环生成的是绝对路径,不加这个参数直接报unsafe file name。如果合并报错,先别急着怀疑分片坏了,按这个顺序看:报错信息里提到的那个文件名,单独用播放器打开能不能播?能播说明是时间戳问题,加-fflags genpts重新生成时间戳再试;不能播说明这个分片本身是坏的(下载中断或者解密失败),那就重新下这一段。4.4 关键参数的推算过程并发数和超时这两个参数,与其给个拍脑袋的数字,不如说清楚怎么推。并发数的瓶颈通常不在你的带宽。一个 720p 的分片大约 400 到 800 KB,6 秒时长,折算码率在 1 Mbps 上下。16 并发满载时理论带宽需求约 16 Mbps,现在家宽基本都能满足。真正的瓶颈是两处:一是浏览器对同一域名的并发连接数限制(HTTP/1.1 下通常是 6,HTTP/2 下多路复用可以更高);二是服务端的限流策略。所以经验值是:站点走 HTTP/2 就开到 12 到 16,走 HTTP/1.1 就压到 6 到 8,超过连接数限制的部分只会在队列里排队,不会真的更快,反而增加超时风险。超时按单个分片大小 ÷ 你的实际下载速度 × 安全系数来估。假设分片 600 KB,你的下行实测 5 MB/s,那理论耗时 0.12 秒,给 10 秒超时相当于 80 倍冗余,足够应对抖动。但如果链路上有绕行节点,单请求可能到 2 到 3 秒,这时 10 秒仍有 3 倍冗余,还算合理;再往上加就没意义了,因为真卡住 20 秒的请求,基本也不会在第 21 秒突然成功。重试次数别超过 3。原因很朴素:如果一个分片连续三次都失败,那基本是源端问题(文件缺失、鉴权过期、CDN 节点异常),再重试只是浪费时间。这时候正确的动作是停下来看一眼失败的具体状态码,而不是把重试调到 10 次。5. 常见问题与排查实录5.1 面板有反应但抓不到地址这是最高频的问题,分几种情形。情形一,脚本装晚了。页面已经完整加载、播放器已经初始化完毕,脚本才注入,钩子根本没挂上。解决办法是刷新页面。判断依据是:控制台里脚本的初始化日志出现在播放器初始化日志之后。情形二,播放器用的是 Web Worker 发请求。少数播放器把网络请求放在 Worker 线程里,主线程的钩子拦不到。这种比较难搞,退路是回到 4.1 节的手动抓包,从网络面板直接拿地址,绕过脚本。情形三,请求被 Service Worker 接管。有些站点注册了 Service Worker 做离线缓存,请求根本不经过页面的 XHR/fetch 路径。开发者工具的网络面板里会看到请求的来源标着 Service Worker,这种情况钩子法基本失效,同样退回手动抓包。情形四,地址在 iframe 里。播放器嵌在跨域 iframe 中,脚本的注入范围没覆盖到。脚本管理器一般有在 iframe 中运行的开关,打开再试。5.2 下了一堆小文件但合并不了最常见的三种报错和对应处理。报错提到某个文件名unsafe:就是缺-safe 0,补上即可。或者把路径改成相对路径,把$PWD/去掉。报错说找不到解码器或者格式不支持:八成是某个分片下载不完整。TS 分片如果被截断,包结构就断了,后面所有包都会错位,工具会直接放弃。定位方法是看每个文件大小,正常分片大小应该在一个区间内浮动,明显偏小的就是坏片,单独重下。合并成功但播放时长不对:比如实际两小时,播放器显示 12 分钟。这是时间戳不连续导致的,加-fflags genpts让工具重新生成,或者干脆先转成 TS 再转 MP4 分两步走。还有一种隐蔽情况是分片里混入了不是视频的内容,比如某个请求被重定向到了一个错误页(HTML),文件后缀是.ts但内容是 HTML。这种情况用文本编辑器打开那个文件一眼就能看出来,开头是!DOCTYPE html之类的。CDN 鉴权过期时特别容易出现,表现是前面几百个分片都正常,最后几十个全是这种——因为下载过程中 token 到期了。5.3 音画不同步与无声的成因这两个现象经常被混为一谈,但成因完全不同,得分开放。完全无声,通常是三个原因之一:一是音轨分离的情况(3.2 节提过),脚本只下了视频没下音频;二是合并时漏了-bsf:a aac_adtstoasc;三是解密时只解了视频分片,音频分片还在加密状态——这种情况下播放器可能直接跳过音轨,表现也是无声。开头同步、越到后面越偏,这是时间戳漂移。HLS 分片的时间戳本该连续,但有些转码器在切片时会有几十毫秒的累积误差,拼几百片之后累计到一两秒就明显了。处理办法是合并之后重新封装一次,让工具重建时间轴,-c copy加-fflags genpts -avoid_negative_ts make_zero一般能压下去大部分漂移。如果偏差特别夸张(比如几秒钟),那就得考虑是不是某些分片重复下载了或者顺序错了——检查一下文件编号有没有跳号、有没有重复。5.4 常见问题速查表现象最可能原因快速验证处理脚本面板一片空白注入时机太晚看控制台初始化日志顺序刷新页面重试只抓到主列表,选完清晰度就失败相对路径拼接错误手动打开拼接后的子列表 URL手动抓子列表地址填入下载到一半批量失败鉴权 token 过期看失败请求的状态码是不是 401/403重新抓地址,降低并发403 但地址在浏览器里能打开缺 Referer 校验用无痕窗口直接访问该地址补请求头或从页面内触发下载合并后没声音漏了音频流或音频滤镜用工具查看流信息补音轨、加-bsf:a合并后拖不动进度条时间戳不连续看文件时长与预期是否一致加-fflags genpts重封装某一段花屏、其余正常IV 处理错误只有开头花就是 IV 问题用序列号作为默认 IV 重解文件总数比列表少几片静默失败没重试比对编号找缺号单独补下缺失分片提示:排查时养成一个习惯——先把失败的那个分片地址单独在浏览器里打开。能打开说明是脚本或请求头的问题,打不开说明是地址本身失效了。这一步能省掉一大半猜测。6. 我踩过的坑与参数调优经验6.1 并发不是越高越好,我试过 48有次图快,把并发直接拉到 48,想看看极限在哪。结果前 30 秒确实飞快,然后就开始批量超时,几千个分片里有 200 多个失败,重试之后又失败,最后总耗时比 12 并发还长了将近一倍。事后复盘,原因很清楚:目标站点做了单 IP 的瞬时请求频率限制,超过阈值之后会延迟响应而不是直接拒绝,于是请求全部堆在等待队列里,超时时间一到全部判失败。后来我的做法是分档试探:先 8 并发跑 30 秒,看失败率;失败率为零就提到 12,再跑一段;一旦出现零星失败就退回上一档。这个渐进加压的土办法比任何固定参数都可靠,因为不同站点的限流策略差太多了。一般不超过 16,偶尔遇到宽松的 CDN 能到 24,但收益已经很不明显了。还有一个反直觉的发现:并发提高对总耗时的改善是边际递减的。从 4 提到 8,耗时差不多减半;从 8 提到 16,只减了不到三成;从 16 到 32,基本没变化。原因是瓶颈已经从请求排队转移到了磁盘写入和浏览器调度,再多的并发只是在抢同一份资源。6.2 断点续传:让失败不用从头再来几百个分片的任务,中途断一次从头再来是真的痛苦。我现在的做法是强制要求落盘即命名,也就是每个分片下载完成立刻按最终编号写盘,而不是先放内存、最后统一写。这样中断之后,只要重新跑一次、跳过已存在的编号即可。具体怎么操作,取决于脚本是否支持。支持的话直接在设置里勾跳过已存在文件;不支持,就在启动前先把目录里的文件列一遍,人眼扫一下最大编号,再手动从那个位置续。麻烦是麻烦点,但比重新下一小时强。另外一个实用技巧是分批下载。几千个分片的任务,我会先下前 50 个,合并验证一下能不能正常播、声音对不对、时长对不对,确认没问题再放开全量。这样即使参数配错了(比如分辨率选错、音频没下),损失也只有几分钟。这个习惯是从一次下完两小时才发现选成了 360p的教训里养成的。6.3 脚本冲突和调试的基本功装了三五个脚本之后,莫名其妙地有的失效,这种问题很常见,原因通常是两个脚本都在钩同一个 API,后装的把先装的覆盖了,或者互相改了同一个全局变量。排查方法很土但有效:停用除目标脚本之外的所有脚本,刷新,看是否恢复。恢复了就一个个打开,开到哪个坏掉就是它。确认冲突之后,多数情况下可以通过调整加载顺序解决——大多数脚本管理器允许拖动排序或者设置run-at的优先级。调试的时候善用控制台。脚本的日志都会打在页面的控制台里,如果看不到任何输出,先确认脚本是否真的运行了(管理器的图标上通常会有数字标记当前页面激活的脚本数)。如果脚本跑了但没日志,多半是脚本自己包了 try/catch 把错误吞了,临时把 catch 里的内容改成console.error(e)就能看见真实报错。最后分享一个小习惯,我觉得比任何技巧都值钱:每次成功跑通一个站点,把当时的 M3U8 地址结构、并发数、总耗时记在一个文本文件里。攒上十来个站点之后你会发现,同一套 CDN 或者同一个播放器框架的站点,参数几乎可以直接复用,下次遇到同类的,五分钟就能搞定,不用再重新试错一遍。