XML上传临时文件默认存于系统临时目录（如Linux的/tmp），由框架按环境变量或容器配置决定；其清理不自动可靠，需显式删除或兜底定时清理，否则易致磁盘满、敏感信息泄露。
XML上传时的临时文件到底存哪儿
用户上传的 XML 文件在到达业务逻辑前，Web 服务器或框架通常会先写入一个临时文件（不是直接进内存），位置取决于运行环境：
– Python 的 Flask 默认用 tempfile.mkstemp()，路径由系统 TEMP 或 TMPDIR 环境变量决定，常见如 /tmp/（Linux/macOS）或 C:\Users\XXX\AppData\Local\Temp\（Windows）；
– Java 的 Spring MultipartFile 在未配置 setResolveLazily(true) 时，也会落地为临时文件，路径由 javax.servlet.context.tempdir 指定，通常是应用容器的 work/Catalina/.../temp/ 目录；
– Node.js 的 multer 默认使用 os.tmpdir()，即系统临时目录。
临时文件何时被自动清理
多数框架不会“立即删除”临时文件，而是依赖生命周期管理：
– Flask：如果用 request.files['xml'].save(...) 显式保存，原始临时文件**不会自动删**；只有调用 .close() 或请求上下文退出后，且该文件对象未被引用，才可能被 tempfile 模块在垃圾回收时清理（不可靠）；
– Spring：默认在请求结束时由 StandardServletMultipartResolver 调用 cleanupMultipart() 删除，但前提是没手动调用 transferTo() 或 getInputStream() 触发流读取；一旦你用 getBytes() 或 getInputStream()，它可能已转为内存缓冲，也可能仍保留临时文件——行为取决于 maxInMemorySize 配置；
– multer：默认启用 dest 或 storage 后，上传完成即把临时文件移走，原临时路径上的文件会被自动 unlink；但如果出错（比如磁盘满、权限不足），临时文件可能残留。
不手动清理会导致什么问题
/tmp 目录爆满是真实高频故障：
– Linux 系统常配置 systemd-tmpfiles 定期清理，但默认只清 10 天以上未访问文件，而上传失败的 XML 临时文件可能卡住数小时就阻塞后续上传；
– 有些云平台（如 AWS Elastic Beanstalk）的 /tmp 是实例级共享，多个应用共用，一个服务泄漏临时文件会影响其他服务；
– XML 文件若含敏感字段（如身份证号、密钥），残留临时文件等于明文泄露风险；
– 日志中看不到“临时文件未删”，只有 No space left on device 或 EMFILE 这类底层错误，排查成本高。
