zipfile默认不显示进度是因为extractall()是批量操作，内部不暴露字节流读取过程，无法挂钩进度回调；需手动遍历filelist，用open()和shutil.copyfileobj()流式解压并累加已写入字节数来实现真实字节级进度。
为什么 zipfile 默认不显示进度？
因为 zipfile.ZipFile.extractall() 是批量操作，内部直接调用 extract() 处理每个成员，不暴露读取字节流的过程，也就没法挂钩进度回调。想有进度，必须绕过 extractall()，自己遍历 ZipFile.filelist，逐个解压，并在写入目标文件时统计已写入字节数。
如何手动控制解压并实时更新进度？
核心是用 ZipFile.open() 获取压缩包内文件的类文件对象，再用 shutil.copyfileobj() 流式写入，同时监听每次 read() 的返回长度。关键点：
-
ZipFile.open(member)返回可读对象，但不支持seek()或len()，所以得提前从member.file_size获取原始大小 - 解压目标路径需用
os.path.join()拼接，避免member.filename中的../路径穿越（必须校验） - 进度计算基于当前文件已写入字节数 / 该文件总大小，不是整个 ZIP 的百分比——除非你预先算出所有
file_size总和
示例片段：
import zipfile, os, shutil
<p>def extract_with_progress(zip_path, dest_dir):
with zipfile.ZipFile(zip_path) as zf:
total_size = sum(m.file_size for m in zf.filelist)
extracted = 0
for member in zf.filelist:</p><h1>安全检查：拒绝含 ".." 的路径</h1><pre class="brush:python;toolbar:false;"> if ".." in member.filename or member.filename.startswith("/"):
continue
target_path = os.path.join(dest_dir, member.filename)
os.makedirs(os.path.dirname(target_path), exist_ok=True)
with zf.open(member) as src, open(target_path, "wb") as dst:
while True:
chunk = src.read(8192)
if not chunk:
break
dst.write(chunk)
extracted += len(chunk)
progress = extracted / total_size * 100 if total_size else 0
print(f"\r{progress:.1f}%", end="", flush=True)
tarfile 解压进度怎么加？
tarfile 比 zipfile 更麻烦：它的 TarFile.extractfile() 返回对象没有 file_size 属性，且 tarinfo.size 是唯一可靠大小来源。但注意：tarinfo 的 size 是未压缩大小，而实际读取时可能因 gzip/bz2 压缩导致流长度不可预知——所以进度只能按 tarinfo.size 算，误差在所难免。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 必须用
tarfile.open(..., "r:*")自动识别压缩格式，不能硬写"r:gz" -
tarinfo.name同样要校验，防止路径穿越；tarinfo.isreg()过滤掉目录、符号链接等非文件项 - 如果 tar 包含大量小文件，进度跳变会很剧烈，因为
size总和固定，但单个文件写入耗时差异大
进度条库（如 tqdm）能直接套用吗？
可以，但仅适用于“按文件数”进度，不是真实字节进度。例如：
from tqdm import tqdm
with zipfile.ZipFile("a.zip") as zf:
for member in tqdm(zf.filelist, desc="Extracting"):
zf.extract(member, "out/")
这种写法简单，但问题明显：
- 一个 1KB 的文本文件和一个 100MB 的视频文件，在进度条上各占 1%，体验失真
- 无法捕获写入磁盘慢于解压流的情况（比如目标盘 I/O 瓶颈）
-
tqdm不知道每个member的真实大小，所以不能切换为字节模式
真要字节级精度，就得自己流式读写+累加，没捷径。
真正难的不是代码逻辑，而是处理各种边缘情况：损坏 ZIP 头、加密文件跳过、权限写入失败后如何续传、中文路径编码……这些往往比进度本身更消耗调试时间。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
