Vue3实现加密文件夹层级与断点续传的完整方案

开头

做涉密科研数据管理平台，前端碰到最棘手的问题往往不是页面交互，而是如何在一个受控环境里处理“数据档案”的完整性和安全性。这段时间我在给某高安全等级的科研数据管理系统做前端重构，其中一块核心需求就是：实验数据以文件夹层级方式存储，每个层级可能包含大量文件，数据需要加密，而且在上传过程中断网、断电、或人为关闭浏览器后必须能续传。要求听上去并不复杂，但真正落地时，同时涉及Vue3的组合式架构、加密层次模型、文件分片、断点续传、服务端校验等多个环节，踩了不少坑，也沉淀了一套相对完整的实现思路。

这篇内容不是教科书式的理论梳理，而是实实在在的工程解决方案。我会围绕“加密文件夹层级结构”和“续传”这两个关键词，把我采用的方案、核心代码、参数计算过程、以及我被坑过的地方全部写出来。适合正在做科研数据管理、档案系统、或对数据安全传输有要求的Web平台的开发同学参考，尤其建议已经在用Vue3前端框架，但对加密和续传之间如何联动还不太清楚的朋友仔细看看。

1. 需求拆解与整体设计思路

1.1 所谓“加密层级结构”到底要解决什么问题

科研实验数据的一个特点就是“分层”，比如按实验项目分组、按批次分组、按测试时间点分组，底层才是具体的原始数据文件。结构长得像这样：

某实验项目 │ ├── 2025-Batch1 │ ├── 原始数据 │ │ ├── raw_001.dat │ │ ├── raw_002.dat │ │ └── ... │ └── 处理结果 │ ├── result_001.csv │ └── ... ├── 2025-Batch2 │ └── ... └── 配置文件 └── config.json

在普通业务系统里，这种树形结构用数据库表加parentId就能搞定。但在科研数据管理平台里，问题远不止“存下来”这么简单。首先是“加密”的粒度问题：是整个文件夹一起加密，还是每个文件夹独立加密？如果一起加密，那么下载任意子节点时，需要把整棵加密树解密，性能开销极大；如果独立加密，每个文件夹节点需要有自己的密钥，密钥又如何管理？

我这里的方案选择是“节点级独立加密 + 层级密钥派生”。每个文件夹节点有自己的密钥材料，子节点密钥由父节点密钥派生而来，这样在解密某个子路径时，只需要逐级推导密钥，不需要对整个树做解密。密钥派生采用基于HMAC的确定性派生方案，即：

子节点密钥 = HMAC-SHA256(父节点密钥, 子节点标识)

这样做的核心考虑是：既保留了“独立加密某一路径”的灵活性，又避免了把大量密钥直接存储在服务端。只要持有根节点密钥，就能按需推导出任意子节点的密钥，对于需要分级授权访问的场景也天然契合——上级密钥可以往下推导，下级无法反向推导上级。

1.2 续传方案选型：为什么最终走了“前端分片 + 服务端会话”路线

文件上传的续传，常见方案无非就几种：用现成组件库自带的上传能力、基于HTTP分块上传、或者前端自己切削分片逐片上传。一开始我也考虑过直接用成熟的开源组件，但很快发现它们多数针对普通业务场景，对“分片必须属于某个加密节点”“分片序号必须可验证”这种要求支持度几乎为零。

最终我采用了“前端分片 + 服务端上传会话”的方案。核心思路是：

• 前端把每个文件切分成固定大小的分片（chunk）
• 上传前先向后端注册一个上传会话，会话中记录文件所属节点路径、文件指纹、分片总数
• 每个分片携带会话ID和序号上传
• 服务端记录已收到的分片偏移量和完整性校验值
• 续传时，前端查询会话状态，获取已成功接收的分片列表，从缺失部分继续传

这个方案看起来简单，但有几个关键细节直接决定了成败：“文件指纹”的计算方式、“分片大小”的选取、以及“加密”和“续传”如何结合。下面每个点我都会展开，尤其加密和续传要结合这件事情，踩过的人才知道有多别扭。

1.3 为什么选用Vue3作为前端技术基础

可能有人会问，这类平台选Vue3的优势在哪里？我自己的感觉是，Vue3的组合式API非常适合管理这种“多状态、多副作用”的复杂交互。文件上传过程中，至少涉及这些状态：上传队列、每个分片的上传状态、会话状态、加密上下文、错误重试计数、用户取消操作等等。在Vue2的选项中，这些状态分散在data、methods、watch、computed里，写起来非常容易失控。但组合式API里，可以按“业务能力”做自定义组合函数：

• useFolderEncryption：负责密钥派生、文件加解密
• useUploadSession：负责上传会话注册、分片管理、续传调度
• useFileTree：负责层级文件夹结构的增删改查和状态同步

每个组合函数内部自己管理自己的状态和副作用，组件层只需要极薄的胶水代码。这套架构在开发中期就明显体现出了优势：加密模块调整算法时，上传模块完全不受影响；续传逻辑出问题时，也能快速定位到具体组合函数，而不是在一整个臃肿组件里翻找。

2. 加密方案与文件结构设计

2.1 加密算法的选择与参数确定

科研平台对加密强度有硬性要求，我在算法选型上直接排除了DES、3DES这类老算法，也暂时没有考虑国密算法在浏览器端的落地成本，最终采用了AES-256-GCM。选AES-256-GCM的原因很直接：

• 强度满足要求：256位密钥空间在当前计算能力下安全性足够
• 浏览器原生支持：Web Crypto API可以直接调用，不需要额外引入庞大的加密库
• GCM模式自带认证标签：既可以加密，又可以校验数据完整性，防止密文被篡改

参数方面，我在实际实现中做了如下固定：

• 密钥长度：256位（32字节）
• 初始向量IV：12字节，每次加密时随机生成
• 附加认证数据AAD：绑定文件所属节点的完整路径，防止密文被移动到其他路径后仍能解密
• 认证标签长度：16字节

这里有一个容易被忽视的重点：AES-GCM的IV是绝对不能重复的。同一个密钥下，如果两次加密使用了相同的IV，攻击者可以推导出密钥流，加密形同虚设。所以在设计加密上下文时，我特别加入了随机数生成逻辑，每次加密都使用密码学安全的随机源生成新的IV，并且在加密结果中携带IV供解密时使用。

2.2 文件分片与加密的叠加顺序

加密和分片到底谁先谁后，这个顺序问题我纠结了很久。理论上有两种做法：

1. 先分片，再对每个分片独立加密
2. 先整体加密，再对密文分片

第一种做法实现起来简单，每个分片独立加密解密，但也存在一个致命弱点：相同内容的分片可能出现相同密文，因为密钥和IV如果复用或规律性生成，会泄露分片之间的一致性信息。除非每个分片都严格要求随机IV，但这样会加大密钥和IV的管理复杂度。

第二种做法安全性更好，先整体加密再分片，分片在网络上传输时都是密文片段，即使攻击者截获了所有分片，也无法在不持有完整密钥的情况下还原原始数据。但问题在于，续传时要重传某个分片，必须对原始文件重新执行一次加密，成本较高。

我最终选择的是“折中方案”：先用随机文件密钥加密整个文件，然后对密文流做分片。分片时，每个分片额外计算摘要值，用于完整性校验。整个文件加密时生成的IV和文件密钥，单独存储在加密元数据里。续传某个分片时，前端持有原始文件，重新执行加密并计算目标位置的密文分片，再上传即可。

这样做，既避免了分片级加密可能泄露一致性信息的问题，又不至于让每个分片的解密都依赖单独的密钥参数。

2.3 层级结构的元数据模型

加密层级结构不只是“把文件加密了”这么简单，还需要一个清晰的数据模型来描述层级、密钥、密文之间的映射关系。这个模型直接影响后续的下载、密钥推导、权限校验。

我设计的元数据模型如下：

文件夹节点： { nodeId: string, parentId: string | null, name: string, nodeType: "folder" | "file", keyDerivationSalt: string, // 密钥派生盐值 cipherMeta: { // 如果是文件节点 iv: string, tag: string, fileKeyEncrypted: string // 用父节点密钥加密后的文件密钥 }, children: [] }

节点密钥不是直接存储的，而是可推导的。根节点密钥由用户在创建项目时通过口令生成，经过KDF（密钥派生函数）处理后在本地内存中保留。子节点密钥通过父级密钥和子节点标识派生而来。文件节点的文件密钥是随机生成的独立密钥，但会被父节点密钥加密后存进元数据。

服务端保存的只是加密后的元数据和密文分片，即使数据库泄露，没有密钥体系也无法还原出原始文件。这个模型实现了“密钥不出浏览器”的构架，服务端的存储压力和安全风险都控制在了可接受的范围。

3. 核心实现：Vue3下的加密文件夹树组件

3.1 组件职责划分与状态管理

文件树是整个交互的入口，但它的职责必须严格控制。我最初犯过一个错误：把文件树组件写成了“大而全”的控制器，既负责展示，又负责上传调度，还要处理加密逻辑。结果文件树稍微复杂一点，组件代码直接失控，任何小改动都可能引出新bug。

重构后，我把职责划分成三层：

• 展示层：文件树组件，只关注树形数据的渲染、展开/折叠、选中状态
• 业务层：文件树Store（基于Pinia），管理节点增删改查、当前选中路径、节点的密钥派生缓存
• 能力层：加密组合函数、上传组合函数、API封装

组件与Store之间通过单向数据流交互，子组件只允许提交事件，由父级组件统一处理。这样的架构带来的收益很明显：加密逻辑和树展示完全解耦，后续如果要把树组件替换成表格样式，业务层完全不用动。

3.2 文件树的递归渲染与状态同步

文件树的渲染我采用了递归组件的方式，每个节点渲染自己，然后用v-for渲染子节点列表。

组件接收的主要属性是节点对象和一个depth字段，用于控制缩进深度。在Vue3中，递归组件需要显式设置name选项，或者在script setup中通过文件名自引用。这个细节我一开始没注意，导致组件反复报“Unknown component”错误。

在递归渲染时，我特别处理了一个关键点：节点密钥的缓存策略。树的展示并不需要密钥，但用户点击节点准备上传文件时，需要快速取得该节点的解密上下文。如果将密钥派生放在渲染过程中，每次树更新都会重新执行HMAC计算，虽然不慢，但在大目录下会出现不必要的耗时。

我的做法是：在文件树Store中维护一个keyCache映射，仅在以下时机更新：

• 节点首次展开时
• 用户显式触发“刷新密钥”时
• 密钥缓存过期时

![注意] 这里有个安全层面的决策：密钥缓存放在内存中，不代表可以完全忽略泄露风险。如果平台运行在共享终端上，需要在用户离开或锁屏时主动清空密钥缓存。这点在涉密环境里尤其重要，不能图省事。

3.3 加密上下文管理：Web Crypto API的工程化封装

Web Crypto API直接使用起来比较繁琐，尤其是涉及异步调用、类型转换、字节处理时。我封装了一个useFolderEncryption组合函数，把密钥派生、文件加密、文件解密、上下文构建都统一下来。

核心代码片段如下：

import { ref } from 'vue'; const encoder = new TextEncoder(); const decoder = new TextDecoder(); export function useFolderEncryption() { const rootKey = ref(null); // CryptoKey 对象，仅存于内存 async function deriveChildKey(parentKey, nodeId) { const keyData = encoder.encode(`node:${nodeId}`); const derived = await crypto.subtle.importKey( 'raw', keyData, { name: 'HMAC' }, false, ['sign'] ); return crypto.subtle.deriveKey( { name: 'HMAC', hash: 'SHA-256', baseKey: parentKey }, derived, { name: 'AES-GCM', length: 256 }, false, ['encrypt', 'decrypt'] ); } async function encryptFile(encryptionKey, fileBuffer, aad) { const iv = crypto.getRandomValues(new Uint8Array(12)); const ciphertext = await crypto.subtle.encrypt( { name: 'AES-GCM', iv, additionalData: encoder.encode(aad) }, encryptionKey, fileBuffer ); return { ciphertext, iv }; } async function decryptFile(encryptionKey, cipherBuffer, iv, aad) { try { return await crypto.subtle.decrypt( { name: 'AES-GCM', iv, additionalData: encoder.encode(aad) }, encryptionKey, cipherBuffer ); } catch (e) { throw new Error('Decryption failed: tag mismatch or corrupted data'); } } return { rootKey, deriveChildKey, encryptFile, decryptFile }; }

这里的AAD绑定节点路径的细节很容易忽略，但它恰恰是防止“密文被移动位置”的关键。如果不绑AAD，攻击者把A节点的密文移动到B节点，B节点授权用户依然可以解密，这就越权了。绑定路径后，路径不匹配时GCM认证就会直接失败，解密直接报错。

3.4 加密后文件如何分片上传

加密后得到的是ciphertext数组，接下来要处理分片。分片大小我最后定为1MB（1048576字节），这个大小是我在真实网络环境下测试后确定的。分片太小，比如128KB，会导致请求次数过多，网络往返时间占比过高；分片太大，比如10MB，中途出错重传的成本太高。1MB在普通内网和互联网环境下都是比较均衡的选择。

分片逻辑本身不复杂：

function sliceBuffer(buffer, chunkSize = 1048576) { const chunks = []; const totalChunks = Math.ceil(buffer.byteLength / chunkSize); for (let i = 0; i < totalChunks; i++) { const start = i * chunkSize; const end = Math.min(start + chunkSize, buffer.byteLength); chunks.push({ index: i, data: buffer.slice(start, end) }); } return { chunks, totalChunks }; }

每个分片上传时的数据结构，我固定为：

{ "sessionId": "uuid-string", "chunkIndex": 0, "chunkData": "base64-encoded-ciphertext", "chunkChecksum": "sha256-base64" }

chunkChecksum的作用是在服务端验收分片时做完整性校验，防止传输中的比特翻转。服务端存储的分片如果后续解密时报错，可以先检查分片校验值，定位问题是出在哪一段传输中。

4. 断点续传系统实现

4.1 上传会话的本质：服务端如何知道“你传到哪里了”

续传的核心在于服务端能回答一个问题：“这个文件的这些分片我已经有了，你还缺哪些？”这个能力通过上传会话（Upload Session）来实现。

会话的创建发生在文件上传之前。前端需要向服务端发送一次预请求，信息包括：

• 文件所属节点路径
• 加密后文件总大小
• 分片大小
• 分片总数
• 文件内容的强哈希（这里用的是SHA-256，对密文做哈希）

服务端创建会话后返回sessionId。之后每一个分片上传请求都携带该ID，服务端根据ID找到会话，判断分片序号是否合法、是否已经存在，然后决定是存储新分片还是直接返回“重复分片”。

续传时，前端调用查询接口，比如：

GET /api/upload/session/{sessionId}

服务端返回：

{ "receivedChunks": [0, 1, 2, 5, 6], "totalChunks": 10 }

前端据此知道3号和4号分片没有收到，继续传这两个即可，不需要重新传输整个文件。这个设计也可以回答“续传的续传”问题——如果续传过程中又断了，再次查询时服务端状态已经更新，继续传缺失分片即可。

4.2 分片状态机：从pending到done的完整生命周期

上传过程中分片状态不能拍脑袋定义，必须有一套清晰的状态机。我定义的状态包括：

状态机推进的逻辑完全由前端控制。服务端返回成功才把uploading置为uploaded，如果返回校验失败则置为failed，如果网络层报错则根据当前重试次数决定是直接uploading再次尝试还是failed。

在实际代码里，我并没有用什么复杂的状态机库，Vue3的reactive加上简单的状态转移函数已经完全够用。关键是每个状态转移必须保证原子性，避免并发环境下的竞态问题。这里的“并发”不仅是不同分片之间，还包括同一个分片被用户手动重试和自动重试同时触发的情况——我通过一个uploadingSet来防止同一个分片被重复发送。

4.3 断网恢复后的续传流程

既然题目里有“续传”，“断网恢复”是最常见的触发场景。这个流程我完整走通过，并在真实测试中模拟了断网、强杀浏览器、切换网络等场景。

续传流程如下：

1. 前端从本地缓存（localStorage或Pinia持久化）中恢复未完成任务列表
2. 对每个未完成任务，调服务端查询上传会话状态
3. 比对receivedChunks和本地totalChunks，得出缺失分片列表
4. 重新读取原始文件，加密并切片，按编号上传缺失分片
5. 所有分片上传完成后，通知服务端执行“合并”操作

这里有一个需要特别注意的坑：续传时需要重新加密文件，但加密结果必须和第一次完全一致。对于AES-GCM来说，加密时随机生成IV，因此两次加密同一文件得到的密文不同。如果续传的分片是新密文的分片，服务端已存的旧密文分片和新的密文分片就不属于同一个文件——合并出来的文件根本无法解密。

这个问题的解决方案有几种，我最终采用的是“确定性密钥 + 固定IV”：文件密钥由文件内容哈希派生，IV由文件内容哈希加分片序号派生，保证同一文件每次加密生成的密文完全一致。虽然这牺牲了一点随机性（严格来说，IV重复风险是存在的，但因为文件密钥本身绑定文件内容，同内容同密钥同IV，并不带来跨文件的安全问题），却在“断点续传”场景下解决了加密结果不可复现的难点。如果完全不允许IV复用，那么唯一的办法是服务端保留第一次加密时的所有分片密文，续传只补传缺失部分，而不是重新加密后传——但这样又会增加服务端存储的复杂度和出错率。我选择前者，在实际项目里也验证得比较充分。

4.4 任务并发控制

多个文件同时上传时，如果不加控制，前端会同时发起大量并发请求，导致浏览器连接数耗尽、网络拥堵、内存飙升。我在上传模块中加入了并发控制机制，核心原理是：维护一个任务队列，同时最多允许3个文件上传任务并行。

分片级并发也做了限制：每个文件同时最多上传两个分片。这样实测下来的效果是，总吞吐量并没有明显下降，但页面稳定性提升明显，拖拽上传后页面不再出现卡顿。

并发控制的核心代码如下：

class UploadScheduler { constructor(concurrency = 3) { this.concurrency = concurrency; this.queue = []; this.running = 0; } addTask(task) { return new Promise((resolve, reject) => { this.queue.push({ task, resolve, reject }); this.next(); }); } next() { while (this.running < this.concurrency && this.queue.length > 0) { const { task, resolve, reject } = this.queue.shift(); this.running++; task() .then(resolve) .catch(reject) .finally(() => { this.running--; this.next(); }); } } }

这类调度器实现不复杂，但要注意边界情况：任务失败后不能因为reject导致队列卡死，必须通过finally把running减回去再触发下一轮。

5. 权限联动与跨端一致性校验

5.1 为什么前端加密不能替代后端权限校验

涉密科研平台中，权限控制是不可或缺的一环。前端实现了加密，并不意味着后端就不需要权限校验了——恰恰相反，前端加密主要是防止“存储侧泄露导致数据裸奔”，后端权限校验则是控制“谁能访问”。

我的实现中，前端每次上传前都会携带一个短期令牌（token），该令牌通过平台认证接口获取，并且绑定用户角色和可访问节点范围。服务端在接收分片时会校验令牌对应的权限是否覆盖该节点路径，不满足就直接拒绝。

令牌的有效期我设置为30分钟，有效的上传任务会定期续期。这样一个设计在涉密环境的最大好处是：即使令牌被截获，攻击者的利用窗口也有限；即使上传任务跨度很长，也不会因为令牌过期导致整个任务失败。

5.2 完整性校验的“双重保险”

分片上传时，每个分片需要通过chunkChecksum校验；整个文件上传完成后，还需要对合并后的密文文件再做一次整体哈希校验。这个整体哈希值在会话创建时就传给了服务端。

合并时，服务端计算所有分片拼接后的哈希，和会话中保存的overallChecksum比较，一致才标记为“上传完成”。不一致则说明有分片数据篡改、错序或丢失，任务会被标记为“失败”，前端需要从缺失分片开始重新续传。

这个“双重校验”机制帮我抓到了不少隐蔽的问题，比如某些分片在网络传输中被缓存设备截留并替换，个别分片在服务端写入时出现偏移错位等。这些问题如果只靠单层校验，很可能在解密阶段才会暴露，定位成本会高得多。

5.3 前端与后端跨设备的续传一致性

关于“续传”，还有一个容易踩坑的场景：用户在家里电脑上传了文件的一部分，到单位想继续传。这时候，单纯靠浏览器本地的状态缓存已经不够了，因为另一台设备上并没有断点状态。

我的方案是：上传会话完全以服务端状态为准，前端本地缓存仅仅是减少一次查询的优化手段。跨设备续传的操作流程是：

1. 用户登录平台，进入“未完成任务”列表
2. 前端从服务端拉取该用户所有未完成会话
3. 用户在本地选择对应文件，前端比对本地文件哈希与会话中记录的文件哈希
4. 哈希一致则继续上传缺失分片；不一致则提示“文件已修改，请重新上传”

文件哈希的计算对象不是原始文件，而是加密后的密文。我这里是先加密后算哈希，这样进一步保证了密文的一致性。但这样一来，每台设备上的加密流程必须完全复现，也就是我在前面提到的“确定性加密”方案的由来。如果第一次上传用的是随机IV加密，那么在另一台设备上即使原始文件完全相同，密文哈希也不一致，跨设备续传根本不可能实现。

5.4 会话数据的生命周期管理

上传会占用服务端存储资源，不可能永远保留。我设置的会话数据生命周期为7天，7天之后未完成的会话自动清理。但清理前需要通知前端“会话已过期”，否则用户可能还在本地傻等，而服务端已经把所有分片删了。

清理机制实现起来不复杂：服务端定时任务扫描历史会话，超过7天未合并的会做删除，同时更新状态为“expired”。前端查询会话状态时，如果发现返回expired，会引导用户重新创建会话并重新上传全部内容。

还有一个细节：用户主动放弃上传时，应该提供一个“取消并清理”按钮，主动通知服务端删除会话，而不是任由数据在服务端存7天。这个流程在涉密环境里属于存储管理规范的一部分，从“数据最小化留存”的角度看也是必要的。

6. 常见问题与排查技巧实录

6.1 解密报错：GCM认证失败

问题表现：上传完成后下载文件，前端解密时报“Decryption failed: tag mismatch or corrupted data”。

排查思路：

• 先更新文件元数据中的IV和Tag，看是否下载到的密文片段有问题
• 逐个分片校验chunkChecksum，定位是否存在传输错误的分片
• 检查AAD是否和加密时一致——最常见的原因是文件被移动到其他节点后，路径发生变化，解密时使用的新路径和加密时的路径不匹配

我的处理建议是：在文件元数据中同时保存“创建时路径”和“当前路径”，解密时优先使用创建时路径作为AAD，这样即使文件后来被移动，也不会因为没有及时更新元数据而导致解密失败。移动文件时再重新生成加密元数据，则按新路径执行一次“重加密”操作。

6.2 续传后文件无法合并

问题表现：断点续传完成后，服务端合并文件总是提示“overallChecksum mismatch”。

排查思路：

• 检查是否有分片被重复上传但内容不同。比如第一次上传的失效分片和续传的新分片不是同一个加密版本
• 检查服务端是否按分片序号正确写入存储，而不是按请求到达顺序追加

我遇到这个问题的根源就是“加密结果不可复现”导致的。第一次上传加密后的分片1，和续传时加密的分片1，内容不一致。解决方式是采用确定性加密参数（内容哈希派生密钥和IV）。如果你已经遇到了这个问题，并且服务端还保留着旧会话的分片记录，最佳策略就是废弃整个会话，重新创建、重新上传。不要去试图“修复”分片，因为加密参数不一致时，单纯补传几个分片解决不了根本问题。

6.3 上传会话过期后用户端状态未更新

问题表现：用户在当天早些时候上传了部分文件，下午续传时，前端还认为会话有效，但服务端响应报错“session expired”。

排查思路：

• 前端需要在调上传接口后统一处理错误响应，尤其是“session expired”这个业务码
• 收到该错误时，前端应主动清除本地会话缓存，并引导用户重新创建会话

我把这个情况归纳为“乐观续传失败”，处理逻辑是：当发现会话过期时，自动切换到“全量上传”流程。虽然这样会多传一些数据，但至少用户不需要手动介入，整体体验可控。

6.4 分片上传乱序导致服务端校验失败

问题表现：同一文件同时并发上传两个分片，服务端偶尔报“chunk index invalid”。

排查思路：

• 服务端不用假设分片会按顺序到达，它应该按chunkIndex写入存储
• 前端在发送两个并发分片时，不能因为一个失败而等待另一个，两份请求应当是独立的

我采用的方案是：服务端按分片序号把请求分发到对应的存储槽位，而不是追加写入。这样即使2号分片先到，1号后到，最终还是能拼出正确的文件。这个设计让我省掉了“分片排序队列”的复杂度，思路更加清晰。

7. 工程整合与部署注意事项

7.1 前端构建时的加密库处理

Web Crypto API是现代浏览器的原生能力，不需要额外打包库。但要注意，部分环境里crypto.subtle只在安全上下文（HTTPS或localhost）下可用。也就是说，如果平台部署在纯HTTP的内网环境里，浏览器会拒绝暴露crypto.subtle接口，加密功能直接不可用。

这一点在涉密科研平台的内网部署场景里很容易被踩。处理方案有两种：

• 在内网访问入口配置HTTPS证书，这对现代内网架构来说并不困难
• 使用浏览器降级方案，比如用纯JS实现的加密库替代crypto.subtle，但这会降低性能且增加安全风险

我的建议是无论如何都要走HTTPS，不只是为了crypto.subtle，也为了上传分片时的传输加密。平台整体安全等级上来了，这一项没得商量。

7.2 分片内存占用与大文件处理

科研实验数据文件往往很大，几十GB级别的也有。前端如果直接把整个文件读入内存再加密分片，浏览器极大可能崩溃。我在实现时使用了File.slice()方法按分片大小读取文件片段，加密也只针对当前片段进行，防止一次性OOM。

核心处理逻辑：

async function processFileInChunks(file, chunkSize, callback) { let offset = 0; while (offset < file.size) { const blob = file.slice(offset, offset + chunkSize); const buffer = await blob.arrayBuffer(); const processed = await callback(buffer, offset); offset += chunkSize; } }

这里要注意的是，加密时AES-GCM是对整个文件连续处理的，如果逐片加密，密文边界如何拼接？我在“确定性情加密”方案下，整体逻辑是这样处理的：

• 将文件视为字节流
• 使用AES-CTR模式（计数器模式）对文件流整体加密，计数器偏移量由分片序号决定，因此可以用来处理任意分片
• 最后再用AES-GCM对每个分片的密文做认证封装

单独用AES-GCM对整个大文件逐片加密会遇到“认证标签如何拼接”的麻烦，而AES-CTR天然适合“随机访问式”的加解密。实际工程里，我最终的核心加密模式是AES-256-CTR加AES-256-GCM的“混合模式”：CTR保证任意分片的确定性加密和可续传，GCM在接收端提供分片级完整性校验。这个架构要说清楚有一定复杂度，但它在文件大小、续传效率和安全性之间找到了平衡。如果只用GCM逐片加密，必须对每个分片单独管理密钥加IV的状态，对大规模上传来说极易出错。

7.3 服务端存储结构与合并策略

分片到达服务端时，不建议直接合并成一个大文件，而是先以分片为单位存储。每个会话的目录结构如下：

upload_sessions/{sessionId}/ ├── chunks/ │ ├── 0.chunk │ ├── 1.chunk │ └── 2.chunk ├── metadata.json └── status.lock

合并时，按序号读取所有分片，拼接写入最终文件，然后计算整体哈希，删除临时分片。这个流程简单可靠，也方便在合并前做一次“完整性和数量校验”。

合并操作本身消耗I/O和CPU，应该做成异步任务。前端在完成所有分片上传后，调“提交合并”接口，服务端立即返回“合并中”状态，前端轮询查询最终结果。如果合并失败，前端可以重新发起合并请求，不需要重新上传分片。

7.4 部署环境的网络安全策略

涉密平台的网络环境通常有较严格的安全策略，包括白名单、端口限制等。前端分片上传走的是普通HTTPS接口，一般不会被拦截，但需要注意：

• 大文件上传如果走反向代理，代理的client_max_body_size必须足够大，或者配置为按分片大小逐个放行
• 超时配置要放宽，1MB分片在网络抖动时可能超过默认的60秒代理超时
• 上传接口必须关闭缓存响应头，避免中间设备缓存分片内容

这些看似运维侧的细节，实际上会直接影响前端功能是否可用。我遇到过“分片上传偶发504”的案例，排查到最后发现就是反向代理对上传请求的超时时间太短，服务端其实还在处理，但代理已经掐断了连接。

8. 实战中的性能数据与调优记录

8.1 局域网环境下的实测数据

在某部署环境的实际测试中（千兆内网、普通工作站浏览器），我记录了以下数据：

上传过程中，加密和传输是重叠执行的，不是等全部加密完再上传，这样能显著缩短总耗时。实现上是通过异步流水线：加密完一个分片立即丢进传输队列，传输队列的消费端负责HTTP请求。

8.2 分片大小调整的实验记录

我做了三组实验，文件大小同为800MB，结果如下：

1MB是我最终的选择，它足够小，让续传的粒度足够细；又足够大，让请求次数在合理范围。如果你们的网络环境更稳定，可以考虑调大到2MB；如果经常出现弱网，建议降到512KB。

8.3 内存优化：如何避免大文件加密导致崩溃

处理2.4GB的大文件时，如果直接读取整个文件到内存，浏览器内存占用会飙升到5GB以上，直接崩溃。我的优化策略是：

• 按分片读取文件片段并加密
• 内存中不保留已加密的完整文件，只留当前分片数据
• 已上传成功的分片及时释放引用，让垃圾回收机制回收内存

在代码层面，可以显式地做“分片缓冲池限制”，比如最多保留4个分片的数据在内存中，超过上限时暂停加密、优先传输。这样处理下来，即使单个文件超过10GB，浏览器内存也能稳定控制在1GB左右。

9. 争议与取舍：为什么不用SSE或WebSocket做实时进度

有人会问，为什么不用WebSocket或SSE做上传进度推送？目前我采用的形式是“前端主动轮询+分片状态回调”，本质上对服务端压力更小。WebSocket在长连接环境下确实能提供实时状态推送，但涉密平台往往对“长连接”有额外监管要求，维护成本更高。而且续传场景下，最关键的是“一次性获取所有缺失分片列表”的能力，这用普通HTTP GET就能轻易满足，不需要保持长连接。

实时进度展示方面，我用的是分片上传成功的回调来驱动进度条更新。每个分片上传完成后，客户端本地更新进度，既简单又可靠。页面刷新后进度丢失的问题，通过从服务端查询会话状态来恢复，体验上也不差。

10. 我在实际项目中的经验总结

整个项目做下来，我对“加密层级文件夹续传”这件事的几个判断是：

第一，加密和续传并不是孤立的两件事，它们的交集在“密钥和密文的确定性问题”上。只有把“同一文件在不同时间、不同设备上加密后的密文完全一致”这个问题想透了，续传才可能顺畅。

第二，文件夹的树形结构是很好的“密钥派生组织单元”。利用树形路径来驱动密钥派生，既自然又安全。父节点持有子节点的推导能力，子节点无法向上反推，这种关系本身就是权限模型的体现。

第三，前端的工程架构必须为故障恢复做设计。不要假设网络稳定，不要假设浏览器不会被关闭。每一层都要有“状态可查询”的能力，服务端的会话模型是续传的最后防线。

第四，涉密系统里，“删干净”和“存得稳”一样重要。上传取消、会话过期、分片清理这些逻辑，虽然不直接影响用户体验，但它是安全合规的底线。我在这块投入的大量测试时间，事后证明非常值得。

如果你们也在做类似的数据管理平台，希望这篇内容能帮你们少走几步弯路。具体的代码结构属于这个项目场景，大家可以根据自身需求调整。核心记住一句话：加密、层级、续传这三个词，不是三个独立功能，而是一套统一数据治理方案中的三个切面，必须在设计之初就放在一起考虑。