简介：115转存助手UI优化版3.9.1是一款由网友魔改的115网盘辅助脚本，主要面向需要批量转存、文件提取和自动化管理的115用户。该版本重点优化了交互界面，使操作更直观，同时修复了原版中常见的转存中断、大文件提取错误等问题，整体稳定性明显提升。包体十分精简，仅包含1个js脚本文件，压缩后大小约44KB，使用时无需安装复杂依赖，直接配合相关环境即可加载运行。目前已有2.2万余人学习或使用过这份资源，足以说明其在社区中的实用价值。通过这份脚本，用户可以快速实现批量转存与提取修复后的完整功能，还能借鉴网友对界面和逻辑的魔改思路，适合有一定动手能力的115重度用户收藏使用。

1. 115转存助手3.9.1魔改版：这个版本把转存提取修到了什么程度

手里攒着几十条“115分享链接+提取码”，在资源群、表格、备忘录里来回复制，一条条打开网页版转存，是很多往网盘搬资料的人每天最烦躁的环节。115转存助手就是解决这个问题的用户脚本，而3.9.1这个由社区网友魔改的UI优化版，把原版遗留的目录树点选、提取码识别、日志遮挡三块问题做了集中修补，转存提取这条链路才算真正恢复到“能用”的状态。适合两类人：一类是每天批量整理网盘资料的搬运型用户；另一类是拿网盘当素材库、希望一条链接直接落进指定目录的内容工作者。下面不吹版本，只拆改动、讲安装、跑一遍实战，再把最容易翻车的地方提前摆出来。

2. 改动拆解：UI优化、转存链路与提取修复分别做了什么

这个魔改版不是简单换个皮肤。我拆过好几个版本，3.9.1的核心价值集中在两块：一是把原本凑合能用的小按钮改成了可持续操作的工具条；二是把转存提取主流程里散落的bug串起来修了一遍。下面按三块讲。

2.1 UI优化：不是把按钮换个皮

原版最常见的毛病是工具栏按钮挤在页面右上方，窗口稍微窄一点就显示不全；转存日志面板默认驻留右下角，直接把文件树遮住一大截，想选“目标目录”还得先把日志折叠起来。魔改版的处理方式是把主操作收敛到一个悬浮工具条，日志面板改成可折叠、可拖拽的小气泡层，默认半透明，鼠标移上去再展开，同时增加跟随网页版亮色/暗色模式的选项。

// 工具条挂载示意：在 document-end 阶段创建容器 const bar = document.createElement('div'); bar.id = 'trans-toolbar'; bar.style.cssText = 'position:fixed;right:24px;bottom:80px;z-index:9999;'; // 传统做法是把所有按钮塞进页面顶栏，这里改成 fixed 悬浮层，避免撑破布局 const btn = document.createElement('button'); btn.textContent = '转存'; btn.addEventListener('click', () => openTransDialog()); bar.appendChild(btn); document.body.appendChild(bar);

这段代码里两个参数值得注意：position:fixed让工具条脱离网盘页面的常规文档流，窗口缩放时不会被挤走；z-index:9999是为了压过网盘自身的浮层组件，否则面板会被遮挡。按钮用click事件而不是mousedown，兼容触摸屏和鼠标的差异。实际使用时，如果发现按钮加载后又消失，多半是页面框架重绘把挂载点清掉了，后面避坑章节会专门说。

菜单逻辑也有变化。原版把“转存”“提取日志”“设置”拆成三个入口，魔改版合并成一个“转存”主面板，内部用标签页切换。这样做的收益很直接：新手只需要认准一个悬浮按钮，不用记三个位置。

2.2 转存链路：从粘贴到转存要过三道识别

脚本要处理的输入格式远不止一种。常见的有：普通分享链接（带share_id）、带提取码的链接（share_code）、sha1格式链接，以及纯目录分享链接。如果解析阶段识别错类型，后面所有请求都会白跑。我一般把解析逻辑拆成“先匹配sha1，再回退匹配share_id/share_code”的顺序，因为sha1格式本身带路径信息，识别优先级最高。

function parseShareInput(raw) { // 第一条正则命中 sha1 格式，字段依次是协议、文件名、40位sha1、大小、路径 const sha1Match = raw.match( /^115:\/\/(.+?)\|([a-fA-F0-9]{40})\|(\d+)\|(.+)$/ ); if (sha1Match) { return { type: 'sha1', name: sha1Match[1], sha1: sha1Match[2], size: Number(sha1Match[3]), path: sha1Match[4] }; } // 第二条正则匹配带 share_id 的网页分享链接 const shareMatch = raw.match(/[?&]share_id=(\d+).*?(?:share_code=([\w-]+))?/); if (shareMatch) { return { type: 'share', shareId: shareMatch[1], code: shareMatch[2] || '' }; } return null; }

注意raw在进入解析前要做一次trim()，否则从聊天软件复制过来的链接经常带着换行符或首尾空格，正则会直接空手而归。提取码这组参数用[\w-]匹配，兼容有连字符的分享码；如果服务端返回的提取码带%编码，还需要额外做一次decodeURIComponent，这是社区版最容易漏掉的地方。

原版一个更隐蔽的问题是文件树只加载第一层目录。分享链接指向一个多级文件夹时，第二层及以下全部点不开，转存只能拿到最外层。这个魔改版常见的做法是在接口返回后做递归拼接，按“父目录id”把子项挂到树形结构上，点击展开时才惰性加载。也就是说，展示的是完整目录树，但请求仍然是按需发出的，不会一次性把几十个目录全拉回来。

2.3 提取“全修复”：一张表看懂修了什么

判断一个魔改值不值得更新，就看它对下面这些场景的处理。3.9.1的“转存提取全修复”主要体现在这张表里：

这张表相当于一个选型清单。如果你拿到的是别的版本号，先对着表里对照一遍，如果好几项都没有动静，那基本只是拿原脚本重新打包，并没有真正处理转存链路的深层问题。

3. 部署与配置：三步装好脚本并校准参数

用户脚本的安装门槛不高，但参数配置不对，后面跑批量任务时早晚翻车。这一章按“装管理器、导入脚本、验证生效”三步走，每一处参数都解释为什么这么设。

3.1 第一步：安装用户脚本管理器

先去浏览器扩展商店搜索 Tampermonkey 并安装，也可以用 Violentmonkey，两款都能跑，只是配置面板入口略有不同。装完后点扩展图标，选“添加新脚本”，把下面这段元数据骨架贴进去，再把脚本正文替换成你下载到的魔改版内容：

// ==UserScript== // @name 115转存助手 3.9.1-魔改UI版 // @namespace trans-helper.local // @version 3.9.1 // @description 转存提取全修复的社区魔改分支，含user标识 // @match https://你的网盘域名/* // @match https://你的网盘域名/v/* // @run-at document-end // @grant GM_xmlhttpRequest // @grant GM_setClipboard // ==/UserScript==

三个关键参数要理解清楚，不能照抄：

@match决定脚本在哪些页面执行，必须准确覆盖网盘主页和文件页，写错一个字符脚本就不注入。我一般会把根域和带路径的页面各写一条规则。@run-at document-end表示等页面DOM渲染完成再注入脚本，如果改成document-start，很可能按钮还没挂上就被网页框架的重绘逻辑清掉。@grant GM_xmlhttpRequest是给脚本开跨域请求权限，转存接口和分享接口属于不同子域，没有这条权限会遇到混合内容拦截。

3.2 第二步：导入脚本并打开配置面板

如果拿到的是.user.js文件，直接把它拖到浏览器窗口，扩展管理器会弹出安装确认。装完后打开网盘页面，脚本图标上会出现“待运行”角标。点击脚本图标进入管理面板，重点看这几个配置项：

并发数和延迟是一对组合参数。实测网盘的分享接口对同一会话有频控逻辑，并发开到5以上，跑几十条任务时很容易出现红色错误码；降到2并发、延迟400ms左右，稳定性最好。这是一条血泪经验：批量转存慢一点不会死，被频控踢下线才是真正的灾难。

3.3 第三步：验证脚本真的在跑

打开网盘页面后，按F12进控制台，输入下面这段代码确认脚本已经注入：

// 验证用户脚本是否成功注入 const ver = document.querySelector('#trans-version'); if (ver) { console.log('[trans] ready, version =', ver.textContent); } else { console.warn('[trans] not injected: 检查@match域名与脚本启用状态'); }

这里#trans-version是脚本挂在工具条上的版本元素，如果控制台拿到[trans] ready，说明脚本已经接管页面。如果输出的是 warning，按三个方向查：脚本是否在扩展面板里被关闭；@match是否匹配当前域名；浏览器是否装了第二款脚本管理器导致权限互相干扰。还有一个偏门的后悔药：把脚本在编辑页面随便加一个空格再保存，强制重新注入一次，有时比刷新页面可靠。

4. 实战转存提取：目录定位、批量任务与日志判读

配置完成只是起点，真正决定好不好用的，是转存目标目录的定位逻辑、批量任务队列的设计，以及日志到底怎么读。这一章跑一遍完整流程。

4.1 单链接转存：从粘贴到落库的完整操作

日常操作不复杂：复制分享链接和提取码，点悬浮工具条上的“转存”，在弹出面板里选目标目录，再点“开始转存”。有三个细节容易踩：

第一，粘贴内容保留换行没问题，脚本按行解析，提取码单独一行也能识别。第二，工具条面板里的目录树默认只展开到第二层，更深层目录需要点击展开，这不是bug，是惰性加载的设计。第三，目标目录必须通过树形控件选中，不能手动输入路径，接口按目录id寻址，不认路径字符串。

function buildTransferTask(parsed, targetDirId) { const task = { kind: parsed.type, target: targetDirId, // 网盘内部目录id，不能传路径字符串 filename: parsed.name, sha1: parsed.sha1, size: parsed.size, dupe: config.skipDuplicate, // 转存前按sha1去重 status: 'pending' }; console.log('[trans] task planned', task); return task; }

target字段值得单独强调。网盘接口按目录id寻址，传路径字符串会出两个问题：中文路径需要完整编码，且层级关系一旦带错一个斜杠，文件就落到别的目录。所以脚本里所有目录选择结果最终都映射成dir_id，日志里看到的currentDirId就是当前选中的目录。如果你发现转存后文件去了根目录，九成是这里变成了默认值。

4.2 批量转存：二十条链接一次跑完

批量输入区支持多行粘贴，每行一条链接，脚本逐行解析后压入任务队列。队列状态分pending、success、failed三种，失败的任务不会阻塞后续链接继续跑。

const queue = links .map(parseShareInput) .filter(n => n && n.type) .map(p => buildTransferTask(p, state.currentDirId)); runWithLimit(queue, { concurrency: 3, // 实测2~3最稳，再高容易触发频控 delay: 400, // 每次请求间隔毫秒 retries: 1 // 只重试一次，避免死循环轰炸接口 });

runWithLimit是脚本内部的并发控制函数，concurrency控制同时发出的请求数，delay控制每个请求之间的间隔，retries控制失败后的重试次数。我用下来觉得retries设1最合适：重试两次以上，遇到频控时会在同一个错误上反复撞墙，日志里刷屏，接口不会因为多试几次就放开限制。

4.3 读日志：区分“转存完成”和“转存成功”

这是新手最容易误解的一点。日志面板里出现“任务完成”，只代表脚本把当前循环跑完了，不代表文件真的进了网盘。“转存成功”才是接口确认落库。区别在哪里？看返回状态码：

更隐蔽的情况是接口返回200，但文件没出现在目标目录。此时去根目录看一眼，因为目标目录id在会话中失效时，接口会把文件静默放到默认目录。日志和实际文件树不一致，是用户脚本里最典型的“黑匣子”，也是最容易让人误判脚本失灵的场景。

5. 避坑排查：六个导致转存失败或误转的典型场景

这些坑大多不是脚本自身的逻辑bug，而是用户脚本机制和网盘网页版交互方式共同造成的。提前看过，能省出大半天排查时间。

5.1 页面刷新后工具条消失

现象：刷新网盘页面，悬浮工具条没有出现，脚本像没装一样。

原因：@run-at时机太早，工具条挂载后又被页面框架的重绘逻辑清掉；或者网页脚本后加载，把用户脚本创建的DOM节点直接移除。

解决：改用document-end，并在挂载后观察节点是否存在；如果仍被移除，常见做法是用MutationObserver监听页面根节点，发现工具条消失就重新挂载一次。

5.2 提示转存成功，网盘里找不到文件

现象：日志显示200，目标目录里没有新文件，却在根目录看到了。

原因：会话中的目标目录id失效，接口静默把文件落到默认目录。脚本没有把currentDirId在日志里打印出来，整个过程就是个黑匣子。

解决：转存前强制打印一次currentDirId，确认不是空值或默认值；发现文件落错目录后，回根目录手动移动即可，代价不大。

5.3 带中文文件名或中文目录的链接转存报错

现象：只转英文文件名的链接没事，中文文件名的链接报错或返回404。

原因：正则提取到中文路径后没有做URL编码，请求直接拼中文参数，服务端拒绝解析。

解决：按参数粒度做编码，只对路径值编码，不要把整个URL一起编码。正确的做法是encodeURIComponent(item.path)，这样分隔符不会被转掉，服务端收到的才是合法参数。

5.4 批量任务切到其他标签页再回来，全部pending

现象：开着批量转存，切到另一个标签页处理事情，回来发现任务全部停在等待中。

原因：用户脚本的生命周期跟着页面走，页面被浏览器挂起后，定时器和请求循环都不再执行。

解决：把队列状态持久化到localStorage，切换回来时对比pending列表，自动恢复执行。脚本在每次状态变更时都写一次快照，刷新也不会丢进度。

5.5 提取码带全角冒号导致鉴权失败

现象：从聊天软件复制提取码，链接本身没问题，脚本一直报“提取码错误”。

原因：复制内容里混入了全角冒号、全角空格或不可见字符，正则匹配在提取码上落空。

解决：解析前统一做trim()，再把全角冒号、空格转成半角。这个是社区版最常处理的边界问题，3.9.1正是在这一步停了漏。

5.6 同一条链接转存两次，出现重复文件

现象：批量任务里两条相同链接都显示成功，网盘里出现两个同名文件。

原因：去重开关没有打开，或者去重逻辑放在解析阶段而不是转存前，导致两条独立任务都通过检查。

解决：打开配置里的“转存前查重”，按sha1 + 文件大小双重比对；如果已经产生重复，直接在网盘里按修改时间排序，删掉后创建的那一份即可。

6. 进阶技巧：把重复转存流程压成一个可控任务流

脚本能跑通只是及格线，真正效率提升来自把整个转存流程变成可暂停、可恢复、可验证的任务流。这里分享三个我在实际使用中的习惯。

第一，任务状态写入localStorage。批量任务跑一半被意外刷新，是用户类工作流最常见的翻车点，把队列和当前目录id都存下来，刷新后重新读取并合并状态：

const state = { queue: [...], currentDirId: '123456', updatedAt: Date.now() }; localStorage.setItem('trans-helper-state', JSON.stringify(state));

恢复时只取queue里status === 'pending'的任务重新入队，已经成功的不要碰。这个设计让长任务可以拆成多段执行，不用一次盯着页面。

第二，永远建一个“待整理”中转目录。我不管转存目标是哪个文件夹，都会先新建一个名为“待整理”的目录，所有批量任务默认指向它。整理完再移动到正式目录。这样可以避免批量任务里个别链接的目录结构错乱时，文件散落到网盘各处。

第三，转存后做一次抽查校验。跑完批量任务后，在脚本日志面板里核对每个文件的sha1与源列表是否一致。抽查规则很简单：每完成10个任务，取1个源文件大小非0的任务，对比网盘里同名文件的大小和sha1是否匹配。这一步能提前暴露转存过程中的丢数据问题。

最后说一句我的习惯：有一次周末批量转存600多个文件，没开去重开关，目录里同名文件堆了四层，清理花了三个小时。从那以后每次转存前都强制走一遍三件事——确认目标目录id不是根目录、打开去重开关、把任务状态持久化到本地。希望帮到你。

本文还有配套的精品资源，点击获取