expand-archive是powershell内置zip解压命令，支持-force和-verbose参数提升稳定性，但受限于单线程全加载机制，对>2gb大包、大量小文件或utf-8中文路径易失败，推荐改用bandizip或7-zip替代。
expand-archive 是 powershell 内置的解压命令，适用于 zip 格式，语法简洁、无需额外安装工具。但它在处理大体积压缩包（如 >2gb、含大量小文件、或路径/编码异常）时容易出错或卡死——这不是你操作不对，而是它本身设计局限所致。下面直接说清楚怎么用、哪些坑要绕开、替代方案怎么选。
一、基础用法与必须加的参数
默认写法 Expand-Archive -Path archive.zip -DestinationPath ./out 看似没问题，但对大包极不友好。务必加上这两个关键参数：
-
-Force：覆盖已存在同名文件，避免中途报错中断 -
-Verbose：实时显示解压进度（尤其对大包很重要，否则像卡住）
示例：
Expand-Archive -Path "D:\builds\app-release-v2.8.0.zip" -DestinationPath "C:\temp\unpacked" -Force -Verbose
注意：目标路径必须已存在，PowerShell 不会自动创建多层目录。如果 `C:\temp\unpacked` 不存在，先运行 mkdir -p C:\temp\unpacked。
二、大包常见失败原因及应对
- 内存溢出或无响应：`Expand-Archive` 是单线程、全加载解压，大 ZIP（尤其含上万个小文件）易耗尽内存。解决办法是改用 Bandizip 或 7-Zip 的命令行（见下文）。
- 中文文件名乱码：PowerShell 默认按系统编码（如 GBK）读 ZIP 文件名，而 GitHub 等平台打包用 UTF-8。此时 `Expand-Archive` 会直接解出乱码路径，且无法指定编码。必须换工具或预处理。
- 权限不足导致写入失败：特别是解压到 `C:\Program Files` 或受保护目录时。确保以管理员身份运行 PowerShell，或改用用户有写权限的路径（如 `~\Downloads`）。
三、真正适合大包的替代方案（推荐）
当 ZIP 超过 1GB、含中文路径、或需批量处理时，别硬扛 `Expand-Archive`。以下是更稳更快的选择：
-
Bandizip CLI（免费、支持编码切换）：
下载 Bandizip 后，把 `Bandizip.exe` 所在路径加入系统环境变量，然后执行：Bandizip x -y -cp=UTF8 "D:\large.zip" "C:\output"
其中-cp=UTF8强制按 UTF-8 解析文件名，-y自动确认覆盖。 -
7-Zip 命令行（开源、脚本友好）：
安装后调用：& 'C:\Program Files\7-Zip\7z.exe' x "D:\large.zip" -o"C:\output" -y
支持更多格式（RAR、7z、tar 等），且解压速度和稳定性明显优于 `Expand-Archive`。
四、自动化场景下的实用建议
- 不要在 CI/CD 流水线里依赖 `Expand-Archive` 处理构建产物包——它不稳定、无超时控制、错误码也不标准。换成 Bandizip 或 7-Zip，并加
try/catch和超时逻辑。 - 若必须用 PowerShell 原生命令，可先用
Get-ChildItem检查 ZIP 内容大小和文件数：[System.IO.Compression.ZipFile]::OpenRead("archive.zip").Entries.Count
如果条目数 >5000 或总大小 >1.5GB，就果断切到外部工具。
