基于SM4国密算法实现.NET Core大文件安全分片上传

1. 项目概述：为什么大文件上传必须考虑安全传输？

在当前的Web应用开发中，大文件上传（如视频、设计图纸、数据库备份）已经是一个常规需求。无论是企业内部的知识管理系统，还是面向用户的网盘、内容创作平台，都离不开这个功能。然而，很多开发者在实现时，往往只关注了“上传”本身——比如分片、断点续传、进度条——却忽略了“传输”过程中的安全风险。想象一下，一份未加密的、包含敏感信息的合同或源代码包，在公网传输过程中被截获，后果不堪设想。这就是为什么我们需要在.NET Core后端，为C#实现的大文件上传功能，披上一层坚固的“加密铠甲”。

SM4国密算法，正是这套铠甲的优秀材料。它是由国家密码管理局认定的商用密码算法，其安全强度与AES-128相当，但在某些特定场景和合规要求下，是国内项目的首选。将SM4加密与大文件上传结合，核心目标就是在文件离开客户端、穿越不可信的网络、到达服务器端的整个旅程中，确保其内容的机密性和完整性。这不仅仅是“为了加密而加密”，而是构建可信赖应用的基础防线。本篇文章，我将从一个有十多年经验的C#后端开发者的视角，手把手带你拆解这个需求，从设计思路到代码实现，再到生产环境中的避坑指南，让你不仅能实现功能，更能理解每一个决策背后的“为什么”。

2. 整体架构设计与核心思路拆解

面对“大文件”和“加密传输”这两个关键词，直接的想法可能是：在客户端用JavaScript加密整个文件，然后上传。但这对于大文件来说是行不通的。SM4是分组加密算法，通常用于加密数据块。对大文件进行整体加密，会消耗巨大的客户端内存，导致浏览器卡死或崩溃。因此，我们的核心思路必须是：分片加密，流式处理。

2.1 核心流程与角色分工

整个安全上传流程涉及客户端（前端）和服务器端（.NET Core）的紧密配合。一个健壮的架构应该职责清晰：

1. 客户端（前端）职责：

   • 文件分片：将用户选择的大文件（比如2GB的视频）切割成固定大小的块（例如1MB或5MB）。
   • 分片加密：对每一个分片（FileSlice）使用SM4算法进行加密。密钥是关键，需要由服务器动态生成并安全下发。
   • 元数据管理：记录文件唯一标识（如MD5或自定义UUID）、总分片数、当前分片索引、加密后的分片哈希值（用于校验）等。
   • 并发控制与上传：有序或并发地将加密后的分片数据流（ArrayBuffer/Blob）上传至服务器特定接口。
   • 进度反馈与重试：实现上传进度条，并对失败的分片进行自动重试。

2. 服务器端（.NET Core）职责：

   • 密钥管理与下发：为本次上传会话生成一个随机的SM4加密密钥（Key）和初始向量（IV），并安全地返回给客户端（通常可结合HTTPS及短期Token）。
   • 接收加密分片：提供API接口，接收客户端上传的二进制流数据。
   • 流式解密与校验：在接收到分片数据流的同时，进行SM4解密，并计算解密后数据的哈希值，与客户端传来的哈希值比对，确保传输过程未出错。
   • 分片暂存与合并：将解密后的分片以临时文件形式存储在磁盘（或对象存储）上。待所有分片上传并验证成功后，按顺序合并这些临时文件，还原出原始文件。
   • 清理与状态维护：管理上传会话状态，处理异常中断，并在最终合并后或会话过期后清理临时文件。

2.2 为什么选择“分片后加密”而非“加密后分片”？

这是一个关键设计决策。两种方案看似相似，实则差异巨大：

• 方案A（先分片，后加密）：原始文件 -> 分片 -> 对每个分片独立加密 -> 上传。
• 方案B（先加密，后分片）：原始文件 -> 整体加密 -> 将加密后的大文件分片 -> 上传。

我们强烈推荐方案A。原因如下：

1. 客户端内存友好：方案A每次只在内存中保留一个分片（如5MB）的数据进行加密，内存峰值恒定且很低。方案B需要先加密整个文件，对于1GB的文件，加密过程可能就需要占用超过1GB的连续内存，极易导致浏览器崩溃。
2. 并行化与容错：方案A中每个分片的加密、上传、校验都是独立的。一个分片上传失败，只需重传该分片，不影响其他分片。方案B如果中间某个分片丢失，可能影响整个加密文件的还原。
3. 灵活性：方案A更容易实现暂停、续传。因为每个分片的状态（是否已加密、是否已上传、是否已验证）是独立的。

注意：SM4作为分组密码，当选择方案A时，需要为每一个分片使用相同的Key，但必须使用不同的IV（或通过某种方式保证每个分片的加密上下文独立），以避免相同的明文分片产生相同的密文，降低安全性。通常可以为每个分片生成一个随机IV，并随分片数据一起上传。

2.3 技术栈选型考量

• .NET Core版本：选择LTS（长期支持）版本，如.NET 6或.NET 8。它们性能更好，API更现代，社区支持也更长久。
• SM4算法库：.NET Framework没有内置SM4支持。在.NET Core中，我们通常使用BouncyCastle或Portable.BouncyCastle库。这里选择Portable.BouncyCastle，因为它对.NET Standard/.NET Core的支持更友好。
• 前端上传库：可以使用成熟的库如axios配合自定义分片逻辑，或者使用更专业的tus-js-client（实现了tus上传协议）。为了更直观地展示原理，本文将围绕使用fetch API和File API的自定义实现来讲解。
• 存储：对于合并前的分片临时文件，存储在服务器本地磁盘是最简单的方式。但在分布式或云原生环境下，应考虑使用共享存储（如Azure Blob Storage的块存储、AWS S3）或Redis（用于小分片元数据）来保证扩展性。

3. 核心细节解析与实操要点

3.1 SM4算法在.NET中的使用要点

在C#中使用SM4，主要涉及加密模式、填充模式和IV的处理。

1. 加密模式与填充：SM4通常采用CBC（密码分组链接）模式。这种模式需要一个IV，并且安全性优于ECB模式。填充采用PKCS7Padding（在.NET中常对应PaddingMode.PKCS7），确保明文长度是分组长度的整数倍。
2. 密钥与IV长度：SM4的密钥长度固定为128位（16字节）。IV的长度与分组大小相同，也是128位（16字节）。IV必须是随机的、不可预测的，且不应重复使用。
3. 使用BouncyCastle库：你需要通过NuGet安装Portable.BouncyCastle包。核心的加密/解密器需要通过CipherUtilities.GetCipher来获取。

// 示例：使用BouncyCastle创建SM4/CBC/PKCS7加密器 using Org.BouncyCastle.Crypto; using Org.BouncyCastle.Crypto.Parameters; using Org.BouncyCastle.Security; public class Sm4Cryptor { private readonly string _algorithm = “SM4/CBC/PKCS7Padding”; public byte[] Encrypt(byte[] plainData, byte[] key, byte[] iv) { var cipher = CipherUtilities.GetCipher(_algorithm); var keyParam = new KeyParameter(key); var parameters = new ParametersWithIV(keyParam, iv); cipher.Init(true, parameters); // true for encryption return cipher.DoFinal(plainData); } public byte[] Decrypt(byte[] cipherData, byte[] key, byte[] iv) { var cipher = CipherUtilities.GetCipher(_algorithm); var keyParam = new KeyParameter(key); var parameters = new ParametersWithIV(keyParam, iv); cipher.Init(false, parameters); // false for decryption return cipher.DoFinal(cipherData); } }

实操心得：BouncyCastle的API比较底层，注意DoFinal方法会处理所有数据。对于流式加密解密，需要使用CipherStream包裹你的Stream，这在服务器端流式解密分片时非常有用，可以避免将整个分片读入内存。

3.2 大文件分片的策略与参数选择

分片大小直接影响到上传效率、服务器压力和用户体验。

• 分片大小：通常选择在1MB到10MB之间。
  • 太小（如100KB）：会导致HTTP请求数量爆炸式增长，增加网络开销和服务器连接压力。
  • 太大（如100MB）：单个请求失败的成本高，重传耗时长，且在上传过程中，浏览器需要将整个大分片数据读入内存进行加密和准备上传，可能造成卡顿。
  • 推荐值：5MB是一个很好的平衡点。它足够小，可以保证稳定的进度反馈和良好的容错性；又足够大，不会产生过多的请求数。例如，一个1GB的文件，大约需要205个请求。
• 分片命名与标识：每个分片需要唯一标识。可以采用组合键：{FileUniqueId}_{ChunkIndex}_{TotalChunks}。例如，文件ID为abc123，总分片100个，第5个分片可命名为abc123_5_100.tmp。这个标识需要在上传接口中作为参数传递。
• 最后一片的处理：最后一个分片的大小很可能小于标准分片大小。代码逻辑必须能正确处理这种情况，不能假设所有分片大小一致。

3.3 密钥的安全管理与传输

这是安全链条中最关键的一环。绝对不能将密钥硬编码在客户端。

1. 服务器生成，一次一密：为每一次文件上传会话（Session）生成一个独立的、随机的SM4密钥和IV。会话可以由一个唯一的UploadSessionId来标识。
2. 安全通道下发：密钥和IV必须通过HTTPS连接从服务器API下发到客户端。可以考虑对密钥本身再进行一次加密，例如使用基于本次会话临时生成的RSA公钥加密SM4密钥，但鉴于HTTPS已提供传输层安全，在大多数场景下，直接通过HTTPS传输已足够安全，关键是保证接口本身的身份认证（如需要有效的用户Token）。
3. 短期有效与销毁：这个上传会话和对应的密钥应该有有效期（如30分钟）。服务器端在合并文件完成后，或在会话过期后，应立即在内存中销毁密钥。切勿将密钥持久化到数据库或日志中。
4. 客户端存储：客户端在收到密钥后，应将其保存在内存变量中，用于本次上传所有分片的加密。页面刷新或关闭后，密钥自动失效。

4. 实操过程与核心环节实现

下面我们分步实现客户端和服务器端的核心代码。为了聚焦于SM4和分片上传本身，我们简化了错误处理、日志等周边代码。

4.1 服务器端（.NET Core）实现

首先，创建一个FileUploadController。

4.1.1 初始化上传会话与获取密钥

[ApiController] [Route(“api/upload”)] public class FileUploadController : ControllerBase { private static readonly ConcurrentDictionary<string, UploadSession> _sessions = new(); private readonly IWebHostEnvironment _env; public FileUploadController(IWebHostEnvironment env) { _env = env; } [HttpPost(“init")] public IActionResult InitUploadSession([FromBody] InitUploadRequest request) { // request包含 fileName, fileSize, fileHash(可选) var sessionId = Guid.NewGuid().ToString(“N”); var key = GenerateRandomBytes(16); // 128-bit SM4 Key var iv = GenerateRandomBytes(16); // 128-bit IV var session = new UploadSession { SessionId = sessionId, FileName = request.FileName, FileSize = request.FileSize, TotalChunks = (int)Math.Ceiling((double)request.FileSize / Constants.CHUNK_SIZE), Key = key, Iv = iv, // 注意：这里存储的是基础IV，实际每个分片可能需要衍生IV UploadedChunks = new ConcurrentDictionary<int, bool>(), TempFileDirectory = Path.Combine(_env.ContentRootPath, “TempUploads”, sessionId) }; Directory.CreateDirectory(session.TempFileDirectory); _sessions.TryAdd(sessionId, session); // 设置会话5分钟后过期（示例，实际应更复杂） var _ = Task.Delay(TimeSpan.FromMinutes(5)).ContinueWith(t => { _sessions.TryRemove(sessionId, out _); // 清理临时目录 try { Directory.Delete(session.TempFileDirectory, true); } catch { } }); return Ok(new InitUploadResponse { SessionId = sessionId, Key = Convert.ToBase64String(key), Iv = Convert.ToBase64String(iv), ChunkSize = Constants.CHUNK_SIZE }); } private byte[] GenerateRandomBytes(int length) { var bytes = new byte[length]; using var rng = RandomNumberGenerator.Create(); rng.GetBytes(bytes); return bytes; } } public class InitUploadRequest { public string FileName { get; set; } public long FileSize { get; set; } public string FileHash { get; set; } } public class InitUploadResponse { public string SessionId { get; set; } public string Key { get; set; } // Base64编码的密钥 public string Iv { get; set; } // Base64编码的IV public int ChunkSize { get; set; } } public class UploadSession { public string SessionId { get; set; } public string FileName { get; set; } public long FileSize { get; set; } public int TotalChunks { get; set; } public byte[] Key { get; set; } public byte[] Iv { get; set; } public ConcurrentDictionary<int, bool> UploadedChunks { get; set; } public string TempFileDirectory { get; set; } } public static class Constants { public const int CHUNK_SIZE = 5 * 1024 * 1024; // 5MB }

注意：上述代码将IV直接下发并用于所有分片，这在CBC模式下是不安全的（如果两个分片明文相同，密文也相同）。更安全的做法是为每个分片生成一个独立的IV，或者使用一个“基础IV”与分片索引进行某种运算（如异或）来衍生出每个分片唯一的IV。这里为了简化示例，使用了基础IV，生产环境请务必改进。

4.1.2 接收、解密并保存分片

这是最核心的接口，需要处理流式数据。

[HttpPost(“chunk")] [DisableRequestSizeLimit] // 允许大请求，实际生产环境应配置Kestrel/Middleware限制 public async Task<IActionResult> UploadChunk( [FromForm] string sessionId, [FromForm] int chunkIndex, [FromForm] int totalChunks, [FromForm] string chunkHash, // 客户端计算的加密后分片的哈希 IFormFile file) // 接收上传的文件流 { if (!_sessions.TryGetValue(sessionId, out var session)) return BadRequest(“Invalid or expired session.”); if (chunkIndex < 0 || chunkIndex >= session.TotalChunks) return BadRequest(“Invalid chunk index.”); // 检查分片是否已上传（实现幂等性） if (session.UploadedChunks.ContainsKey(chunkIndex)) return Ok(new { message = “Chunk already uploaded.” }); var tempChunkPath = Path.Combine(session.TempFileDirectory, $”{chunkIndex}.tmp”); try { using var inputStream = file.OpenReadStream(); // 1. 计算上传来的密文分片的哈希，与客户端传来的chunkHash比对，验证传输完整性 using var hashAlgo = SHA256.Create(); var computedHashBytes = await hashAlgo.ComputeHashAsync(inputStream); var computedHash = BitConverter.ToString(computedHashBytes).Replace(“-“, “”).ToLowerInvariant(); inputStream.Position = 0; // 重置流位置 if (!computedHash.Equals(chunkHash, StringComparison.OrdinalIgnoreCase)) { return BadRequest(“Chunk hash mismatch. Data may be corrupted during transmission.”); } // 2. 流式解密 // 为当前分片衍生一个唯一的IV (示例：IV = baseIV XOR chunkIndex的字节表示) var chunkSpecificIv = DeriveChunkIV(session.Iv, chunkIndex); using var outputFileStream = new FileStream(tempChunkPath, FileMode.Create, FileAccess.Write); // 使用BouncyCastle的CipherStream进行流式解密 var cipher = CipherUtilities.GetCipher(“SM4/CBC/PKCS7Padding”); var keyParam = new KeyParameter(session.Key); var parameters = new ParametersWithIV(keyParam, chunkSpecificIv); cipher.Init(false, parameters); // 解密模式 using var cipherStream = new CipherStream(inputStream, cipher, null); // 输入流是密文 await cipherStream.CopyToAsync(outputFileStream); // 3. 验证解密后文件的哈希（可选，但推荐） outputFileStream.Flush(); // 可以重新读取tempChunkPath计算哈希，与客户端上传前计算的原始分片哈希比对（需客户端上传该值） // 4. 标记分片上传成功 session.UploadedChunks[chunkIndex] = true; return Ok(new { message = “Chunk uploaded and decrypted successfully.” }); } catch (Exception ex) { // 清理可能已部分写入的临时文件 if (System.IO.File.Exists(tempChunkPath)) System.IO.File.Delete(tempChunkPath); // 记录日志 ex return StatusCode(500, “Internal server error during chunk processing.”); } } private byte[] DeriveChunkIV(byte[] baseIv, int chunkIndex) { // 这是一个示例衍生方法，将chunkIndex转换为字节数组并与baseIv异或 // 生产环境可能需要更复杂的方案，如使用HMAC var indexBytes = BitConverter.GetBytes(chunkIndex); // 确保indexBytes长度与IV相同（16字节） Array.Resize(ref indexBytes, 16); var derivedIv = new byte[16]; for (int i = 0; i < 16; i++) { derivedIv[i] = (byte)(baseIv[i] ^ indexBytes[i]); } return derivedIv; }

4.1.3 合并分片并完成上传

当所有分片上传成功后，客户端调用此接口触发合并。

[HttpPost(“complete")] public IActionResult CompleteUpload([FromBody] CompleteUploadRequest request) { if (!_sessions.TryGetValue(request.SessionId, out var session)) return BadRequest(“Invalid or expired session.”); // 检查是否所有分片都已上传 if (session.UploadedChunks.Count != session.TotalChunks) { return BadRequest($”Not all chunks uploaded. {session.UploadedChunks.Count}/{session.TotalChunks}“); } var finalFilePath = Path.Combine(_env.ContentRootPath, “Uploads”, session.FileName); var finalDir = Path.GetDirectoryName(finalFilePath); Directory.CreateDirectory(finalDir); try { using var finalStream = new FileStream(finalFilePath, FileMode.Create, FileAccess.Write); // 按索引顺序合并所有临时分片文件 for (int i = 0; i < session.TotalChunks; i++) { var chunkPath = Path.Combine(session.TempFileDirectory, $”{i}.tmp”); if (!System.IO.File.Exists(chunkPath)) { throw new FileNotFoundException($”Chunk {i} file missing.”); } var chunkData = System.IO.File.ReadAllBytes(chunkPath); finalStream.Write(chunkData, 0, chunkData.Length); } finalStream.Flush(); // 可选：计算最终文件的哈希，与客户端最初提供的fileHash比对 // ... // 清理：移除会话和临时目录 _sessions.TryRemove(request.SessionId, out _); Directory.Delete(session.TempFileDirectory, true); // 返回最终文件的访问路径或ID return Ok(new { filePath = finalFilePath, message = “File uploaded and merged successfully.” }); } catch (Exception ex) { // 记录日志 ex return StatusCode(500, “Error merging files.”); } }

4.2 客户端（JavaScript）实现要点

客户端使用原生JavaScript的File API和fetch API进行分片、加密和上传。

4.2.1 初始化与分片加密

首先，需要一个JavaScript的SM4加密库，例如sm-crypto。你需要通过npm安装或直接引入。

// 假设已引入 sm-crypto import { sm4 } from ‘sm-crypto’; class SecureFileUploader { constructor(file, apiBaseUrl) { this.file = file; this.apiBaseUrl = apiBaseUrl; this.chunkSize = 5 * 1024 * 1024; // 5MB，应与服务器协商 this.totalChunks = Math.ceil(file.size / this.chunkSize); this.uploadedChunks = new Set(); this.sessionInfo = null; // 用于存储sessionId, key, iv } async initUploadSession() { const response = await fetch(`${this.apiBaseUrl}/init`, { method: ‘POST’, headers: { ‘Content-Type’: ‘application/json’ }, body: JSON.stringify({ fileName: this.file.name, fileSize: this.file.size, fileHash: await this.calculateFileHash(this.file) // 可选，使用SHA-256 }) }); this.sessionInfo = await response.json(); console.log(‘Session initialized:’, this.sessionInfo); } async upload() { if (!this.sessionInfo) await this.initUploadSession(); const key = this.base64ToUint8Array(this.sessionInfo.key); const baseIv = this.base64ToUint8Array(this.sessionInfo.iv); for (let chunkIndex = 0; chunkIndex < this.totalChunks; chunkIndex++) { if (this.uploadedChunks.has(chunkIndex)) { console.log(`Chunk ${chunkIndex} already uploaded, skipping.`); continue; } const start = chunkIndex * this.chunkSize; const end = Math.min(start + this.chunkSize, this.file.size); const chunkBlob = this.file.slice(start, end); // 1. 读取分片数据为ArrayBuffer const chunkArrayBuffer = await chunkBlob.arrayBuffer(); // 2. 为当前分片衍生IV (需要与服务器端算法一致) const chunkIv = this.deriveChunkIV(baseIv, chunkIndex); // 3. 使用SM4加密分片数据 // sm-crypto的sm4.encrypt期望参数是(明文数组, 密钥数组, 模式, iv数组) // 注意：sm-crypto可能默认输出16进制字符串，我们需要字节数组 const encryptedData = sm4.encrypt( new Uint8Array(chunkArrayBuffer), key, { mode: ‘cbc’, iv: chunkIv } ); // 这里假设encrypt返回Uint8Array，具体看库文档 // 4. 计算加密后数据的哈希（用于服务器端传输校验） const encryptedHash = await this.calculateHash(new Uint8Array(encryptedData)); // 5. 创建FormData并上传 const formData = new FormData(); formData.append(‘sessionId’, this.sessionInfo.sessionId); formData.append(‘chunkIndex’, chunkIndex); formData.append(‘totalChunks’, this.totalChunks); formData.append(‘chunkHash’, encryptedHash); // 将加密后的Uint8Array转换为Blob，作为文件字段上传 const encryptedBlob = new Blob([encryptedData]); formData.append(‘file’, encryptedBlob, `chunk_${chunkIndex}`); try { const uploadResponse = await fetch(`${this.apiBaseUrl}/chunk`, { method: ‘POST’, body: formData, // 注意：不要手动设置Content-Type，FormData会自动设置multipart/form-data }); if (uploadResponse.ok) { this.uploadedChunks.add(chunkIndex); console.log(`Chunk ${chunkIndex} uploaded successfully.`); // 更新UI进度条: (this.uploadedChunks.size / this.totalChunks) * 100 } else { const errorText = await uploadResponse.text(); console.error(`Failed to upload chunk ${chunkIndex}:`, errorText); // 实现重试逻辑 } } catch (error) { console.error(`Network error uploading chunk ${chunkIndex}:`, error); // 实现重试逻辑 } } // 所有分片上传完成后，通知服务器合并 await this.completeUpload(); } async completeUpload() { const response = await fetch(`${this.apiBaseUrl}/complete`, { method: ‘POST’, headers: { ‘Content-Type’: ‘application/json’ }, body: JSON.stringify({ sessionId: this.sessionInfo.sessionId }) }); const result = await response.json(); console.log(‘Upload completed:’, result); } deriveChunkIV(baseIv, chunkIndex) { // 必须与服务器端C#的DeriveChunkIV逻辑完全一致！ const indexBytes = new Uint8Array(16); const view = new DataView(indexBytes.buffer); view.setInt32(0, chunkIndex, true); // 小端序写入chunkIndex // 其余字节保持为0（因为Array.Resize在C#端用0填充） const derivedIv = new Uint8Array(16); for (let i = 0; i < 16; i++) { derivedIv[i] = baseIv[i] ^ indexBytes[i]; } return derivedIv; } async calculateHash(data) { // 使用SHA-256计算哈希，返回16进制字符串 const hashBuffer = await crypto.subtle.digest(‘SHA-256’, data); const hashArray = Array.from(new Uint8Array(hashBuffer)); return hashArray.map(b => b.toString(16).padStart(2, ‘0’)).join(‘’); } base64ToUint8Array(base64) { const binaryString = atob(base64); const bytes = new Uint8Array(binaryString.length); for (let i = 0; i < binaryString.length; i++) { bytes[i] = binaryString.charCodeAt(i); } return bytes; } } // 使用示例 const fileInput = document.getElementById(‘fileInput’); fileInput.addEventListener(‘change’, async (e) => { const file = e.target.files[0]; if (!file) return; const uploader = new SecureFileUploader(file, ‘https://your-api.com/api/upload’); await uploader.upload(); });

关键点：客户端与服务器端的IV衍生算法deriveChunkIV必须绝对一致，否则解密会失败。这是联调时最容易出问题的地方。

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

在实际开发和上线过程中，你会遇到各种各样的问题。下面是我总结的一些典型问题及其解决方案。

5.1 加密/解密失败，数据损坏

• 症状：服务器端解密分片时抛出异常，如“Bad padding”或解密出的数据无法识别。
• 排查步骤：
  1. 检查密钥和IV的编码：确保客户端和服务端对密钥、IV的编码（Base64/Hex）和解码方式一致。一个字节错了，整个解密就全乱。
  2. 验证IV衍生算法：这是最常见的坑。在客户端和服务器端分别打印（或日志记录）前两个分片的衍生IV值，进行逐字节比对。务必保证算法在两端完全一致（包括字节序Endianness）。
  3. 检查加密模式与填充：确认两端都使用的是SM4/CBC/PKCS7Padding。BouncyCastle和sm-crypto的默认设置可能不同，必须显式指定。
  4. 核对数据流：在客户端，将加密前的分片原始数据、加密后的数据分别计算哈希并打印。在服务器端，收到数据后先计算哈希与客户端传来的chunkHash比对，确保网络传输无误。然后再进行解密。
  5. 分片边界问题：确保客户端分片时File.slice(start, end)的边界计算正确，没有重叠或遗漏。最后一个分片的大小要特殊处理。

5.2 上传性能瓶颈与内存溢出

• 症状：上传大文件时浏览器卡顿、内存占用飙升，甚至标签页崩溃。
• 解决方案：
  1. 优化分片大小：将分片大小从1MB调整到5MB或10MB，减少HTTP请求数量和内存中同时处理的数据块数。
  2. 流式加密：如果前端SM4库支持流式加密（Cipher对象可以update和final），则不要一次性将整个分片ArrayBuffer读入内存进行加密。可以分块读取Blob并加密。不过，浏览器环境下的流式API（如Streams API）配合加密库使用可能较复杂，需评估。
  3. 控制并发数：不要一次性发起所有分片的上传请求。实现一个队列，限制同时进行的上传请求数（如3-5个）。这能显著降低浏览器和服务器的瞬时压力。
  4. 使用Web Worker：将耗时的加密计算放到Web Worker线程中，避免阻塞主线程导致UI卡顿。这是处理超大文件（如数GB）上传的高级优化手段。

5.3 服务器端并发与资源管理

• 症状：多人同时上传大文件时，服务器磁盘I/O、CPU或内存吃紧，响应变慢。
• 解决方案：
  1. 异步与非阻塞I/O：确保所有文件I/O操作（读流、写文件）都是异步的（async/await），避免阻塞线程池线程。.NET Core的FileStream异步API性能很好。
  2. 限制单请求资源：在中间件或Kestrel配置中，限制单个请求的最大体量，防止恶意超大文件攻击。
  3. 分布式临时存储：不要把所有临时分片文件都放在单个服务器的本地磁盘。对于微服务或集群部署，应使用共享存储服务，如Azure Blob Storage的块Blob、AWS S3，或者使用Redis（存储小分片元数据和状态）。合并操作可以由一个后台服务或某个特定实例来完成。
  4. 及时清理：除了会话过期清理，还应有一个后台清理任务，定期扫描TempUploads目录，删除超过一定时间（如24小时）的残留临时文件夹，防止磁盘被占满。

5.4 网络不稳定与断点续传

• 需求：上传中途网络断开或用户关闭页面，再次上传时希望能从断点继续，而不是重头开始。
• 实现思路：
  1. 持久化上传状态：在客户端（如IndexedDB或LocalStorage）记录文件唯一标识（如内容哈希+文件名+大小）、总分片数、以及每个分片的上传状态（成功/失败）。在初始化上传会话时，服务器可以返回已上传成功的分片索引列表（需要服务器也持久化每个会话的上传状态到数据库或分布式缓存）。
  2. 分片哈希校验：即使服务器标记某个分片已上传，在续传时客户端也应重新计算该分片的哈希，与服务器端存储的哈希比对，确保数据一致性，避免因上次上传不完整导致文件损坏。
  3. 接口幂等性：UploadChunk接口必须实现幂等。即同一个sessionId和chunkIndex重复上传，服务器应识别并返回成功，而不是重复处理或报错。我们的代码中通过ConcurrentDictionary检查已实现基本幂等。

5.5 前端加密库的兼容性与性能

• 问题：不同的SM4 JavaScript库在API、输出格式、性能上可能有差异。
• 选型与适配建议：
  1. 优先选择活跃维护的库：如sm-crypto。仔细阅读其文档，看是否支持CBC模式和PKCS7填充，以及输入输出是ArrayBuffer、Uint8Array还是16进制字符串。
  2. 进行性能测试：在目标浏览器中，测试对一个5MB的ArrayBuffer进行加密需要多长时间。如果时间过长（如>500ms），会影响用户体验，需要考虑优化分片大小或使用Web Worker。
  3. 准备降级方案（可选）：如果加密过程成为瓶颈，且业务对安全性要求可以适当放宽，可以考虑仅对文件头尾部分关键元数据进行加密，或者采用更快的算法（如国密SM4的ECB模式，但安全性较低）。但这需要与产品和安全团队充分沟通。

5.6 生产环境部署注意事项

1. HTTPS是必须的：整个传输过程，包括获取密钥的/init接口，都必须使用HTTPS。否则，加密形同虚设，密钥在传输过程中就可能被窃取。
2. 密钥管理服务（KMS）：对于更高安全要求的场景，不应在应用服务器内存中生成和存储密钥。应该集成云服务商或自建的KMS（如Azure Key Vault, AWS KMS，或使用HashiCorp Vault），由KMS生成密钥并完成加密解密操作，应用服务器只处理密钥句柄。
3. 监控与告警：对文件上传接口的关键指标进行监控：请求量、平均耗时、失败率、解密失败次数。设置告警，当失败率突增或解密失败频繁时及时通知。
4. 文件类型与病毒扫描：解密合并后的文件，在存储或提供给下游系统前，务必进行文件类型校验（通过魔数而非仅扩展名）和病毒扫描，防止上传恶意文件。

实现一个支持SM4加密的大文件上传系统，是对开发者综合能力的考验，涉及前后端协作、密码学应用、流式处理、并发控制和资源管理。从设计上就考虑安全性、可靠性和性能，才能构建出真正健壮的服务。希望这篇超过五千字的详细拆解，能帮你避开我当年踩过的那些坑，顺利实现安全、高效的文件传输功能。如果在具体实现中遇到更棘手的问题，不妨从最基础的“数据一致性”和“算法一致性”两个角度去排查，往往能事半功倍。