离线安装 composer 依赖必须设 composer_disable_network=1 并执行 composer install --no-plugins --no-scripts --no-autoloader，再运行 composer dump-autoload -o；仅拷 composer.lock 会因远程元数据校验失败报 “package not found”，vendor 存在仍报错是因默认访问 packagist.org 校验。
离线安装 Composer 依赖，不能靠“拷个 composer.lock 就跑 composer install”——它大概率报 Package not found 或卡在 Downloading https://repo.packagist.org/packages.json。真正能落地的，只有两种路径：一种是彻底不联网、零 HTTP 请求，靠完整 vendor/ + 环境变量强制隔离；另一种是把 Packagist 搬进内网，用本地 HTTP 镜像源替代外网地址。前者简单粗暴但不可更新，后者可维护但需额外服务。
为什么 vendor 目录存在还报 “Package not found”
这不是文件丢了，是 Composer 在 install 阶段仍会尝试访问 packagist.org 校验元数据（比如版本列表、dist.url 格式、dist.shasum），哪怕 vendor/ 已存在。只要没显式切断网络通路，这个请求就会触发。
-
COMPOSER_DISABLE_NETWORK=1是必须项，否则所有--no-xxx参数都拦不住初始校验 - 删掉全局配置里的
repo.packagist：运行composer config -g --unset repo.packagist - 临时验证是否真离线：往
/etc/hosts（Windows 是%SystemRoot%\System32\drivers\etc\hosts）加一行127.0.0.1 packagist.org，再执行composer install -v；看到Connection refused才算到位 - 若
composer.lock中某包的dist.url是https://开头，且没配本地仓库，COMPOSER_DISABLE_NETWORK=1下会直接退出，不给你机会
最稳的离线方案：完整 vendor + 禁插件脚本 + 强制重生成 autoload
别信“只传 composer.lock + composer.json”，也别指望 composer archive 打全量——它不处理子依赖。真正能落地的只有完整 vendor/ 目录打包。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在线机执行：
composer install --no-dev --prefer-dist --optimize-autoloader，确保所有子依赖进vendor/，且无 dev-only 文件 - 打包前删掉：
vendor/bin/（Windows 软链失效）、vendor/composer/installed.json（含绝对路径，引发 autoload 异常） - 目标机解压后，执行：
COMPOSER_DISABLE_NETWORK=1 composer install --no-plugins --no-scripts --no-autoloader - 必须补一记：
composer dump-autoload -o，否则可能运行时报Class not found
想保留 composer install 流程？搭本地 Packagist 镜像源
不是“放 ZIP 就能用”，而是要让 Composer 认为它还在连官方源——只是地址换成本地 HTTP 服务。Satis 是目前最轻量、最稳定的静态镜像生成工具，不需要数据库，Nginx 直接托管即可。
- 联网机上用
composer create-project composer/satis安装 Satis，写好satis.json，明确指定要镜像的包和版本（避免全量同步） - 运行
php bin/satis build satis.json web/，生成含packages.json和所有 ZIP 包的静态站点 - 把整个
web/目录拷到内网服务器，用 Nginx 指向该目录根路径（确保能通过http://192.168.10.100/packages.json访问） - 内网机执行：
composer config -g repos.packagist '{"type":"composer","url":"http://192.168.10.100"}'，覆盖默认源 - 注意：
secure-http必须关掉，否则 HTTP 镜像源会被拒绝：运行composer config -g secure-http false
artifact 源为什么解压 ZIP 后还是报错
artifact 类型仓库只提供 ZIP 包，不提供元数据（packages.json、composer.json）。Composer 仍需从某个源拉取这些 JSON 文件来解析依赖树——如果没显式配置镜像源，它默认 fallback 到 packagist.org。
- 必须组合使用：
composer.json中同时声明两个repositories：一个artifact源 + 一个内网镜像源（如type: "composer"指向http://192.168.10.100） -
artifacts/必须是相对路径，写成./artifacts/；绝对路径（如/opt/artifacts/）会被 Composer 忽略 - 确保外网机器生成
composer.lock时用了--prefer-dist，且dist.url是相对路径（如./artifacts/pkg-1.2.3.zip）或file://协议 - 修改
composer.json加artifact源后，要删掉旧的vendor/和composer.lock，重新执行composer update --no-dev --prefer-dist --no-autoloader生成新 lock
真正难的不是“怎么配”，而是“怎么确认它真的不联网了”。很多问题直到上线运行才暴露——比如插件悄悄调 API、autoload 因路径变更失效、或者 composer.lock 里混进了 dev-master 这类不稳定版本。每次迁移前，务必用 hosts + -v 实测，而不是只看命令有没有报错。
