2026-05-21-00-05-04 导入进度与压缩包支持

工程分析/经验记录.md

@@ -1405,3 +1405,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 可滚动面板内的长按按钮要优先处理焦点滚动和滚动位置恢复；医学视图内的统计面板若影响主画布或菜单可达性，应外置为复核信息块。任何覆盖式资产导入都要在前端显式确认，并在后端同步生成或清理与资产强绑定的缓存，防止新旧 DICOM/STL 信息串用。
+
+## 2026-05-21-00-05-04 大文件导入不能在浏览器内 base64 化
+
+A. 具体问题
+
+用户批量导入 STL 模型时 Chrome 出现 `Render process gone / Out of Memory`，同时 DICOM 和 STL 导入缺少进度条，也不能直接上传 ZIP 等压缩包，导致大体量医学数据传输和反馈体验都不稳定。
+
+B. 产生问题原因
+
+旧导入链路会在前端对每个文件执行 `arrayBuffer -> binary string -> base64`，再把所有文件塞进一个 JSON 请求。STL 或 DICOM 文件稍大时，浏览器会同时持有原始文件、ArrayBuffer、字符串、base64 和 JSON body 多份副本，内存膨胀很快；JSON 上传也无法可靠提供上传进度。
+
+C. 解决问题方案
+
+前端改为 `XMLHttpRequest + FormData` multipart 上传，使用 `xhr.upload.onprogress` 展示上传百分比、文件数和体积，上传完成后进入“服务器正在解压与解析”状态。后端引入 `multer` 使用磁盘临时文件接收上传，并支持普通 DICOM/STL、ZIP、TAR、TAR.GZ、TGZ 和单文件 GZ；解压后只筛选当前导入类型需要的文件，写入项目级上传目录，并清理运行缓存和临时文件。
+
+D. 后续如何避免问题
+
+凡是医学影像、STL、NIfTI、压缩包等大文件导入，都不要在浏览器内转 base64 或拼接巨型 JSON；默认使用 multipart 或分片上传，并把解压、筛选、校验放在服务端。导入 UI 应区分“上传进度”和“服务器处理阶段”，避免用户误以为进度到 100% 就已经完成解析。