Composer离线解压失败与路径配置无关，因解压使用系统临时目录（TMPDIR或/tmp），不受cache-dir、vendor-dir等Composer配置影响；真正需检查ZipArchive可用性、TMPDIR空间/权限及proc_open是否被禁用。
Composer离线解压失败，根本不是路径问题
Composer没有“解压路径”这个可配置项。它解压 ZIP 包时，只用临时目录（TMPDIR 或系统默认 /tmp），不走 cache-dir、vendor-dir 或任何 Composer 配置项。所谓“配置解压路径”，实际是绕过 PHP 原生 ZipArchive 的缺陷，换用外部工具或调优临时环境。
为什么改 cache-files-dir 不影响解压位置
cache-files-dir 只控制 ZIP 包存哪（如 /path/to/cache/files/monolog/monolog/2.10.0.0/xxx.zip），但解压动作发生在内存+临时磁盘阶段，和缓存路径完全无关。常见误解是“配了缓存就能控制解压”，结果 ZIP 文件明明在 files/ 下，却卡在 ZipArchive::extractTo(): failed to open stream。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
cache-files-dir是只读源，解压时 Composer 把它当“输入文件”读取 - 真正写入解压后代码的位置是
vendor/（或config.vendor-dir指定路径） - 中间临时解压目录由 PHP 运行时决定，Composer 不暴露该路径的配置入口
真正能干预解压行为的三个点
遇到 zlib_decode(): data error 或 extractTo(): failed to open stream，优先检查以下三项：
- 确认
ZipArchive实例化可用：php -r "new ZipArchive();"不报错，且php -r "echo ZIPARCHIVE::CHECKSUM_CRC32;"有输出 - 检查
TMPDIR是否可写、空间充足：df -h /tmp和df -i /tmp，必要时导出大分区路径：export TMPDIR="/mnt/bigdisk/tmp" && mkdir -p "$TMPDIR" && chmod 777 "$TMPDIR" - 强制启用外部解压器：
COMPOSER_UNZIP=7zip composer install（需提前装好7z或7zz），比COMPOSER_DISABLE_ZLIB=1更稳
离线场景下最易忽略的权限链
离线机常因 SELinux、容器挂载或 rootless 模式导致 /tmp 被限制写入，而错误日志里从不提 SELinux。现象是：同一命令在联网机 OK，离线机报 failed to open stream，但 ls -ld /tmp 看着权限没问题。
- 先跑
getenforce，若为Enforcing，临时切为Permissive测试是否缓解 - Docker 容器内离线运行时，确保
/tmp是rw挂载，而非ro或noexec -
proc_open被禁用会静默导致解压失败：php -i | grep disable_functions，若含proc_open，必须从php.ini中移除
