业务人员一次上传几十份文档，ZIP 可以减少传输操作，却也把文件命名、目录结构和资源消耗一并带进服务端。本文讨论接收外部 ZIP 的数据接入流程，以 Python 3.14 文档说明库行为，工程建议需在实际运行时与文件系统中验证。没有在本文中运行安全实验，也不将方案描述为壹典现有产品功能。
把压缩包看作一批待验收输入
导入流程至少有五个状态：收到原包、清单通过、成员读取完成、内容检查通过、批次可供下游使用。HTTP 上传成功只对应第一步。若在解压第一份文件后就触发索引，后续失败会使知识库或训练数据集看到半个批次，造成难以追溯的缺项。
为原包生成稳定批次标识，记录来源、接收时间、原包摘要值、处理规则和运行时版本。保留受控原包用于复核，同时给暂存区设置生命周期。摘要值可以关联同一输入，但若没有可信来源提供的对照，它本身不能证明文件真实或可信。
先明确允许的格式与业务需求。只需要若干 CSV 的流程，没有必要接受任意可执行文件、加密包或无限嵌套包。无法解密、算法不支持或格式不完整，应进入明确失败状态，而非把未处理成员当作空文件继续。
优先让包内名称退出物理存储路径
路径越界发生在外部名称被解释为受限目录之外的地址；CWE-22 同时覆盖相对路径和绝对路径问题。[2] 防线不应只是删除某个危险片段。本文建议：若业务不需要还原目录，就为每个成员分配服务端生成的存储编号，将原名称保存在清单中，供展示和追溯使用。
例如包内的 reports/nov.csv 可以映射到批次下的成员 0007，清单保留原名称、成员序号、实际字节数及内容摘要。后续解析器按清单取文件，不从原名称重新拼接路径。原名展示还需按界面上下文安全转义，不能因没有参与落盘就当作可信文字。
若确需保留目录层级，应定义允许的相对路径语法、最大深度和组件长度，并按目标平台检查绝对路径、上级目录组件、驱动器或网络路径、分隔符及保留名称。判断目录归属要依据路径组件，不用字符串前缀；名称以某目录文字开头，不等于它属于该目录。
解析与检查之后，写入过程仍需防止符号链接或并发替换把目标指向其他位置。使用由服务端新建、仅工作进程可写的独立目录，不恢复链接、设备等非普通成员；需要目录保真时采用相应平台的安全文件创建机制并测试竞争条件。静态路径检查不能替代写入时的隔离。
Python 文档区分 ZipFile.extract/extractall 与 zipfile.Path 的名称处理；后者不自动清理包内文件名，需要调用方负责验证。[1] 不能因为某个提取接口有保护，就假定自己用 Path 或读取流后手动写盘也继承了同一保护。
重复名称不能靠最后一次写入解决
同一个包可能包含重复名称，也可能包含在目标环境下被视为相同的名称。不要先按名称建字典再检查重复，那会提前丢掉成员。保留目录条目的顺序和独立身份，明确是整批拒绝还是进入人工处置；不让最后一个条目悄悄覆盖前一个。
Unicode 规范化与标识符碰撞讨论了字符变换为何会折叠差异。文件导入还应检查大小写、尾部字符、路径转换以及目标存储的比较规则。不同平台的相等语义可能不同，因此不能只在开发电脑上证明两个名字不同。
使用生成编号存储可以避免物理覆盖，但业务歧义仍需解决：两个同名销售表究竟是修订版、不同门店还是重复上传？若清单无法说明，不能擅自选择一份作为正式数据。将物理安全与业务选版分开，才不会把“都存下来了”当成导入正确。
展开预算要同时约束字节、数量和执行时间
CWE-409 描述高压缩输入导致资源放大的问题。[3] OWASP 的文件上传建议也要求考虑解压后的大小，而非只限制上传体积。[4] 由此不能推出一个适用于所有企业的压缩比阈值。重复文本天然可高度压缩，低压缩比的大文件同样可能耗尽容量。
清单预检可利用声明的未压缩长度、成员数和压缩方法提前拒绝明显超限输入，但这些是输入元数据，不能代替执行期预算。应在有限大小的读取块中累计实际输出，分别限制单成员字节、全批字节、条目数量、目录深度与嵌套层数；写出下一块前确认预算尚可容纳。
在工作进程外另设内存、CPU、墙钟时间和磁盘配额。即使没有输出很多字节，解析或解压仍可能消耗资源；仅靠读取循环中的计数无法涵盖目录解析及单次库调用。清单枚举本身也要在受限工作进程内完成，并控制排队与并发，避免多批分别合格却共同挤满磁盘。
构造一份试点预算：最多一百个成员、单文件二十 MiB、总展开二百 MiB、不自动展开内层压缩包。它只是业务选择示例，不是行业安全标准。若前九份各二十 MiB，第十份实际输出超过剩余二十 MiB，应停止、标记整批失败并清理未发布输出，而不是截断成一个貌似正常的文件。
若业务必须展开嵌套包，所有层共享同一根批次预算，并额外限制深度与累计处理次数。不能每进入一层重新领取完整额度。还应把后续 PDF、图片或表格解析的资源预算单独纳入流程；解压完成并不保证内容解析低成本。
流式读取、隔离检查和成套发布
建议的实现顺序是：保存原包并登记批次；在受限进程内枚举全部成员；检查格式、数量、名称映射和冲突；逐成员有限块读取到新建暂存文件；确认完整读取及库校验结果；运行获准的内容检查；写出最终清单；最后将整个批次标记为可用。任何一步失败，都不发布部分成员。
Python zipfile 文档说明格式、密码、CRC、压缩方法和资源限制都可能造成读取失败。[1] 校验未完成时，不因已写出部分字节就报告成功。CRC 等完整性检查不能证明内容无恶意；文件类型识别、恶意内容检查与业务字段校验各有独立职责。
OWASP 建议隔离上传存储并采用必要的权限限制。[4] 在本文的接入设计中，暂存区不作为网站静态目录，不授予执行权限，工作进程仅具备当前批次所需读写能力。杀毒或内容检查超时、不可用时，应记录未完成状态，不能自动换成通过。
成套发布可以采用版本目录加受控清单指针：只有状态为已通过且清单完整的批次才被下游读取。原子重命名是否可用取决于存储和文件系统，不应把本机同文件系统的行为套到对象存储或跨卷操作。对象存储可用独立完成记录作为可见性门槛，并校验它引用的全部对象。
用反例证明拒绝、清理和恢复都有效
验收至少覆盖普通小包、空包、恰好达到预算、超出一个读取块、重复名称、目标平台名称碰撞、越界名称、不支持算法、损坏成员和不允许的嵌套内容。每个用例事先写出预期状态。空包是否允许由业务决定，但不能被误报为包含有效数据的成功导入。
同时检查副作用：拒绝后受限目录外没有新增或改变的文件；已有正式批次未被覆盖；暂存占用得到释放；下游没有接收到半批文件；错误记录能够定位原包与失败阶段。这些断言应在隔离测试环境执行，避免用真实重要文件作为试验目标。
再模拟工作进程在中途被终止、磁盘预算耗尽、内容检查超时及完成标记写入失败。恢复时依据批次记录核查状态，未完成输出不能直接续作正式文件。可以从保留原包在新的隔离暂存区重做同一批次，但对外发布仍需幂等，避免两次完成事件触发重复入库。
最终交付应包括允许格式、成员身份策略、预算、拒绝规则、清理期限、反例结果和下游可见性约定。安全导入不是找到一个“解压成功”函数，而是确保每个成员只进入获准位置、资源不会无界扩张、失败不会变成半批正式数据。