WebUploader+PHP实现大文件分片上传与加密传输完整指南

军工科研单位里跑着的业务系统，最让人头疼的往往不是业务逻辑，而是文件上传。设计图纸、试验数据、检测报告，动不动就是几百MB甚至上G，用普通的上传组件传起来又慢又容易断，断了大不了重来，但要是传到一半网络抖一下，前端排队、后端拥塞，整个流程就卡死了。更关键的是，这类文件属于敏感文件，上传过程必须考虑加密传输，不能把明文数据直接送到服务器。我之前在一个单位内部系统里落地过基于WebUploader和PHP的分片上传方案，把分片、断点续传、加密传输整个串了起来。这篇就按我的实际落地过程，把前端配置、后端接收、加密解密以及那些容易踩的坑，一条条讲清楚。

先说结论：WebUploader解决的是“怎么把大文件稳定上传”的问题，PHP解决的是“后端怎么接收和合并分片”的问题，加密传输解决的是“数据在链路上不被偷窥”的问题。三者组合，才是敏感文件上传的完整闭环。

1. 为什么非要用“分片+加密”这套组合

1.1 大文件直传的三个现实痛点

很多人第一反应是：用普通的上传组件，把文件作为整体丢给后端不行吗？小文件当然可以，但大文件直传有三个非常现实的痛点。

第一个是网络超时。单位的网络环境普遍做了流量控制和策略限制，一个请求长时间占用连接，很容易被中间设备掐断。一旦断掉，HTTP层面拿到的往往是一个连接重置错误，前端无感知，后端的临时文件已经写了一半，整个上传只能从头再来。

第二个是服务器内存压力。PHP默认的 post_max_size 和 memory_limit 阈值都不高，即便你调到2G，处理一个超大文件时也需要在内存里构建完整的multipart请求体。多个用户同时上传，内存立刻被打爆，直接表现为进程被杀或响应极慢。

第三个是失败重试成本高。一个1.2G的文件，你传到第1.1G的时候断了，重传意味着从头再来，一次失误可能浪费半小时甚至更久。对使用单位来说，时间是不可控的。

分片上传解决的就是这三个问题：把大文件切成若干个小分片，每个分片独立上传，失败后只需要重传失败的那一片；分片并发数可控，对服务器和带宽更友好；全部上传完成后在后端合并。这才是大文件传输该有的形态。

1.2 敏感文件传输的完整信任链

敏感文件之所以叫敏感，是因为它一旦被不该看到的人看到，就可能造成不可逆的影响。这里的威胁模型不仅包括外部黑客，也包括链路监听、传输日志留存、以及非授权访问。

如果只用HTTPS，只能说“链路加密了”，但如果站点本身被人做了中间人劫持，或者你们的内部网络里有抓包工具，数据在到达服务器之前仍然存在被截获的可能。所以单靠HTTPS是不够的，还需要在应用层做一层加密：前端先把文件分片加密，再通过HTTPS通道传输，后端收到密文后解密、校验、再落盘。

我用一个生活化的比喻解释一下：HTTPS相当于你寄快递时选了保险专线，但包裹里的东西仍然是明晃晃放在纸箱里的；应用层加密相当于你自己先给文件加了一把锁，再放进纸箱。就算运输途中的任何环节出了纰漏，打开箱子的人看到也是一堆密文，没有密钥就毫无价值。对敏感文件来说，两道防线必须同时存在。

1.3 技术选型对比：WebUploader vs 其他开源组件

市面上做分片上传的组件并不少，从老牌的Plupload、jQuery-File-Upload，到体系完整的OSS/S3 SDK，各有各的适用场景。但在军工科研单位的特殊环境里，有三个硬性条件：内网或专网部署、依赖受限、不希望引入过重的云服务依赖。

WebUploader是目前国内用得最广泛的前端上传组件之一，虽然官方已经多年不维护了，但它的设计思路非常成熟：自带分片上传、并发控制、队列管理、MD5指纹计算和断点续传，API简单，对jQuery依赖也清晰。它的分片机制不需要后端配合特定协议，只要后端按约定接收 chunk 和 chunks 参数就能实现。这对自研后端、需要深度定制的场景非常友好。

对比Plupload，WebUploader的中文文档更多、社区资料更全，踩坑成本更低；对比云厂商SDK，WebUploader完全本地化部署，适合要求资源不出内网的单位。当然，它也有明显的缺点——依赖Flash（现代浏览器基本用HTML5运行，Flash插件只在极老的兼容场景才使用），官方的Demo代码有点老气，但核心功能仍然能打。我的判断是：只要是内网自研系统，WebUploader依然是性价比最高的大文件上传基础组件。

2. 整体架构与安全设计思路

2.1 系统角色与上传链路划分

整套上传系统可以简单划分成四个角色：前端上传模块、上传网关（也就是Web入口）、临时存储区、永久存储区。

前端上传模块负责把文件切成指定大小的分片，逐片计算MD5，然后按并发数限制逐一发送请求。上传网关收到分片后，先做身份鉴权、分片参数校验、类型限制校验，再决定是否接收这个分片。临时存储区存放未合并的分片，按上传会话ID独立建目录，防止不同用户、不同文件的分片互相混淆。永久存储区是合并完成之后的最终落点，通常放在另一台存储服务器或文件系统的独立目录中。

我设计的实际链路是：

code复制前端分片 -> 应用层加密 -> HTTPS传输 -> PHP接口校验鉴权 -> 临时目录收片 -> 全部收齐后解密合并 -> 完整性校验 -> 转永久存储

这里面每一环都有对应的安全职责：应用层加密保证数据即使被截获也无意义；HTTPS保证链路层的保密性；PHP接口的权限校验控制“谁可以传”；临时目录按会话隔离防止串文件；最后的完整性校验确保解密后的文件与源文件一致。少任何一环，整个链条都有明显短板。

2.2 分片大小怎么定：参数计算与取舍

分片大小不是拍脑袋定的，它受两个因素制约：前端HTTP请求的稳定性、后端的处理效率。分片太小，请求数量过多，每个请求都需要建连、鉴权、写入，开销大；分片太大，又失去了分片的意义，单个请求的失败成本重新变高。

我常用的经验值是2MB到8MB，内网环境取4MB比较均衡。计算一下：一个1.2G文件，按4MB分片就是307片左右，并发数设为3~5，单分片上传在百兆内网里不到一秒就能完成，整体上传时间基本受限于磁盘IO和网络带宽，用户体验很流畅。

如果你要算更精确的，可以参照这个公式：期望分片耗时 = 分片大小 / 期望带宽 × 8，然后让单分片耗时控制在1到2秒之间。假设内网带宽是40Mbps，期望单片耗时1秒，那么分片大小就是40Mb / 8 = 5MB，取整为4MB或者5MB都合理。

前端还会对每一个分片计算MD5，这不仅是校验用，也方便做“秒传”——如果整个文件的MD5在后端已经存在，前端可以直接跳过上传，只回传一个MD5值，服务器直接返回“文件已存在”。这个功能在重复上传同一个大文件时特别省时间。

2.3 加密方案选型：为什么用AES-256-CBC加HMAC

选加密方案的时候有一个很关键的前置条件：前端要在浏览器里完成加密。浏览器的加密能力受限于Web Crypto API或者JavaScript密码库。考虑到WebUploader的项目要兼容内网里各种繁杂的浏览器环境，以及很多单位用的还是老系统自带的内核，我用的是CryptoJS这个纯JS库，加密算法选AES-256-CBC。

有朋友可能会问：为什么不用GCM这种带身份认证的加密模式？GCM确实更安全，还能同时校验完整性，但问题在于CryptoJS原生不支持GCM，需要在纯JS里自己实现，而在军工单位这种要求代码审查、稳定优先的环境里，引入复杂的自研加密逻辑会增加不可控风险。相比之下，CBC模式链路成熟，配合独立的HMAC-SHA256做完整性校验，可以达到“加密+防篡改”的双重效果，而且每一环都有公开标准可审查。

还需要强调一点：永远不要用ECB模式。ECB模式下相同明文会得到相同密文，文件头、文件结构里的重复模式会被暴露，对敏感文件来说这是致命的弱点。CBC模式中每个分片使用随机生成的IV（初始化向量），同一个文件的不同分片IV也不同，这样相同内容的两个分片产生的密文也完全不同，才能有效防止模式分析。IV不需要保密，但必须随密文一起传给后端，后端用它来解密。

3. WebUploader前端分片上传的具体配置

3.1 引入WebUploader并初始化上传组件

WebUploader的使用方式比较固定：引入CSS和JS，然后初始化一个Uploader实例。举一个我实际用过的例子。

前端页面引入部分的示意如下：

html复制<link rel="stylesheet" href="/static/plugins/webuploader/webuploader.css" />
<script src="/static/plugins/jquery.min.js"></script>
<script src="/static/plugins/webuploader/webuploader.min.js"></script>

然后初始化Uploader：

javascript复制var uploader = WebUploader.create({
    swf: '/static/plugins/webuploader/Uploader.swf',
    server: '/api/upload/uploadChunk',
    pick: '#picker',
    accept: {
        title: '敏感文件',
        extensions: 'pdf,doc,docx,zip,rar,xls,xlsx,dwg',
        mimeTypes: 'application/pdf,application/msword,application/zip,application/x-rar-compressed,image/*'
    },
    fileVal: 'file',
    chunked: true,
    chunkSize: 4 * 1024 * 1024,
    threads: 3,
    fileNumLimit: 5,
    fileSizeLimit: 2 * 1024 * 1024 * 1024,
    duplicate: true
});

这里有几个关键点要解释。chunked: true 是开启分片，chunkSize 设置每片大小，threads: 3 控制同时上传的分片数，太大容易把带宽占满，太小则慢，3到5是内网的合理区间。fileVal 是后端接收文件的表单字段名，前后端必须一致。

server 指向分片上传接口，而合并接口可以单独设置。我建议合并动作由后端自动完成：当后端发现某个上传会话的所有分片都到齐了，自动触发合并流程。这样前端不用额外调用合并接口，逻辑更简单，合并失败后也容易通过重新上传缺失分片来恢复。

3.2 分片参数、并发控制与MD5指纹计算

WebUploader在上传每个分片时，会自动在请求里携带几个关键参数：chunk（当前分片索引，从0开始）、chunks（总分片数）、size（分片大小）、name（原文件名）。这些参数在后端非常关键，一个是判断切片是否上传完整，一个是合并时的排序依据。

此外还需要给每个分片附带一个分片MD5。WebUploader自带MD5插件，也可以直接用SparkMD5来计算整个文件的MD5用于秒传。我建议两者都做：文件级MD5用来在业务层判断“这个文件我是不是之前传过”，分片级MD5用来校验单片的完整性。

给每个分片附加参数的做法，是在 beforeSend 事件里用 formData 扩展：

javascript复制uploader.on('beforeSend', function (file) {
    var chunk = file.chunk;
    var chunks = file.chunks;
    uploader.options.formData = {
        chunk: chunk,
        chunks: chunks,
        chunkMd5: file.chunkMd5s[chunk],
        fileMd5: file.md5,
        token: getToken()
    };
});

这里的 token 是身份凭证，后端用它判断用户是否有权限上传敏感文件。chunkMd5s 是预先计算好的分片哈希数组，在上传开始前就计算好，避免每片上传时临时计算导致卡顿。

3.3 断点续传与秒传的实现逻辑

WebUploader本身支持断点续传，但实现方式需要结合后端。它的做法是：上传前先检查本地是否已存在该文件的部分分片记录，如果存在，就只上传缺少的分片。

前端需要做的是监听 uploadProgress 记录进度，并把已上传分片信息保存到 localStorage，当页面刷新或网络断开后再进来时，读取记录并重新上传缺失分片：

javascript复制uploader.on('uploadProgress', function (file, percentage) {
    var cacheKey = 'upload_' + file.md5;
    var progress = JSON.parse(localStorage.getItem(cacheKey) || '{}');
    progress[file.chunk] = true;
    localStorage.setItem(cacheKey, JSON.stringify(progress));
});

后端则更简单：每个分片在上传时，如果发现临时目录中已经存在该分片（可以通过分片MD5做标识），直接返回“分片已存在”，前端跳过这一片。这样即使前端没有存储进度记录，后端也能基于已有分片跳过重复上传。两端配合才是断点续传最稳的做法。

秒传的实现逻辑是：当文件加入队列时，先计算整个文件的MD5，向后端发一个查询请求，如果后端在文件指纹库里找到了相同的MD5，直接标记这个文件为“已上传”，前端不再执行任何分片请求。

4. PHP后端接收分片与合并实现

4.1 分片接收接口的设计与校验

后端接口是整个流程的守门员。我写接口的时候，第一步绝对不是接收文件，而是校验请求是否合法。

先看一个完整的分片接收接口骨架：

php复制public function uploadChunkAction()
{
    $token = $this->request->getPost('token');
    $user  = Auth::checkToken($token);
    if (!$user) {
        return $this->json(401, '未授权');
    }

    $chunk  = (int) $this->request->getPost('chunk');
    $chunks = (int) $this->request->getPost('chunks');
    $ext    = strtolower(pathinfo($name, PATHINFO_EXTENSION));
    if (!in_array($ext, ['pdf','doc','docx','zip','rar','xls','xlsx','dwg'], true)) {
        return $this->json(400, '不允许的文件类型');
    }

    $file = $this->request->getFile('file');
    $size = $file->getSize();
    if ($size <= 0 || $size > 8 * 1024 * 1024) {
        return $this->json(400, '分片大小不合法');
    }

    $chunkMd5 = $this->request->getPost('chunkMd5');
    if (md5_file($file->getTempName()) !== $chunkMd5) {
        return $this->json(400, '分片校验失败');
    }
}

这里的校验逻辑有五个层次：身份鉴权、扩展名白名单、分片大小上限、分片索引合法性、MD5校验。每个层次都有明确目的。身份鉴权防止陌生人上传文件到你的服务器；扩展名白名单防止有人上传可执行文件或PHP脚本到临时目录；分片大小上限防止超大请求拖垮接口；分片索引合法性防止异常请求把分片写到错误的位置；MD5校验确保网络传输过程中分片没有被篡改或损坏。

需要特别注意的是，敏感文件的临时目录绝对不要放在Web根目录下，而且要禁止PHP解析。最简单的方式是把分片临时目录放在web根目录之外，或者在该目录下放置一个 .htaccess 或Nginx配置，明确关闭该目录的脚本执行权限。

4.2 分片保存与会话隔离

每个上传会话必须有独立的临时目录，否则并发环境下两个用户同时上传同名文件，分片就会互相覆盖。我用的目录命名规则是：md5(用户ID + 文件MD5 + 会话时间戳)。这样一个用户上传同一个文件，在不同的会话里也会落在不同目录，互不干扰。

分片保存的逻辑代码如下：

php复制$sessionDir = UPLOAD_TEMP_DIR . '/' . $sessionKey;
if (!is_dir($sessionDir)) {
    mkdir($sessionDir, 0750, true);
}

$chunkFile = $sessionDir . '/' . sprintf('%05d', $chunk) . '.part';
$file->moveTo($chunkFile);

分片文件以“5位数字索引.part”命名，主要是方便合并时按文件名自然排序，不需要额外读分片元数据排序。PHP自身的排序函数按字符串排序时，00000到00299自然有序，合并的时候直接按文件名扫一遍就行。

保存完分片后，需要检查是否所有分片都已上传完成。一种做法是每次上传后都扫描目录，比较 .part 文件数量和 chunks 参数：

php复制$count = count(glob($sessionDir . '/*.part'));
if ($count == $chunks) {
    $this->mergeFile($sessionDir, $fileMd5, $name);
}

如果所有分片到齐，就进入合并流程。这里有一个小技巧：触发合并动作的那个请求，可以顺手向前端返回一个合并结果；其余分片请求则正常返回“分片已保存”，前端不需要感知后端何时开始合并，它只需要按部就班地把所有分片传到服务器。

4.3 合并分片时如何处理密文与校验

因为前端上传的是密文分片，所以合并流程不能直接拼接 .part 文件后重命名，得先解密、再拼接。这里给出一段可参考的合并代码：

php复制public function mergeFile($sessionDir, $fileMd5, $originalName)
{
    $parts = glob($sessionDir . '/*.part');
    sort($parts, SORT_STRING);

    $finalPath = $sessionDir . '/' . $fileMd5 . '.plain';
    $out = fopen($finalPath, 'wb');

    foreach ($parts as $part) {
        $cipherData = file_get_contents($part);
        $iv = substr($cipherData, 0, 16);
        $encrypted = substr($cipherData, 16);
        $hmac = substr($encrypted, -32);
        $encryptedBody = substr($encrypted, 0, -32);

        $computedHmac = hash_hmac('sha256', $iv . $encryptedBody, $this->secretKey);
        if (!hash_equals($computedHmac, $hmac)) {
            throw new \Exception('分片HMAC校验失败');
        }

        $plainData = openssl_decrypt($encryptedBody, 'AES-256-CBC', $this->secretKey, OPENSSL_RAW_DATA, $iv);
        if ($plainData === false) {
            throw new \Exception('分片解密失败');
        }

        fwrite($out, $plainData);
        unlink($part);
    }

    fclose($out);

    $finalMd5 = md5_file($finalPath);
    if ($finalMd5 !== $fileMd5) {
        throw new \Exception('合并后文件MD5不一致');
    }

    rename($finalPath, UPLOAD_STORE_DIR . '/' . $originalName);
}

这段逻辑里有三个容易被忽略的细节。

第一，每个分片的密文结构是 IV + 密文体 + HMAC。IV的长度固定16字节，HMAC固定32字节。解密前先把这几个部分切出来，不能直接把整个文件丢给 openssl_decrypt。

第二，HMAC计算的是 IV + 密文体，不要把HMAC自身也纳入计算范围。这样设计能让后端同时验证“这个分片确实是用我们约定的密钥生成的”以及“密文在传输过程中没有被改动过”。

第三，合并完成后还要做一次全文件MD5比对。分片校验只能证明每一片没问题，但无法防止分片顺序被打乱或合并过程中出现写入错误。全文件MD5是最后一层兜底。

4.4 临时文件清理与目录权限设防

分片上传最容易被忽视的是临时文件的清理。如果用户上传到一半放弃，或者网络断开后再也没回来，临时目录里就会残留部分分片文件。这些文件虽然是密文，但长期堆积会占据大量磁盘空间，还可能在审计时留下不必要的隐患。

我做了两层清理机制。第一层是“上传完成即清理”：合并结束后，删除临时目录。第二层是“超时清理”：写一个系统定时任务，每30分钟扫描上传临时目录，删除创建时间超过2小时但未完成合并的目录。这个超时时间可以根据文件大小和网络环境调整，但不能太短，否则一个2G大文件在慢速网络下可能传不完就被清了。

目录权限方面，临时目录设置为 0750，属主是PHP运行用户；存储目录设置为 0750，禁止其他用户读取。如果用的是Nginx，静态访问无论如何都不该指向存储目录——存储目录里的文件只能通过PHP接口带权限鉴权后下载，不能通过URL直接访问。

5. 加密传输的前后端实现细节

5.1 前端AES加密分片

加密的动作发生在分片上传之前。WebUploader在 beforeSend 事件里做了表单参数扩展后，还需要把分片内容本身替换为加密后的数据。

具体做法是用 FileReader 把当前分片的数据读成ArrayBuffer，然后交给加密函数处理：

javascript复制uploader.on('beforeSend', function(file) {
    var blob = file.source.getSource();
    var start = file.chunk * file.chunkSize;
    var end = Math.min(start + file.chunkSize, file.size);
    var partBlob = blob.slice(start, end);

    var reader = new FileReader();
    reader.onload = function(e) {
        var arrayBuffer = e.target.result;
        var encrypted = encryptChunk(arrayBuffer, file.chunk);
        // 用加密后的数据替换当前分片的默认上传数据
        uploader.options.formData = {
            encryptedData: encrypted,
            iv: encrypted.iv,
            hmac: encrypted.hmac,
            chunk: file.chunk,
            chunks: file.chunks,
            token: getToken()
        };
    };
    reader.readAsArrayBuffer(partBlob);
});

由于WebUploader默认会从 file 对象里读取原始分片并附加到请求中，如果不想改源码，一个更稳妥的方案是：直接把上传接口的请求体构造改成以 Blob 形式提交加密后的分片。前端会因为代码改动少而更稳定。下面是我整理的一个比较具体的加密函数：

javascript复制function encryptChunk(arrayBuffer, chunkIndex) {
    var iv = CryptoJS.lib.WordArray.random(16);
    var key = CryptoJS.enc.Hex.parse(config.uploadKey); // 32字节密钥

    var wordArray = CryptoJS.lib.WordArray.create(arrayBuffer);
    var encrypted = CryptoJS.AES.encrypt(wordArray, key, {
        iv: iv,
        mode: CryptoJS.mode.CBC,
        padding: CryptoJS.pad.Pkcs7
    });

    var hmac = CryptoJS.HmacSHA256(
        iv.concat(encrypted.ciphertext),
        CryptoJS.enc.Hex.parse(config.hmacKey)
    );

    return {
        iv: iv.toString(CryptoJS.enc.Hex),
        data: encrypted.ciphertext.toString(CryptoJS.enc.Hex),
        hmac: hmac.toString(CryptoJS.enc.Hex)
    };
}

前端加密最需要注意的地方是：千万不要在前端页面里写死一个全局密钥。虽然任何加密方案都假设前端代码可以被逆向，密钥最终都能被拿到，但敏感系统仍然要尽量提高攻击成本。实际工程里，我会让上传接口在鉴权通过后动态下发一个临时会话密钥，有效期和上传会话一致，过期即销毁。这样即使密钥在网络上被截获，也只影响一次上传会话，而不是所有历史文件。

5.2 密钥管理与防篡改签名

密钥管理在整个加密链路里是最难做、也最容易出问题的环节。密钥生成、分发、存储、轮换，每一步都需要认真对待。

前端拿到临时密钥的流程是这样的：上传前先调用 POST /api/upload/getUploadTicket，后端校验用户身份，生成一个随机AES-256密钥，把它加密后返回（这个加密可以用单位已有的数字证书体系来做）。前端拿到密钥后用于本会话所有分片的加密。会话结束后，后端自动销毁该密钥。

为了防篡改，每个分片都要带HMAC签名，这点上面已经提过。签名用的密钥和加密用的密钥可以做区分——加密密钥负责保护数据机密性，HMAC密钥负责保护数据完整性。两个密钥分离的好处是，如果某把密钥意外泄露，攻击者只能解密数据，却无法伪装新的有效分片；反之，拿到了HMAC密钥，也只能篡改数据，却解不开数据。

后端侧的解密函数，对应前端的加密格式：

php复制$iv = hex2bin($ivHex);
$cipherBody = hex2bin($dataHex);
$hmac = hex2bin($hmacHex);

$check = hash_hmac('sha256', $ivHex . $dataHex, $this->hmacKey);
if (!hash_equals($check, $hmacHex)) {
    throw new \Exception('签名校验失败');
}

$plain = openssl_decrypt($cipherBody, 'AES-256-CBC', $this->sessionKey, OPENSSL_RAW_DATA, $iv);

这里我特意用 hash_equals 而不是 == 来比较HMAC，就是为了防止时序攻击——普通字符串比较在发现第一个差异字符时就会返回，攻击者可以通过响应时间逐字节猜出正确的签名。这在敏感系统里不是强迫症，而是必须做的安全加固。

5.3 文件类型与内容的双重复核

上传接口按扩展名白名单过滤，只是最基础的一道门槛。敏感系统里，文件内容本身也要做复核。因为扩展名是可以随便改的，攻击者完全可以把一个可执行文件改名为 .pdf 后上传。

我的做法是：合并解密完成后，用PHP的 finfo 扩展读取文件的真实MIME类型，再和扩展名比对：

php复制$finfo = new \finfo(FILEINFO_MIME_TYPE);
$realMime = $finfo->file($finalPath);
$allowedMimes = [
    'pdf' => 'application/pdf',
    'doc' => 'application/msword',
    'xls' => 'application/vnd.ms-excel',
    'zip' => 'application/zip',
];

如果真实MIME类型不在允许列表内，直接拒绝入库。这一步能拦住绝大多数伪造扩展名的情况。当然，对于加密的压缩包，MIME识别可能返回 application/octet-stream，这时候可以和扩展名做兼容判定：如果扩展名是 .zip 而真实类型是 application/zip 或者 application/octet-stream，可以放行；如果扩展名是 .pdf 而真实类型是 application/x-php，无论如何都要拒绝。

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

6.1 分片上传成功但合并后文件损坏

这个问题的出现频率相当高，排查方向集中在三个方面。

第一，合并时的排序问题。如果分片文件名的索引没有补零，比如 1.part、2.part、10.part，按字符串排序就会变成 1.part、10.part、2.part，合并出来的文件必然损坏。解决办法是用 sprintf('%05d', $chunk) 格式命名分片，或者合并时用自然排序算法。

第二，分片数据被重复写入或漏写。有些后端的合并逻辑是用追加模式 fopen($final, 'ab') 写入的，如果并发请求里有两个请求同时触发了合并动作，就会导致重复追加。解决办法是在合并前加一个状态锁——用 flock 或者数据库锁标记该会话已合并，后续请求直接跳过。

第三，密文拼接时字节错位。前端的加密输出如果是以十六进制字符串提交给后端的，后端拿到后的转换方式必须一致。如果一端按hex解码，另一端按base64解码，解密自然会失败。

6.2 解密失败或解密后乱码

解密失败最常见的三个原因：IV不一致、密钥不一致、密文字节被截断。

IV不一致有时候很隐蔽。前端把IV转成了16字节十六进制字符串，也就是32个字符，后端用 hex2bin 转回来是16字节。如果某一步用 substr 切割字符串时，把IV字符串截错了长度，后端解密时OpenSSL就会报错或者输出乱码。

密钥不一致则更常见，尤其是会话密钥动态下发时，前端拿到密钥后如果做了字符串处理，比如去掉了换行符、误加了空格，解密就一定会失败。我在实践中要求前端对密钥做一次明文输出校验，后端也记录解密失败的会话日志——方便快速定位是哪个环节出的问题。

还有一种情况是加密时用 Pkcs7 填充，解密时OpenSSL却用了 OPENSSL_ZERO_PADDING，两边对齐不上的时候解密结果末尾会多出一堆无意义的零字节。

6.3 并发分片乱序导致合并失败

理论上每个分片都有独立索引，合并时按索引排好顺序就不会乱。但实际中还是会出现问题：比如某个分片在传输过程中丢失了，而后端只检查分片“数量对得上”就启动合并，结果丢的那一片参数里没收到，数量自然少了一个。所以不能只看数量，需要逐个检查缺失的索引：

php复制$expected = range(0, $chunks - 1);
$actual = [];
foreach (glob($sessionDir . '/*.part') as $part) {
    $actual[] = (int) basename($part, '.part');
}
$missing = array_diff($expected, $actual);
if (!empty($missing)) {
    // 告知前端缺失哪些分片，重新补齐
}

这个检查会更严谨。前端收到缺失列表后，只上传这几个分片，而不是全量重传。

6.4 浏览器内存溢出与上传卡顿

上传大文件时，如果前端一次性把整个文件读进内存来计算MD5，或者 FileReader 读取分片时没有及时释放引用，就会导致浏览器内存溢出，页面变得卡顿甚至崩溃。

我的经验是：MD5计算不要在前端用 FileReader 读整个文件，用增量读法，分块读入再逐块更新哈希，避免把整个文件同时装进内存。SparkMD5提供了增量接口，一次读2MB，循环到读完，内存占用非常稳定。

分片加密也是一样的道理，每次只对当前分片做 slice 和加密操作，不要在内存里持有全部分片的加密结果。加密完成的密文分片一旦提交给上传组件，就立即释放引用。

6.5 权限与鉴权的两个容易遗漏的点

最后提两个在敏感系统里特别容易遗漏的权限点。

第一个是目录遍历漏洞。如果合并后的文件命名直接使用用户上传的原始文件名，那么用户可以通过文件名里的路径分隔符，把文件写到临时目录之外。解决方法是：文件入库时统一重新命名，文件名用UUID加后缀，原始文件名存数据库，业务下载时才做映射。

第二个是下载端的鉴权。上传做了层层防护，下载时如果只靠一个静态URL，很多人就能直接通过链接读取文件。敏感文件的下载必须走一个单独的接口，先校验登录态和访问权限，再由后端读文件流返回。即使URL被泄露，没有登录态也是废纸一张。

最后再分享一个我自己的体会：军工科研单位这类环境里，安全不是做完一次性配置就完事的，而是要能自证、能审计。上传的每一个分片、每一次合并、每一把密钥的声明周期，都要有日志可查、有数字可核。这套方案落地之后，我最大的感受是：分片和加密本身并不难，难的是把所有细小的环节都照顾到——分片索引对齐、密钥生命周期、临时文件清理、签名校验、目录权限。任何一个环节偷懒，整个安全链条都会从那里断掉。希望这篇记录能给正在做同类系统的你一些参考，少走几步弯路。