最稳的分卷压缩方案是调用7z命令，关键参数为-v（如-v50m），需带单位、用绝对路径、全小写文件名，Python中用subprocess传列表而非字符串，zipfile不支持原生分卷。
用 subprocess 调 7z 命令做分卷压缩，关键在 -v 参数
Windows/macOS/Linux 上最稳的分卷压缩方案，就是调 7z 命令本身。Python 不需要自己实现分块、校验、归档逻辑，7z 已经做得足够健壮。
分卷大小单位必须带后缀（b/k/m/g），比如 -v100m 表示每卷 100 MiB；不加单位会报错 Cannot set volume size。
实操建议：
- 先确保系统 PATH 中有
7z：运行7z --help能输出帮助即表示可用 - 压缩命令示例：
7z a -tzip archive.zip target_folder/ -v50m（生成archive.zip.001,archive.zip.002…） - 注意路径中含空格时，
subprocess.run的args必须拆成列表，不能拼字符串；否则 Windows 下容易因引号解析失败而报错Cannot find archive - 解压时只需指定任意一个分卷（如
archive.zip.001），7z会自动识别并加载全部卷
Python 调用 7z 解压分卷包时，常见 PermissionError 和 FileNotFoundError
不是权限问题，而是 7z 在某些环境下（尤其是 Windows + WSL 混合路径）会拒绝读取符号链接或挂载点路径，报 Cannot open file 或 Access is denied。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 统一用绝对路径，并提前用
os.path.abspath()归一化 - 避免传入
~或$HOME，7z不解析 shell 变量 - 若目标路径含中文，确保终端编码与 Python 启动环境一致（Windows 默认
gbk，但7z输出是utf-8，需显式设encoding='utf-8'） - 解压命令示例：
7z x archive.zip.001 -o./output_dir -y（-y自动确认覆盖）
不用外部工具，纯 Python 实现 zip 分卷压缩不可行
zipfile 模块不支持写入分卷 ZIP（即多文件 .zip.001/.002）。它底层依赖 zlib 流式压缩，但 ZIP 格式要求中央目录（central directory）必须位于整个归档末尾——而分卷意味着你无法预知最后一卷何时结束，也就无法回填该结构。
有人尝试用 seek() 手动补写，但在分卷场景下会破坏跨卷连续性，且 7z/WinRAR 等工具无法识别这种“伪分卷”。
替代思路（仅限小规模、可控场景）：
- 先用
shutil.make_archive(..., format='zip')打完整包，再用os.path.getsize()+shutil.copyfileobj()手动切片（只适合二进制分割，无校验、无跨卷元数据，解压时需人工合并） - 改用
tar+split组合（Linux/macOS）：tar -cf - data/ | split -b 100M - archive.tar.，但解压需cat archive.tar.* | tar -xf -，不兼容 Windows 原生工具 - 真要跨平台+自包含，不如直接打包
7z命令行二进制（如7z.exe或7zz静态版）进你的发布包
7z 分卷包在不同系统间传输时，注意文件名大小写和扩展名一致性
Linux/macOS 默认区分大小写，Windows 不区分。如果分卷文件被重命名为 .ZIP.001 / .zip.002 混用，7z 在 Linux 下可能只识别第一个卷，后续报 Cannot find volume。
关键细节：
- 所有分卷必须使用完全一致的前缀和小写扩展名（推荐全小写：
archive.zip.001,archive.zip.002） - 不要依赖 GUI 工具自动重命名——有些压缩软件会在 Windows 下生成
.001,.002，而在 macOS 下生成.001,.002但实际文件系统不报错，到 Linux 就失效 - 传输前用
ls archive.zip.* | sort（Linux/macOS）或dir archive.zip.*（Windows）确认序列连续且无断点
分卷压缩这事，核心不在 Python 写得多漂亮，而在于让 7z 命令跑得稳、路径传得准、文件名对得上。最容易被忽略的是跨系统传输后的大小写和扩展名一致性——看着都存在，就是解不开。
