根本原因是composer默认实时拉取packagist.org元数据并校验远程sha256哈希，离线时无法访问和验证；解法是提前在有网环境生成完整vendor/和composer.lock，离线机执行composer install --no-scripts --no-plugins --no-dev跳过远程调用，仅校验本地一致性。
离线环境下 Composer install 报错 “Could not fetch packages” 怎么办
根本原因不是网络不通，而是 Composer 默认所有包都从 packagist.org 实时拉取，且会校验 dist 包的远程 SHA256 哈希值。离线时既无法访问源站，也无法验证哈希，直接卡在 Fetching package... 或报 Could not fetch https://packagist.org/p/monolog/monolog.json。
核心解法是让 Composer 完全跳过远程元数据请求，只读本地已缓存或预置的包归档（.zip 或 .tar）和本地 composer.lock 中记录的 exact commit hash / version。
- 必须提前在有网机器上完整执行过
composer install或composer update，确保vendor/和composer.lock齐全 - 将整个项目目录（含
vendor/、composer.lock、composer.json）打包复制到离线机，不要删 vendor —— 这是最常踩的坑：有人以为“重装”就得清 vendor，结果离线时composer install --no-install也跑不起来 - 离线机上运行
composer install --no-scripts --no-plugins --no-dev（若不需要 dev 依赖），它会跳过所有远程调用，仅校验本地vendor/是否与composer.lock一致
如何让 Composer 离线时仍能 install 新包（无 vendor 目录场景）
当只有 composer.json 没有 vendor/，又不能联网，就必须用“本地包仓库”模式。这不是配置镜像，而是把包文件本身变成源。
操作分三步：
- 在有网机器上，用
composer archive --format=zip vendor/monolog/monolog 2.10.0手动导出每个需离线安装的包为 zip（注意版本号要和composer.json中声明的一致） - 把这些 zip 放进离线机某个目录，比如
/opt/composer-packages/，并建一个packages.json文件，内容为标准 Packagist 格式，包含packages字段，列出每个包的name、version、dist.url（填本地路径如file:///opt/composer-packages/monolog-monolog-2.10.0.zip）、dist.shasum（用sha256sum monolog-monolog-2.10.0.zip计算） - 离线机运行
composer install --repository-url=file:///opt/composer-packages/packages.json，Composer 就会从本地读 zip 并解压
为什么设置 “packagist.org: false” 不起作用
很多人在 composer.json 里加 "packagist.org": false，发现依然报错。这是因为该配置只禁用默认仓库，但 Composer 仍会尝试加载其他仓库（包括隐式启用的 packagist.org 备份源），且不会自动 fallback 到本地文件。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
真正有效的写法是：
- 彻底移除 packagist.org：运行
composer config --global repo.packagist false（注意是--global，影响全局配置） - 再显式添加本地仓库：
composer config --global repositories.offline '{"type":"composer","url":"file:///opt/composer-packages/"}' - 最后确认生效：
composer config --global repos应输出含offline的条目，且packagist.org为false
漏掉 --global 是另一个高频失误——本地项目级配置 composer config repo.packagist false 对 install 无效，因为 Composer 在 install 阶段优先读全局配置。
离线部署 Laravel 项目时的额外注意点
Laravel 自带的 php artisan optimize:clear 或 config:cache 不依赖网络，但它的 vendor/bin/phpunit、vendor/bin/pest 等二进制脚本可能通过 #!/usr/bin/env php 调用系统 PHP，而离线机的 PHP 版本或扩展（如 pdo_sqlsrv）若缺失，会导致 composer install 后 php artisan 命令直接报 Class not found。
- 务必检查离线机 PHP 版本是否 ≥ 项目要求（如 Laravel 5.1 要求 PHP ≥ 5.5.9，但示例中明确用 PHP 7）
- 确认关键扩展已启用：
php -m | grep -E "(pdo|curl|mbstring|tokenizer|xml)"，SQL Server 项目还需sqlsrv和pdo_sqlsrv -
composer.lock中的platform字段（如"php": "7.0.33"）只是约束提示，不阻止安装；真正起作用的是离线机实际 PHP 环境
离线环境最脆弱的环节从来不是 Composer 本身，而是它背后那一整套隐式依赖：PHP 解释器版本、扩展、时区配置、甚至 /dev/urandom 权限。别只盯着 composer install 成功，得跑通 php artisan tinker 才算真正落地。
