2026-05-21-00-43-44 修复ZIP STL导入反馈

工程分析/经验记录.md

@@ -1423,3 +1423,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 凡是医学影像、STL、NIfTI、压缩包等大文件导入，都不要在浏览器内转 base64 或拼接巨型 JSON；默认使用 multipart 或分片上传，并把解压、筛选、校验放在服务端。导入 UI 应区分“上传进度”和“服务器处理阶段”，避免用户误以为进度到 100% 就已经完成解析。
+
+## 2026-05-21-00-43-44 导入失败要在主操作区保留可见错误
+
+A. 具体问题
+
+用户导入 `3279-STL.zip` 后浏览器控制台出现 `422 Unprocessable Entity`，但页面主操作区没有明显反馈，用户感知为“没有反应”。后续用同一 ZIP 直接调用接口验证可成功导入 26 个 STL，说明压缩包本体可读，问题更集中在失败反馈不可见和缺少后端可追踪日志。
+
+B. 产生问题原因
+
+前端导入异常只写入左侧项目栏底部的小号 `actionMessage`，主内容区域的进度条会消失，用户视线集中在右侧模型区域时很难看到错误。后端 422 返回虽然包含 `message`，但服务端没有记录项目、导入类型和文件数量，排查需要重新手工复现。
+
+C. 解决问题方案
+
+将项目库导入状态扩展为 `uploading/processing/done/failed`，失败时在顶部进度卡保留红色错误状态、百分比和后端错误原因，不再自动消失。后端导入 catch 中增加结构化日志，记录 `projectId`、`kind`、上传文件数量和错误消息。并用用户提供的 `3279-STL.zip` 对项目 `123` 实际导入，确认项目更新为 26 个 STL。
+
+D. 后续如何避免问题
+
+所有文件导入、导出、保存这类长操作失败时，都要在主操作路径旁保留显眼错误卡，不能只写入边栏或短暂 toast。后端对 4xx/5xx 的可恢复业务错误应记录足够上下文，尤其是项目 ID、导入类型、文件数量和原始异常消息，方便从用户截图快速定位。