医疗系统大文件分片上传与断点续传技术实践

1. 医疗系统大文件上传的挑战与需求

在医疗信息化系统中，大文件上传是常见的刚需场景。放射科的DICOM影像、超声科的动态视频、病理科的高清切片扫描文件，单个文件体积经常达到数百MB甚至GB级别。传统表单上传方式在面对这类需求时，往往会遇到以下典型问题：

• 连接超时：医疗机构的网络环境复杂，跨院区传输时网络延迟较高，HTTP请求在默认配置下容易因超时而中断
• 内存溢出：服务端若采用传统流式处理，大文件缓冲会导致JVM堆内存急剧增长，引发OOM崩溃
• 进度缺失：医生上传大型检查资料时无法获知实时进度，可能误判上传状态
• 断点续传：网络波动导致上传中断后，需要重新传输整个文件，浪费带宽资源

某三甲医院的PACS系统升级案例显示，在未优化前，放射科医师上传一组CT影像（平均1.2GB）的成功率仅为63%，平均需要尝试2.3次才能完成。这直接影响了临床工作效率，甚至可能导致重要检查数据的丢失。

2. 前端分片上传方案实现

2.1 前端分片策略设计

采用Blob.prototype.slice方法实现文件分片，这是浏览器原生支持的二进制分割API。对于医疗影像类文件，推荐设置分片大小为5MB，这个值经过实测验证：

javascript复制// 获取文件分片
function createFileChunks(file, chunkSize = 5 * 1024 * 1024) {
  const chunks = []
  let cur = 0
  while (cur < file.size) {
    chunks.push({
      index: cur,
      chunk: file.slice(cur, cur + chunkSize)
    })
    cur += chunkSize
  }
  return chunks
}

关键经验：分片大小需要权衡网络环境和文件特性。过小的分片会增加请求次数，过大的分片会降低断点续传效果。经过某医疗云平台实测，5MB在CT影像传输中表现最优。

2.2 并发控制与进度计算

医疗系统需要精确的上传进度反馈，采用Promise.allSettled配合并发控制：

javascript复制async function uploadChunks(chunks, maxConcurrent = 3) {
  const retryList = []
  let uploadedSize = 0
  
  // 并发控制执行
  for (let i = 0; i < chunks.length; i += maxConcurrent) {
    const batch = chunks.slice(i, i + maxConcurrent)
    await Promise.allSettled(batch.map(async ({index, chunk}) => {
      try {
        await uploadSingleChunk(chunk, index)
        uploadedSize += chunk.size
        updateProgress(uploadedSize) // 更新进度条
      } catch (e) {
        retryList.push({index, chunk})