技术博客
因为默认行为会访问 packagist.org（或你配置的仓库）拉取包元数据、下载 ZIP 或通过 Git 克隆，同时还会校验 composer.lock 中记录的 dist URLs 和 commit hash。只要 DNS、HTTPS 连接或证书验证任一环节断开，就会报 Could not fetch、failed to open stream 或 SSL certificate problem。
直接加 –no-scripts 参数就行。这是 Composer 唯一、明确、被文档支持的禁用脚本方式，不是 hack，也不依赖环境变量或配置项。
因为默认每次运行都是干净容器，vendor/ 和 Composer 的全局缓存（~/.composer/cache）全丢。不手动干预，composer install 就得重新下载、解压、安装所有包，动辄 2–5 分钟。
离线依赖的本质不是“完全不联网”，而是让 composer install 不依赖实时网络拉包。关键在提前把所有依赖（含递归依赖）和元数据固化下来，CI 环境只做本地还原。
它本质是个静态站点生成器，不是运行时服务。你跑一次 bin/satis build，它就扫一遍 composer.json 里写的包，拉代码、打标签、生成一堆 packages.json 和压缩包链接——然后就结束了。没有后台进程，不监听端口，也不自动更新。
只要 composer.lock 文件还在，composer install 就会严格按它还原依赖，根本不需要“回滚命令”。很多人误以为要执行什么特殊操作，其实只是没意识到锁文件才是真相。
不能。这是个常见误解：bin-compat 是 Composer 自身的内部配置项，只影响 vendor/bin/ 下可执行脚本的生成方式，和 Windows/Linux 兼容性无直接关系。它不改变 PHP 代码行为，也不解决路径分隔符、换行符或 shell 命令差异问题。
Composer 默认联网拉取包，断网时会直接失败。它本身不支持“手动扔个 zip 进去就用”，但能通过本地仓库机制绕过网络——前提是这个 zip 包得是 Composer 兼容的格式（含 composer.json，且结构正确）。
离线环境执行 composer install 报错 Your platform does not meet the minimum requirements，本质是 Composer 2.2+ 默认开启的平台约束检查在联网时会校验 PHP/扩展版本是否匹配 platform 配置，但离线时它仍会尝试验证（哪怕没网络），且不自动降级行为。
本质是默认源走国外服务器，DNS 解析慢、TCP 连接超时或中间链路丢包都会让 composer install 卡住甚至失败，不是你本地环境有问题。