1. 不要用正则去抠HTML解析入口选错了后面全是坑最早做这个纯前端Reddit视频下载器的时候我犯过所有新手都会犯的错拿到一个帖子链接想着用fetch拉下来 HTML然后用一串正则在video、script里找资源地址。听着挺直接结果第一天就翻车。原因其实很简单。Reddit 页面绝大多数内容是服务端渲染加客户端水合视频信息并不稳定地出现在某一处固定的video标签里。有的页面里 URL 是经过转义的有的被拆成 JSON 片段塞在shreddit-app组件的状态里还有的会被 CDN 参数签名改写。你花一晚上写出来的正则第二天可能就因为某个属性的顺序变化而失效。后来我把思路整体换掉不碰 HTML只碰 Reddit 给的内容模型也就是 JSON API 返回的数据结构。只要拿到帖子的id请求对应的comments/{post_id}.json接口返回结果第一层的Listing里就带完整的帖子数据其中media字段就能找到视频的详细信息。这是一个很关键的设计决定。HTML 是给人看的JSON 是给程序用的。作为前端开发者我们要做的是把自己当成一个轻量客户端去消费目标平台本来就公开的结构化数据而不是靠抠标签碰运气。这个思路后来帮了我大忙因为 Reddit 的 HTML 结构经常微调但 JSON 字段的稳定性远高于页面结构。除了选型上的学习之外这里还有一点值得展开解析器的主入口必须容忍多种输入形式。用户在真实使用场景里不会总是给你一个干净的帖子链接。他可能粘贴的是带?utm_sourceshare这种追踪参数的分享链接也可能是因为社交平台截断而少掉末尾斜杠的链接甚至直接给一个帖子 ID。我在项目里会对输入做一个三层兼容先尝试识别comments/{id}再尝试识别v.redd.it/{id}最后把裸 ID 也当作合法输入。每一个分支都走同一个标准化函数统一返回帖子 ID。这样才不会被用户五花八门的粘贴方式逼疯。这个阶段的另一个经验是不要自己去实现“看起来能工作”的 URL 判断逻辑直接用标准 URL 构造函数去解析。很多人喜欢写一堆indexOf和slice吃力不讨好还容易在处理查询参数时把 ID 切坏。用new URL(input).pathname取出路径段然后按段匹配既干净又天然兼容各种 query 参数。提示Reddit 的 JSON API 是公开接口但任何程序访问前都需要遵守目标平台的访问规则。高频请求会导致限流正式使用前要仔细阅读平台的开发者条款。2. Reddit视频数据模型拆解media、reddit_video与那些让人困惑的URL字段既然决定用 JSON 当入口接下来最要紧的就是把数据模型吃透。我调试过程中反复对比了大量帖子的返回结构整理出了一套相对稳定的字段映射下面这块内容是整个下载器的地基。帖子对象里跟视频相关的核心结构长这样{ data: { children: [ { kind: t3, data: { id: abc123, title: A Very Cool Cat Video, author: some_user, subreddit: cats, url: https://v.redd.it/xyz987, media: { reddit_video: { bitrate_kbps: 2000, fallback_url: https://v.redd.it/xyz987/DASH_720.mp4?sourcefallback, hls_url: https://v.redd.it/xyz987/HLSPlaylist.m3u8?..., dash_url: https://v.redd.it/xyz987/DASHPLAYLIST.mpd, duration: 64, height: 720, width: 1280, is_gif: false, scrubber_media_url: https://v.redd.it/xyz987/DASH_96.mp4, transcoding_status: completed } }, secure_media: { reddit_video: { fallback_url: https://v.redd.it/xyz987/DASH_1080.mp4?sourcefallback } }, is_video: true } } ] } }有几个字段值得单独说。media和secure_media绝大多数情况下是一样的区别在于 HTTPS 环境下是否强制加载安全资源。我建议解析时优先取secure_media因为现在的浏览器对混合内容管得很严如果一个视频地址本身是 HTTP 的在 HTTPS 页面里就可能被直接拦掉。reddit_video.fallback_url是最容易理解的字段它是一个 MP4 的直链带sourcefallback参数。这个直链在很多下载器网站里被拿来当默认下载源因为它是一个完整容器浏览器可以直接播放和保存。但问题在于它不一定是最佳分辨率fallback 往往会被服务端降级尤其在原格式分辨率很高的时候。hls_url和dash_url则代表了不同封装协议。HLS 是 Apple 主导的直播流协议现在也广泛用于点播DASH 是国际标准组织推动的动态自适应流媒体协议。Reddit 对同一个视频通常会同时给出 HLS 和 DASH 两种清单这给前端拿到“最高可用清流”提供了可能但也带来了解析复杂度。scrubber_media_url这个字段不显眼但很实用。它是预览拖拽时用的超低码率 MP4我最初完全忽略了它后来在调试“封面图不显示”这种边缘场景时才发现它的存在。它体积小、加载快适合用来做进度条上面的动态预览。我还遇到过一个坑media字段可能是null也可能是{}。对于纯图片帖、投票帖、文本帖这个字段直接就是空。在编写解析器时千万不要假设每个帖子都有media.reddit_video这种假设会在真实数据里被无情打脸。正确姿势是层层判空一旦取不到视频对象就明确告诉用户“当前帖子没有可用的视频信息”而不是抛一个神秘的 TypeError。为了方便团队里的其他人理解我做了一个简单的字段对照表字段作用使用注意fallback_urlMP4 格式兜底直链可能分辨率不是最高适合快速出结果hls_urlHLS 流清单入口需要解析 m3u8适合追求最高清晰度dash_urlDASH 流清单入口浏览器原生支持有限通常需要额外处理scrubber_media_url极低码率预览视频常用于进度条缩略预览transcoding_status转码状态必须是completed才能下载is_gif是否静音循环视频为 true 时通常没有独立音轨把这张表记熟之后再去写解析逻辑脑子会清晰很多。3. HLS清单为什么要单独处理m3u8的解析与降级策略拿到hls_url只是第一步因为它是清单文件地址不是一个可以直接保存的 MP4。下载器要做的是把这个 m3u8 文件拿下来读懂里面的分片结构再把所有分片拼成一个完整视频。这个流程对很多只写业务前端的人来说可能比较陌生但拆开看并没有那么神秘。一个典型的 HLS 播放列表长这样#EXTM3U #EXT-X-VERSION:6 #EXT-X-TARGETDURATION:4 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-PLAYLIST-TYPE:VOD #EXTINF:2.000, https://v.redd.it/xyz987/segment_0.ts #EXTINF:2.000, https://v.redd.it/xyz987/segment_1.ts #EXTINF:2.000, https://v.redd.it/xyz987/segment_2.ts #EXT-X-ENDLIST这里每一个#EXTINF后面跟一个分片地址前面那行表示分片时长。如果清单末尾有#EXT-X-ENDLIST说明这是一个完整的点播视频可以放心把所有分片都拿下来如果没有这个标记说明是直播流视频可能在持续生成这时候去下载就没有意义。我在实现解析时写了几个小的纯函数第一步是把分片地址抽出来function parseHlsSegments(content) { const lines content.split(\n); const segments []; for (let i 0; i lines.length; i 1) { const line lines[i].trim(); if (line.startsWith(#EXTINF)) { const durationMatch line.match(/#EXTINF:([\d.]),/); const nextLine lines[i 1]?.trim(); if (nextLine !nextLine.startsWith(#)) { segments.push({ duration: durationMatch ? parseFloat(durationMatch[1]) : 0, url: nextLine }); } } } return segments; }这里有一个非常重要的细节分片地址可能是相对路径。Reddit 的 HLS 清单里分片地址有时直接给完整 URL但有些 CDN 配置下给的是不带域名的路径。如果你直接拿这个相对路径去请求一定会 404。正确做法是根据hls_url的域名做一次 URL 拼接function resolveSegmentUrl(baseUrl, segmentUrl) { return new URL(segmentUrl, baseUrl).toString(); }如果你熟悉浏览器里的URL构造函数应该知道第二个参数就是 base这段代码能同时处理绝对地址和相对地址是一个非常值得记住的细节。解析完清单后下一步是考虑降级策略。HLS 清单解析得好好的但用户说他下载失败这种情况我遇到过太多次。原因通常是两类一类是 CDN 签名过期地址返回 403另一类是网络环境对 .ts 分片的访问不稳定。因此我在下载流程里设计了三级降级先从 HLS 清单抓取所有分片逐个并发下载最后拼接成 TS 文件。如果 HLS 失败回退到fallback_url直接下载 MP4。如果 MP4 也失败把dash_url和hls_url原样展示给用户让用户在电脑上配合专业下载工具手动处理。有人说第三级回退太“弱”了但我觉得这是最诚实的设计。前端能做的优化是有限的与其让用户卡在一个成功率为零的流程里不如把选择权交还给用户。这个思路在项目后期救了很多次场。4. 绕不开的浏览器边界CORS、Blob和对象URL这个部分是整个项目里最“前端”的部分。因为无论你的解析逻辑写得多严谨最终你仍然要面对一个现实浏览器不是 Node.js跨域请求不是你想发就能发。Reddit 的 JSON API 默认不会给任意前端页面签发跨域访问许可也就是说如果你把一个纯静态页面部署在example.com然后直接在浏览器里请求https://www.reddit.com/comments/abc123.json大概率会被 CORS 策略拦截。这是浏览器的安全设计不是平台方故意刁难。最初我为了完全“纯前端”尝试过各种取巧方式后来统一认识到一个边界前端的根目录永远是用户的浏览器而不是你的服务器。如果你想让用户输入链接就能自动请求 Reddit 的接口就必须在中间加一个代理层。代理层不是后端项目它可以是一个 Serverless Function也可以是一个简单的 Node 脚本但它的本质是一个中间人负责向前端提供 CORS 响应头。但对于很多人来说他们想要的是一个完完全全没有后端的版本比如做成一个静态页面部署在 GitHub Pages 上。这种情况怎么办我的方案是允许用户手动粘贴 JSON。用户在浏览器里打开 Reddit 的 JSON 地址把内容复制进文本框前端解析器在本地完成所有解析工作然后生成下载链接。这个过程不涉及任何跨域请求所有逻辑都发生在用户自己的浏览器里数据也不会上传到任何服务器。这个方案看似笨拙反而是最安全、最合规的。用户自己决定要解析什么内容工具只做本地处理不缓存、不追踪、不上传。我把这种模式叫做“离线导入模式”它适合个人工具和隐私敏感场景。在真正执行下载时还有一个技术点值得展开。浏览器里的下载通常不是直接“保存远程文件”而是先获取资源内容再创建对象 URL然后触发a标签下载。代码是这么写的async function downloadBlob(url, filename) { const response await fetch(url); const blob await response.blob(); const objectUrl URL.createObjectURL(blob); const link document.createElement(a); link.href objectUrl; link.download filename; document.body.appendChild(link); link.click(); link.remove(); URL.revokeObjectURL(objectUrl); }这个过程涉及一个常见的隐藏 bug如果filename里有/或者反斜杠浏览器在做 download 时会把路径截断或者拒绝下载。尤其是帖子标题里的特殊字符简直是下载器的一个大坑。所以我在生成文件名时会先把非法字符全部替换掉顺便做一个长度截断function safeFileName(raw) { const cleaned raw.replace(/[\\/:*?|\s]/g, _); return cleaned.length 60 ? cleaned.slice(0, 60) : cleaned; }另外对象 URL 是有内存开销的。视频文件动辄几十 MB如果用户连续点了很多次下载浏览器的内存占用会肉眼可见地涨上去。所以我每次下载完都会立刻revokeObjectURL这是一个容易被忽略但非常重要的回收动作。还有人问为什么不用download属性直接挂远程 URL因为在跨域情况下download属性是无效的浏览器会把它当成普通跳转直接打开播放页面根本不会触发下载。只有通过 fetch 拿到本地 Blob再创建对象 URL下载行为才受页面脚本控制。5. 音频视频分离纯前端怎么交付Reddit 视频有一个让所有下载器都头疼的特点视频画面和声音数据是分开存储的。你在页面上看视频时感觉一切正常是因为播放器在背后同时拉了两个流一轨是纯画面一轨是纯声音然后在播放器内部把它们同步播放。但如果你只下载了fallback_url里的 MP4运气好的话它自带音轨运气差的话就只有画面没声音或者反过来。HLS 清单里通常只包含视频分片音频清单是另一个地址。想要得到完整带声音的视频最理想是把它俩合并成一个容器。但是纯粹的浏览器前端做不了这种容器级别的封装因为浏览器没有提供一个公开 API 可以直接做 MP4 Muxing。行业里最常见的解法是把视频和音频两个文件都下载下来作为两个资源输出给用户。如果用户有 ffmpeg给出一行简单的命令行去合并。如果目标平台允许在项目里内置一个基于 WASM 的 ffmpeg 库在浏览器本地完成合并。第 3 种方案听起来最完美但实际工程坑很多。WASM 版 ffmpeg 会把大量计算放到浏览器线程里如果视频是 4K 高清转换时内存峰值可能直接爆掉而且耗时很长。我测试过一个 3 分钟 1080p 的视频合并过程跑了快一分钟页面卡到几乎没法操作。所以这个方案我只做成“高级选项”默认不用。还有一种相对轻量的方式是用MediaSourceAPI 在浏览器里把音视频轨道加载进同一个媒体源实现播放级合并。注意这只是在播放器层面把两路流同步起来它并不会生成一个新的 MP4 文件。也就是说用户可以预览最终效果但无法直接保存合并后的成品。这个方案适合做“试看”功能而不适合做“下载”功能。回到下载器的实际体验上我最后的产品设计是把每个可用的流资源都展示到界面上明确标注它是“高清无音轨”“低清带音轨”还是“原始音频”用户都能一眼看懂。同时给出一段 ffmpeg 命令作为附加提示ffmpeg -i video.mp4 -i audio.mp4 -c:v copy -c:a aac output.mp4这比把用户关在一个纯前端黑盒里更负责任。用户是内容的使用者他应该知道自己下载的文件是什么形态而不是拿到一个只有画面没有声音的文件后骂工具难用。6. 合规不等于免责声明下载器的边界设计标题里特意写了“安全合规”这四个字不是用来装点门面的。从我做第一款在线下载工具的经验来看合规问题往往不是在技术上翻车而是在产品设计上没有一点边界感。先说最基础的原则这个下载器只能用于下载用户有权下载的内容。比如你自己上传的视频、版权人明确允许分享的视频、遵循开放许可协议的内容或者用于个人学习、内容备份等场景。如果用户拿这个工具去批量爬取别人作品并声称是“技术无罪”这是非常危险的。在实现层面我做了几件具体事情来落实合规第一是限速和限流。解析器的按钮做了防抖工具内部有一个简单的队列避免用户在极短时间内发起几十次请求。单用户访问频率被限制在一个合理水平不会对目标平台造成压力也能防止自己被封禁。第二是不保存用户数据。无论是帖子 JSON 还是最终下载的媒体地址所有处理都是在用户浏览器本地完成的。我没有设计服务端存储也不保存日志。用户用的过程里产生的文件只会留在用户自己的设备上。这一点对隐私友好的工具来说非常关键。第三是明确提示和拒绝。在界面最显眼的位置写清楚工具的用途并且把“禁止用于侵权、批量抓取、再分发”作为使用前提。听起来像一句废话但我真见过有人复用这个代码做成一个自动批量下载机器人。所以我还在代码里加了一道硬性检查如果一次导入的 JSON 里包含多个帖子并且触发了批量下载模式就弹窗要求用户确认自己是否获得了授权否则直接中断流程。第四是尊重平台规则。凡是抓取类工具都要把目标平台的访问频率、用户协议、robots 文件这些都当成硬性约束而不是可以绕过的障碍。如果某个接口明确要求附带认证那就不应该用匿名方式强行访问。如果一个地址上有明显的 DRM 保护那就不应该去碰。技术的上限很重要但下限同样重要。合规不是一句“仅供学习”就能撇清的它必须体现在每一个产品决策里。如果在一开始设计时就把边界画清楚后续就算项目公开出去也不会把自己放到被动位置上。7. 上线之后踩过的坑最后这部分我按真实项目的先后顺序记录几个影响最大的坑。这些问题不一定出现在教科书里但它们才是项目从“能用”到“好用”的分水岭。第一个坑是m3u8 里只有相对路径。我第一次解析出segment_0.ts这种分片地址时直接不管三七二十一拿它去请求结果一片 404。当时我怀疑是 CDN 问题折腾了半小时才发现是相对地址没有拼前缀。后来我用new URL(segmentUrl, hlsBaseUrl)统一处理问题立刻消失。希望读到这篇的人能直接绕过这个坑。第二个坑是fallback_url有时候是 403。原因是 CDN 签名地址带时效参数但我的浏览器缓存里有旧版本。浏览器拿到一个新 URL 后如果没有禁用缓存中间环节可能会命中旧地址。解决办法是在 fetch 时显式加上cache: no-store并给 URL 末尾补一个时间戳参数。虽然不优雅但确实管用。第三个坑是音频下载的 Content-Type 很迷。Reddit 的音轨分片地址有时返回video/mp4有时返回application/octet-stream。我在做 Blob 类型判断时一开始统一设置成了video/mp4导致在部分安卓浏览器上音频文件无法自动播放。后来改成根据 URL 后缀推断能匹配到audio/mp4的就用音频类型匹配不到的就用application/octet-stream交给系统处理问题才算解决。第四个坑和 iOS Safari 有关。iOS Safari 优先全屏播放视频对download属性的支持一直不够积极。在部分版本里用户点击下载后视频会直接开始播放而不是弹出保存菜单。这个不能算代码 bug更多是平台策略。我后来在下载按钮旁边加了一行小字“若在手机浏览器中无法下载请在电脑端操作或长按链接后选择存储。”这个提示虽然朴素但让客服压力小了很多。第五个坑是一个听起来很蠢但影响巨大的细节帖子 JSON 里可能有多个视频候选。我一开始只取media.reddit_video后来遇到一个画廊帖gallery post里面包含多张图片和一个视频media是null视频信息被放在别的地方。这逼着我重写了数据提取逻辑把解析目标从“找到一个视频”改成“找到所有可能包含视频的位置”然后逐个尝试最后汇总成资源列表。这虽然增加了复杂度但面对真实世界的多样性反而更可靠。最后我想说的是做这类工具最大的乐趣不只是“能下载了”而是你逼迫自己把平台的数据结构、浏览器的能力边界、用户的行为习惯全部拼到一张图里然后找到一个能落地的平衡点。开发流程上也建议多留一些单元测试把不同字段形态的 mock JSON 固化下来下次改代码时运行一遍测试就知道有没有破坏老功能。请记住下载器不是“能通就行”的业务逻辑它本质上是一个小型的媒体处理系统认真对待它才能做出一版不丢人的作品。