三万多颗星的项目，第一眼看像“网盘下载加速器”。它其实在做另一件事：给九家网盘当适配层，说白了就是翻译。九家各有一套只有自己认的规则，这个项目把九套规则塞进一个 764 KB 的脚本，让同一个按钮在九个网站上都能用。它的更新日志里，修修补补排了 45 次，真加新功能只有 7 次，这个比例比星数诚实——单文件、九千多行、没有自动测试，这套形态都是被同一件事逼出来的：得跟着九家网盘一起改版。
它把九个网站，说成同一种语言
项目 2022 年 8 月开的张，到现在四年多，协议是 AGPL-3.0。据仓库首页的数据，现在 37,111 个星、2,646 次复刻。它是从一个更早的脚本改出来的，原作者至今还挂在署名里。最初只覆盖个别网盘，四年下来扩到九家：个人网盘、运营商提供的网盘、浏览器自带的网盘，都算在内。
为什么说它是翻译层？看脚本开头两份清单就有数。第一份写着“在哪些网页上生效”，40 条；第二份写着“允许往哪些网站发请求”，24 条。九家网盘分这 40 条，平均一家四条往上。同一个网盘，个人主页、分享页、时间线、嵌入播放页，网址各不相同，只能一条条列。
第二份清单更能说明问题。光其中一家，就占了六个域名：一个主站、五个备用入口，外加一个专门放文件的下载站。域名是人家的资产，加一个、换一个，脚本这边只能跟着改。
所以真正难维护的不是“下载”这个动作，是那张对照表：哪个网址用哪套接口、文件名藏在哪个字段、下载时要不要带上特定信息。加功能一个版本就能写完，这张表要一直写下去。
为什么要抢在网页前面跑
根据更新日志，2025 年 5 月的一个版本做了件不太显眼的事：让脚本更早启动，早到网页本身还没开始加载。好处很直接，网盘页面会自己重建下载按钮，脚本进得晚，改完就被覆盖；进得早，就能在页面动手之前占好位置。
代价也很实在。网页还没长出来，脚本找不到能挂按钮的地方，只能改成“盯着页面，等那个位置出现再插进去”。源码里有四处这样的盯梢，另外还有十六处把设置存在浏览器本地——一边看页面变不变，一边记住用户选过的主题色和下载软件。
这就解释了更新日志里“适配新版分享页”这类条目为什么反复出现。改版改的常常不是功能，是网页元素的命名和层级。脚本靠这些名字找位置，名字一换就全断。把启动时间提前，等于把自己绑在了对方网页的最上游。
那把钥匙，换成了一张临时通行证
2025 年 7 月的版本把一套长期凭证的代码整段删了，换成有时效的令牌。前者相当于账号的长期钥匙，登录状态就挂在里面，泄漏出去，损失远不止“这次下载失败”。换成令牌之后，能做的事被限定成两项：看基础资料、读写网盘里的文件。
换法的代价藏在授权方式里。据这家平台的开放文档，“没有服务器的小工具”有一条捷径：不用中转，令牌直接随网址交回网页。文档同时也写明，这种令牌不能续期，过期就得重新登录、重新点一次同意。仓库里那份备用配置正好对得上这套路：回跳地址用的是“由用户自己取走”的方式。
不能续期，就没有悄悄续命。用户隔一阵子必然被弹一次授权页，这不是 bug，是没有服务器这个前提的价格。时间线也能佐证：早在 2024 年 10 月，修复记录里就出现过“令牌过期拿不到地址”，比正式换令牌还早了九个月。痛点先来，方案后到。
还有一处细节值得记一笔。脚本的生效清单里，单独留了一条平台授权页。按上面这套流程推断，它是用来在跳转回来时把令牌接住的——没有服务器能接，只能自己站在那个页面上取。
地址拿到手，还有最后一段路
拿到下载地址只是一半，剩下的路有三条，各有各的坑。第一条最省事，交给浏览器自己下载。但浏览器不让脚本替它填写“你从哪儿来”这类身份信息，碰上较真的服务器，直接失败。
第二条是转给本机的下载软件。做法是给软件发一条格式固定的指令，把地址和几个附加信息一起塞进去，其中就有“从哪个网页来”“用什么浏览器”——这些正是浏览器不肯替脚本填的东西，换个地方补上。愿意装软件的人走这条路最稳。
第三条有点将就：让脚本自己在浏览器里把文件切成小块抓回来，再在内存里拼成一整块存下来。不用装任何东西，也能带对信息，但脚本自己标了上限，两个 GB 以内，再大就卡内存，非必要别用。
| 走哪条路 | 能带身份信息吗 | 文件上限 | 要装软件吗 |
|---|---|---|---|
| 浏览器直接下载 | 不能 | 看浏览器 | 不用 |
| 转给下载软件 | 能，可自定义 | 看软件 | 要 |
| 浏览器里切片拼装 | 能，由脚本代填 | 约两个 GB | 不用 |
三条路摆一起看，选哪条取决于“这个服务器挑不挑身份信息”和“文件多大”，跟快慢没什么关系。项目自己也划了这条线：说明里用了整段话否认能破解限速，还把“加速下载”“速度起飞”一类说法归到第三方夸大宣传上。它想守住的位置是“用公开接口把文件取下来”，不是“跑得比会员快”。
六十五个版本，记的是别人的节奏
按更新日志统计，一共 65 条版本记录，横跨 2022 到 2026。按年份数，2023 年一年 26 版，占了四成，之后回落到每年十几个。按类型数，修复 45 次、优化 20 次、适配 9 次、新增 7 次，修复是新增的六倍多。
| 年份 | 版本数 | 占比 |
|---|---|---|
| 2022 | 8 | 12% |
| 2023 | 26 | 40% |
| 2024 | 14 | 22% |
| 2025 | 15 | 23% |
| 2026 | 2 | 3% |
这组数字要配上另一件事才完整：项目里自动测试那一栏，写的是直接报错退出，开发依赖只有一个代码检查工具。换句话说，每次改完，验证方式是人打开九个网站点一遍。没有自动检查的项目，修复条目自然占大头，回归全靠人手，只能发得快、靠用户报。
还有一层是信任范围。脚本的请求白名单第一条是通配符，意思是“哪都能去”，第二条指向本机，给下载软件用，真正的名单在后面二十多条。这样写省事，代价是：一个 764 KB、单人主导、更新自动生效的脚本，实际上握着在浏览器里向任意地址发请求的能力。再加上仓库里那份来自原作者服务器的备用配置，以及三个从公共网络地址临时加载的第三方库，链上任何一环出问题都会往下传。
说到底，一个开源项目长什么样，往往由它绕不开的限制决定，而不是功能清单。它站在别人的页面上，用别人的接口，所以只能是单文件、没测试、跟着改版跑。维护成本不取决于自己写了多少代码，取决于那九家网盘多久改一次。这条曲线，比星数更能回答它还能走多远。
评论