Linux服务器上需通过Web服务上传完成事件触发解压，禁用inotifywait监听，推荐PHP/Python在move_uploaded_file或上传成功后调用unzip命令；必须加-oqj参数并使用临时目录防止路径穿越；XML解析前须校验编码与格式，用lxml容错处理；全程记录日志并清理临时文件。
上传后自动触发解压的常见实现方式
Linux 服务器上没有“天然自动解压”机制，必须靠外部事件驱动。最可靠的做法是监听文件上传完成事件，而不是轮询或依赖定时任务——因为上传可能中断、重试或分片。
典型路径是：Web 服务（如 Nginx + PHP/Python）收到 .zip 文件 → 保存到指定目录（如 /var/uploads/）→ 调用脚本解压并处理 XML。
- 不推荐用
inotifywait监听上传目录，因文件可能未写完就被触发（尤其大文件），导致unzip报错archive is corrupt - PHP 中可用
move_uploaded_file()完成后再执行shell_exec("unzip -o " . escapeshellarg($zip_path) . " -d " . escapeshellarg($extract_dir)) - Python Flask/FastAPI 中，上传成功后调用
subprocess.run(["unzip", "-o", zip_path, "-d", extract_dir])更可控
解压时必须加的参数和安全限制
unzip 默认行为有路径穿越风险：恶意 ZIP 可含 ../../etc/passwd 这类路径，直接解压会覆盖系统文件。必须用参数约束解压范围。
- 用
-j（junk paths）丢弃 ZIP 内原始路径，只解出文件名，再由脚本统一移到目标目录 - 或用
unzip -o -d /tmp/extract_$$ "$zip_path"配合临时目录 + 随机后缀，解压后检查内容再移动 - 务必加
-o覆盖同名文件，避免因旧文件残留导致 XML 解析失败 - 加
-q静默模式，防止输出干扰日志或 Web 响应
unzip -o -q -j archive.zip -d /tmp/extract_12345 # 解压后遍历 /tmp/extract_12345 下所有 .xml 文件
解析 XML 前先校验格式与编码
用户上传的 XML 常见问题：BOM 头、编码声明与实际不符（如声明 UTF-8 但含 GBK 字节）、根节点缺失、格式不规范。直接丢给 xml.etree.ElementTree 或 libxml2 会抛异常中断流程。
- 用
file -i archive.xml查真实编码，再用iconv转换（如iconv -f GBK -t UTF-8 input.xml > output.xml） - Python 中建议用
lxml.etree.parse()替代标准库，它对编码容错更强，且可捕获XMLSyntaxError - 检查是否含
<?xml声明、根元素是否唯一，可用head -n 20 archive.xml | grep "<?"快速筛查
处理完记得清理临时文件并记录错误
临时解压目录、原始 ZIP、中间 XML 文件若不清理，磁盘会很快占满；而 XML 解析失败却不留痕迹，会导致业务方以为“已处理成功”。
- 用
rm -rf /tmp/extract_*清理，不要只删 ZIP —— 解压后的 XML 可能更大 - 把每一步结果（解压是否成功、找到几个 XML、哪个 XML 解析失败、错误行号）写入日志，例如：
echo "$(date): $zip_path → 3 XML, failed on data.xml: line 42" >> /var/log/xml_processor.log - 对关键字段（如订单号、时间戳）做存在性校验，避免空值入库；XML 中
<id/>和<id></id>在某些解析器里表现不同
真正难的不是 unzip 或 parse，而是上传、解压、编码、XML 结构、业务字段这五层嵌套中的任意一层出问题，都得让下游知道“卡在哪”，而不是静默失败或报一个 ParseError: not well-formed。
