XML上传文件重启消失是因为Docker容器文件系统临时性，需通过volume挂载宿主机目录（如/data/xml-uploads:/app/uploads）实现持久化，并确保权限匹配、编码正确及Nginx等前置服务配置合理。
XML上传文件在容器内为何“一重启就消失”
因为默认情况下，Docker 容器的文件系统是临时的。应用接收到 multipart/form-data 提交的 XML 文件后，若直接保存到 /tmp 或 /app/uploads 这类容器内路径，容器重启或重建时数据立刻丢失——这不是代码 bug，而是 Docker 的设计机制。
必须挂载 volume 才能持久化 XML 上传目录
关键不是“能不能存”，而是“存到哪”。你需要把宿主机上的一个稳定路径（如 /data/xml-uploads）通过 volume 映射进容器，让应用明确写入该路径。否则所有上传逻辑都白搭。
- 启动容器时用
-v /data/xml-uploads:/app/uploads（Linux/macOS），Windows 用-v C:\xml-uploads:C:\app\uploads - Docker Compose 中对应配置为：
volumes: - /data/xml-uploads:/app/uploads
- 确保应用代码中保存 XML 的路径硬编码或配置为
/app/uploads，而非相对路径或./uploads - 宿主机目录需提前创建并赋权：例如
mkdir -p /data/xml-uploads && chmod 755 /data/xml-uploads，否则容器内进程可能因权限拒绝写入
docker run 启动时漏掉 --user 可能导致写入失败
很多基础镜像（如 python:3.11-slim）默认以 root 运行，但生产环境常要求降权启动。若你用 --user 1001:1001，而宿主机 /data/xml-uploads 所属用户不是 UID 1001，就会报 Permission denied。
- 检查宿主机目录权限：
ls -ld /data/xml-uploads - 方案一：修改宿主机目录属主：
sudo chown 1001:1001 /data/xml-uploads - 方案二：在容器内用
initContainer或entrypoint脚本自动修正权限（适合 Kubernetes） - 方案三：改用
named volume并在docker-compose.yml中设置driver_opts控制属主（较复杂，小规模部署不推荐）
XML 解析与存储分离：别让上传路径和解析路径混在一起
常见错误是上传完立刻用 lxml 或 xml.etree.ElementTree 读取刚存的文件，却忽略路径是否真的可读、编码是否一致。尤其当 XML 含中文或特殊声明（如 ）时，容易抛出 UnicodeDecodeError 或解析失败。
- 上传后务必用绝对路径再次打开验证：
with open('/app/uploads/test.xml', 'rb') as f: content = f.read() # 不要用 'r' 模式直接 open，先确认 encoding - 若 XML 声明含非 UTF-8 编码，需显式指定：
ET.parse('/app/uploads/test.xml', parser=ET.XMLParser(encoding='gbk')) - 上传服务（如 Nginx）若启用了
client_max_body_size限制，需同步调大，否则大 XML 直接 413 错误，根本到不了应用层
宿主机路径权限、容器用户 UID、XML 文件编码这三点，任一没对齐，上传看似成功，实际后续解析或持久化都会静默失败。
