简介115网盘用户在批量转存或分享文件时常因逐个手动操作而耗费大量时间“115一键转存脚本”正是为化解这一低效痛点而生的浏览器辅助工具。脚本基于JavaScript编写需借助油猴Tampermonkey等浏览器插件运行部署轻量简单核心功能包括一键创建共享链接、批量获取下载链接、批量转存文件并支持一定程度的自动化处理可大幅减少重复操作适合需要频繁管理网盘文件的中初级用户。资源包为RAR压缩格式内部共1个文件文件类型为js脚本整体容量约9KB体量极小下载后即可快速投产使用。目前已有11430人学习或下载人气反映出该脚本在解决实际批量操作难题上颇具价值获得脚本后不仅能直接提升115网盘的整理与分享效率还能借鉴其自动化实现思路用于学习浏览器脚本开发。1. 115一键转存脚本先想清楚它到底在解决什么在115网盘网页端一条条点转存、选目录、确认操作十几条尚能忍受一旦手里攒了几十上百条115分享链接这个动作就成了纯粹的体力折磨。这篇笔记要拆的“115一键转存.user”就是一个跑在浏览器用户脚本管理器里的脚本作用是接管115网页端的转存交互把“复制链接、粘贴、解析、勾选目录、触发转存”这条链路批量自动化。脚本本身不破解任何接口不做会员功能绕过它只是把你手动做的那套点击操作用JavaScript在页面上替你按了一遍。适合两类人一类是日常依赖115收资源、给朋友转存文件的重度用户另一类是刚接触用户脚本、想看看Tampermonkey脚本如何操作SPA单页应用的开发者。前者照着装完就能省时间后者能从中看到一套完整的DOM操作和请求封装思路。2. 先把运行环境装对Tampermonkey、Firefox ESR 115与用户脚本的权限边界2.1 为什么选用户脚本而不是RPA或浏览器自动化框架新手最容易问的问题这功能用按键精灵、用Python加Selenium也能做为什么要折腾用户脚本我拆过几类方案说下差别。Python加Selenium的方案看起来自动化程度高但实际跑起来要维护浏览器驱动版本115页面是典型的动态渲染单页应用元素加载时机稍有变化find_element就会抛超时。更麻烦的是现在反自动化检测越来越敏感无头浏览器或者带自动化标记的窗口容易被识别脚本跑一半被要求重新登录是常有的事。按键精灵这类RPA工具走的是屏幕坐标点击属于“盲点”只要页面布局变一点坐标全废维护成本比写代码还高。用户脚本是另一个思路它直接注入到页面上下文里运行和网页共享DOM元素定位走的是querySelector而不是屏幕坐标页面布局调整了顶多改个选择器不需要重新录制流程。而且它常驻页面不需要每次打开浏览器再手动启动一段代码访问115页面时自动生效。代价是它受限于浏览器页面环境跨域请求需要申请GM_xmlhttpRequest权限但这正是115转存这个场景够用的边界。2.2 安装与启用从浏览器选型到脚本导入的完整路径先说浏览器。如果你只用一个浏览器Chrome或Edge装Tampermonkey都没问题。但如果你在115网页端遇到过“页面卡顿、转存按钮点了没反应”这类问题有一个很实际的组合Firefox ESR 115加Tampermonkey 4.19这个组合在115的老版本页面上兼容性最好。Firefox ESR版本走的是长期支持通道不会像普通版那样频繁更新导致插件兼容性波动。搜索词里大量出现的“firefox esr 115下载”对应的就是这个场景——老页面配老内核反而比最新版浏览器更稳。选好浏览器后装Tampermonkey扩展。装完会在工具栏出现一个黑白棋盘图标点进去选择“管理面板”这一步路径各浏览器略有差异但大方向一致创建新脚本、导入已有脚本、或直接把.user.js文件拖进面板。我建议用导入方式因为115一键转存脚本以.user.js单文件分发导入后Tampermonkey会自动解析脚本头部元数据块。导入完成后去脚本的“设置”页确认几个关键项。第一确认match规则只覆盖115相关域名避免脚本在其他网站乱执行第二确认run-at是document-end而不是document-start不然脚本执行时页面骨架还没渲染完选择器全部落空第三确认grant里申请的权限和你使用需求一致后面第4章会详细展开权限坑。设置完刷新115页面工具栏图标上出现红色角标数字说明脚本已经在这个页面注入运行了。以下是这个脚本典型的元数据块结构导入后可以在编辑页面对照// UserScript // name 115一键转存 // namespace 115-batch-transfer // version 2025.12.01 // description 在115网页端对分享链接进行批量转存支持指定目录 // author notes-from-production // match https://115.com/* // match https://*.115.com/* // grant GM_xmlhttpRequest // connect 115.com // connect *.115.com // run-at document-end // /UserScript (function() { use strict; // 脚本主体逻辑从这里开始 })();这里逐项说下元数据参数的含义因为你后续改脚本大概率会动到这几行。match声明脚本在哪些URL下执行https://115.com/*匹配主站https://*.115.com/*匹配所有子域名少一条都可能出现在某个页面脚本不生效的情况。grant声明脚本需要用到的GM系列APIGM_xmlhttpRequest是用户脚本跨域请求的通行证普通fetch跨域会被CORS挡死用这个API配合connect白名单才能绕开同源限制这是脚本能调起115接口的关键。run-at控制注入时机document-end表示DOM解析完成、资源加载前执行此时页面结构已经完整适合直接挂按钮和监听事件。装完环境只是第一步。如果刷新后脚本没运行最直接的排查方式是打开浏览器开发者工具的Console面板看有没有红色报错。常见的有两类一类是语法错误说明.user.js文件损坏或导入过程被截断重新下载导入另一类是GM_xmlhttpRequest is not defined说明grant配置丢失脚本主体在调用GM API时直接抛异常——这时候回到元数据块把grant补上再保存重载。3. 跑通第一次转存脚本的核心流程与参数调整3.1 四个执行阶段解析、取详情、选目录、触发转存我把这个脚本的工作流程拆成四个阶段分清楚之后你就知道出了问题该去哪个环节找原因而不是对着整个脚本干瞪眼。第一阶段是解析链接。脚本会在115页面上监听你粘贴到输入框的内容识别出115分享链接的标准格式。115的分享链接有两种形态带完整域名的URL以及纯分享码。脚本内部用正则做归一化把两种形态统一转成完整的分享URL再交给下一阶段。这里有一个细节值得注意脚本识别的目标链接必须放在输入框里而不是直接监听页面任意位置的文本这是为了避免误触发。第二阶段是请求详情。拿到分享URL之后脚本通过GM_xmlhttpRequest向115的分享详情接口发请求拿到分享文件的列表。这一步最关键的是接口路径和参数签名不同时间段的分享链接接口版本会有差异。脚本如果出现“解析成功但列表为空”大概率是这个接口的地址或返回结构变了需要把接口返回值打到控制台比对。第三阶段是勾选目标目录。脚本会在115的文件选择弹窗里自动匹配你预先配置的目录ID。115的目录在URL里有一个cid参数脚本配置项里填的就是这个值。如果配置的目录不存在或没有权限脚本会回退到默认目录不会直接报错——这点设计比较稳但也会让人误以为脚本没生效。第四阶段是触发转存。脚本把文件目标地址和分享信息拼接成转存请求参数依次发出。这里用了延迟队列而不是并发全发每次请求间隔几百毫秒避免短时间内请求频率过高被115风控拦下来。四个阶段的依赖关系是线性的解析失败后面全断详情为空则无法渲染候选列表目录匹配失败会静默回退请求频率过高会触发限流。把这几个节点印在脑子里排查速度会快很多。3.2 核心配置项目录ID、并发延迟与失败重试脚本预留了一段配置区在源码顶部就能看到。我拆一个典型配置结构const CONFIG { // 115网盘“我的文件”下目标文件夹的cid右键文件夹属性可查 targetCid: 0, // 0代表根目录按需修改 // 每次转存请求之间的间隔单位毫秒 requestDelay: 800, // 转存失败后的最大重试次数 maxRetry: 3, // 是否显示调试日志 debugLog: true }; function getTargetCid() { // 如果页面URL里有cid参数优先取页面参数覆盖配置文件 const match window.location.search.match(/cid(\d)/); return match ? match[1] : CONFIG.targetCid; }targetCid是最关键的参数它的值在115的“我的文件”页面URL里能看到进入任意文件夹地址栏会出现cid一串数字那个数字就是这个目录的ID。默认配置是0表示转存到根目录。如果你想批量转存到指定文件夹把数字填进去即可。requestDelay控制每两次转存请求之间的间隔。设太小比如200毫秒几十条链接嗖嗖发出去容易被接口限流设太大几百条链接要跑很久。我一般建议800到1200毫秒稳且不会太慢。maxRetry是失败重试次数115接口偶尔会返回偶发错误网络抖动或者服务端瞬时压力都会造成单次失败自动重试能显著提高整体成功率但不要把重试次数设到10次以上频繁重试反而更容易触发限流。getTargetCid函数体现了一个常见设计动态判断优先于静态配置——如果页面URL里已经带了cid参数就说明用户当前正处于某个目录中直接用这个目录作为转存目标。这是一种对用户意图的合理猜测你在哪个目录里操作就默认转存到哪里。如果脚本没有这个逻辑所有转存都落到配置里的固定目录局部使用时非常别扭。3.3 怎么判断脚本真的在干活脚本跑起来之后如果配置了debugLog: trueTampermonkey的管理面板里就能看到实时日志输出。我把日志点也列出来方便你对照。每次成功解析一条链接日志会输出[115-tool] parsed share url - ...每次转存请求发出会输出[115-tool] transferring - filename (cid)转存成功后接口会返回一个状态码日志里出现[115-tool] transfer success就是板上钉钉的成功。如果看到[115-tool] retry 1/3 ...说明第一次请求失败正在重试连续三次重试依然失败日志会打[115-tool] transfer failed并且把失败原因打出来。这里强调一个判断脚本状态的习惯不要只看页面有没有弹窗要看日志里的请求链路是否完整。因为115页面的交互非常频繁转存弹窗被页面自己的脚本关闭、DOM节点被框架重新渲染都会导致你看到的页面状态和实际执行状态不一致。日志才是脚本身体的心电图。4. 避坑清单静默失效、跨域拦截与重复执行4.1 115改版后按钮找不到脚本无报错也不干活现象页面刷新后Tampermonkey图标有角标数字说明脚本注入了但点击页面的转存按钮或者在输入框粘贴链接脚本毫无反应控制台也没有任何报错。原因脚本监听的是115页面上的固定按钮选择器比如#js_transfer_button或者.btn-transfer。115前端改版时把按钮的类名换了或者改了DOM层级脚本的querySelector查不到目标节点事件绑定失效。但是脚本主体没有抛出异常因为这段逻辑简单地“找不到就不绑”不报错也不运行。解决打开控制台执行document.querySelectorAll([class*transfer])查看当前页面转存按钮实际用的选择器是什么把脚本里对应的监听器选择器改掉保存后重新加载页面。如果页面按钮是用框架虚拟DOM渲染的还需要把事件委托挂到document上而不是具体按钮节点否则每次路由切换后监听器都会丢失。这个排查思路适用于任何“页面改版脚本静默失效”的场景没有捷径就是逐步排查选择器。4.2 转存请求被浏览器拦成CORS错误现象脚本解析链接正常目录匹配正常但一到触发转存控制台报红色错误提示类似Access to XMLHttpRequest has been blocked by CORS policy。原因脚本内部的请求走了浏览器的fetch或XMLHttpRequest而没有走GM_xmlhttpRequest。GM_xmlhttpRequest由Tampermonkey提供可以绕过页面同源策略这是用户脚本跨域请求的标准方案。如果脚本里直接封装了fetch(https://115.com/...)浏览器会按照页面的同源策略拦截响应115的接口不返回跨域头请求直接失败。解决把请求方法全部替换成GM_xmlhttpRequest同时确认元数据块里的grant包含GM_xmlhttpRequestconnect包含目标域名。常见写法是GM_xmlhttpRequest({ method: POST, url: https://webapi.115.com/transfer/..., data: payloadxxx, headers: { Content-Type: application/x-www-form-urlencoded }, onload: function(res) { console.log([115-tool] transfer response, res.responseText); }, onerror: function(res) { console.error([115-tool] transfer error, res); } });参数说明method和url不用多说data是POST请求体115接口接受application/x-www-form-urlencoded格式如果你改成application/json部分接口会解析失败。onload和onerror分别对应成功和失败回调失败时res里会有错误信息不要只在控制台看一个error就完事要把res.responseText打出来服务端返回的具体提示才是真正有用的。4.3 同一个115页面执行了两份脚本转存重复提交现象一次转存115里出现两条完全相同的文件或者接口返回“请不要重复提交”。原因用户手动导入了一次脚本文件又在Tampermonkey的在线脚本库中安装了一份两个脚本的name和namespace一致Tampermonkey会将同一标识的脚本视为同一个但如果你导入的脚本和在线安装的版本号不同两个就会同时运行。两个脚本都在页面上挂了事件监听触发了两次转存请求。解决打开Tampermonkey管理面板看脚本列表里是否有两个同名脚本。只保留一个删掉另一个。如果确实需要本地改版调试把本地版本的name改成115一键转存-dev作为区分。这是用户脚本开发里最容易被忽略的问题——平时看“未安装”状态看不出重复一执行就翻车。4.4 页面路由切换后脚本状态丢失现象在115的“我的文件”页面里脚本正常工作点击左侧导航切到“分享”页面再切回来脚本又不响应了刷新页面才恢复。原因115是SPA应用路由切换只是前端框架替换了DOM内容页面本身没有重新加载。用户脚本只在run-at document-end注入一次路由切换后新增的DOM节点上没有重新绑定事件。脚本里如果没有监听路由变化比如MutationObserver观察DOM树变化或者监听popstate事件就会丢失对新DOM的控制权。解决在脚本主体里加一个MutationObserver观察页面主体区域发现DOM变化时重新执行绑定函数。示例逻辑const observer new MutationObserver(function(mutations) { // 每次DOM变化检查目标按钮是否存在存在则重新绑定 const btn document.querySelector(#js_transfer_button); if (btn !btn.dataset.bound) { btn.dataset.bound 1; bindTransferEvent(btn); } }); observer.observe(document.body, { childList: true, subtree: true });这里的参数逻辑childList: true表示监听子节点增删subtree: true表示监听所有后代节点两者配合才能捕获路由切换后整块DOM被替换的情况。btn.dataset.bound是一个防重复标记避免同一按钮被反复绑定事件造成一次点击触发多次请求。这个方案对SPA页面尤其适用比监听popstate更可靠因为不是所有路由变化都会触发popstate。5. 验证脚本是否正常工作日志、接口比对与白名单排查法脚本装好、配置填完别急着大批量转存先跑一轮小批量验证。我的习惯是先拿三条链接试手控制台打开观察日志输出。三条链接全部转存成功再上批量三条里有一条失败先查日志定位不要盲目重试重试次数多了反而容易让115服务端暂时封禁你的转存入口。验证时重点看响应体里的状态字段。115的转存接口返回的是JSON结构字段长这样{state: true, count: 1}state为true代表转存成功。如果看到state: false把返回信息里的错误码打出来code字段比控制台报错更接近真实原因。比如错误码“文件已存在”说明源目录和目标目录有重复文件需要去重后重试错误码“分享已失效”说明分享链接过期重试也没用。还有一个实用技巧把脚本的转存接口拼接逻辑复制到浏览器的Console手动执行一次。因为用户脚本运行在沙箱环境但你的手动请求是在页面主环境发出去的如果手动请求成功而脚本请求失败问题在脚本逻辑如果两种方式都失败问题在接口本身或参数签名。这一步能快速切分“脚本Bug”和“接口变更”省掉大量无头绪排查时间。最后说一个白名单排查法。当脚本表现得“时而灵时而不灵”时用二分法缩小范围先只在一个域名下测试比如只访问115.com主站不进子域名如果一个域名下正常、另一个域名下异常优先检查match和connect的域名覆盖范围。再只转存一条链接观察请求是否发出、响应是否正常。如果单条正常、多条失败问题在并发或延迟参数上加大requestDelay。这个习惯我沿用很久了——从那以后每次115改版或者我改完脚本配置我都会强制走一遍“三条链接、看日志、看响应码、切域名”的流程日志打不满就不准上批量转存。希望这篇复盘能帮你在115转存这件事上少折腾几个晚上。本文还有配套的精品资源点击获取