唯一可靠方式是遍历filelist手动解压并累加file_size计算进度，因extractall无回调且compress_size不适用于ZIP_STORED项；Java需预扫描ZipFile getSize()求和；Node.js应选unzip-stream监听entry.data事件。
Python 用 zipfile 解压时怎么拿到实时进度？
直接读取 ZipFile 的 filelist 并手动遍历每个 ZipInfo 对象，是唯一可靠的方式。因为 extractall() 是黑盒操作，不暴露流式回调接口。
- 先调用
zf.filelist获取所有文件元信息，按file_size累加算出总大小 - 再用
zf.open(name)逐个打开并写入，每写一块就更新已处理字节数 - 别依赖
getinfo().compress_size做进度分母——压缩包里可能有未压缩项（compression == ZIP_STORED），实际解压字节数远大于它 - 示例关键逻辑：
total = sum(f.file_size for f in zf.filelist)<br>for f in zf.filelist:<br> with zf.open(f) as src, open(dst_path, "wb") as dst:<br> while True:<br> chunk = src.read(8192)<br> if not chunk: break<br> dst.write(chunk)<br> processed += len(chunk)<br> print(f"{processed/total*100:.1f}%")
Java 里 ZipInputStream 为什么无法精确反馈解压进度？
根本原因：它只提供「已读取的压缩流字节」，不包含原始未压缩尺寸，而解压过程是边解边写，无法预知最终输出量。
- 常见错误是拿
ZipInputStream.available()或已读压缩字节数除以整个 ZIP 文件长度——这完全不反映真实解压进度 - 可行方案只有两种：① 先用
ZipFile（非流式）预扫描所有ZipEntry.getSize()求和；② 接受粗略估算（如按压缩包内文件数量计数，适合小文件多、大小均匀的场景） - 注意
getSize()返回 -1 表示尺寸未知（常见于 zip64 或某些打包工具），此时必须 fallback 到文件数进度或放弃精确显示
Node.js 用 adm-zip 或 unzip-stream 怎么加进度条？
adm-zip 不支持流式监听，只能走“先解压到内存 Buffer 再写盘”的路子，天然不适合大文件；unzip-stream 才是正解，靠监听 entry 事件 + stream.length。
-
unzip-stream的entry事件中，stream.length是该文件原始大小（未压缩），可安全用于进度计算 - 务必监听
stream.on("data", ...)而不是"end"——后者只在文件写完才触发，无法做实时更新 - 容易漏掉的是：ZIP 中可能含目录项（
stream.type === "Directory"），它的length是 0，需跳过，否则进度会卡住 - 简单示意：
const total = entries.reduce((s, e) => s + (e.stream.length || 0), 0);<br>extract.on("entry", entry => {<br> let loaded = 0;<br> entry.stream.on("data", chunk => {<br> loaded += chunk.length;<br> console.log(`${(loaded / entry.stream.length * 100).toFixed(1)}%`);<br> });<br>});
进度条不准的三个隐蔽根源
不是代码写错，而是 ZIP 格式本身带来的约束，多数人第一次踩都以为是自己逻辑问题。
-
file_size字段可能被故意设为 0 或 -1（尤其某些 Windows 打包工具），导致预计算总大小失败 - 加密 ZIP 文件无法提前获取明文大小，
ZipInputStream和zipfile都会在解密时才抛异常，进度条可能突然中断 - 多线程解压（如用
concurrent.futures或Promise.all）会让「已处理字节数」失去顺序性，必须加锁或改用原子计数器，否则进度跳变甚至倒退
真正难的从来不是画个进度条，而是搞清你手里的 ZIP 文件到底有没有给你留出算进度的依据。
