没有。--prefer-offline 不是 Composer 的合法参数，官方文档和源码中均不存在；实际可用的是 Composer 2.2+ 引入的 --no-network，它彻底短路所有远程请求，仅依赖本地 composer.lock 中 file:// 或本地路径的 dist.url 及对应 ZIP 包存在。
Composer 有 --prefer-offline 吗？先说结论
没有。--prefer-offline 不是 Composer 的合法参数，官方文档和源码中均不存在。你看到的可能是混淆了 --no-network、--prefer-dist 或某些插件（如已废弃的 hirak/prestissimo）的私有 flag。弱网下真正起作用的是 --no-network，但它不重试——它直接跳过所有网络请求。
--no-network 是怎么工作的？为什么它不重试
--no-network 是 Composer 2.2+ 引入的硬性拦截开关，不是“低配联网模式”，而是彻底切断远程通道：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 它短路
RepositoryManager::fetchPackage()调用，不发任何 HTTP 请求，不查 API，不验签名，也不 fallback - 只依赖
composer.lock中每个包的dist.url字段是否为file://或本地路径，且对应 ZIP 必须已存在于~/.composer/cache/files/或vendor/ - 一旦某个包的
dist.url是https://，或缓存缺失，就直接报错Package not found in local cache，不会尝试重试、降级或换源
弱网下想“重试”，得靠 HTTP 层配置，不是 --no-network
如果你卡在 Downloading 阶段反复失败，说明问题出在网络传输层，此时该调的是重试和超时参数，而非离线模式：
- 默认重试仅 3 次，延迟从 100ms 到 500ms，对弱网远远不够：用
--retries=5或全局设composer config --global retries 5 -
http-timeout控制单次 HTTP 请求上限，默认 300 秒太短：建议项目级执行composer config http-timeout 1200 - 别忘了 PHP 底层的
default_socket_timeout——即使 Composer 设了 1200，若 PHP CLI 还是 60 秒，cURL 仍会在 60 秒断开：临时跑php -d default_socket_timeout=1200 $(which composer) install - 镜像源必须生效：运行
composer config -g repos.packagist.org确认输出是https://mirrors.aliyun.com/composer/类地址，不是packagist.org
真正容易被忽略的点
弱网下最常被绕过的不是 Composer 参数，而是缓存状态和包类型。哪怕你设了 --retries=10 和 http-timeout=1800，只要 composer.lock 里某个包的 "type": "git" 或 "source" 字段存在，Composer 就会尝试 git clone --depth=1，而 git 在弱网下根本不走重试逻辑，也不受 http-timeout 控制。此时唯一解法是确保所有包都走 --prefer-dist，并提前用国内镜像源同步过 dist 包——否则重试再多，也只是在重复失败。
