Composer在离线物理机节点上制作自包含便携式依赖离线包方案-composer-PHP中文网

直接复制 vendor 目录是最可行的便携方案，前提是源机与目标物理机的 php 版本（含小版本）、关键扩展（mbstring、openssl、json、curl、zip）完全一致，且项目不含需编译的扩展依赖；打包前须执行 composer install --no-dev --optimize-autoloader 并验证 autoload，解压后需运行 composer_disable_network=1 composer install --no-plugins --no-scripts --no-interaction --no-dev 及 composer dump-autoload -o --classmap-authoritative。

composer在离线物理机节点上制作自包含便携式依赖离线包方案

直接复制 vendor 目录是最可行的便携方案

只要源机和目标物理机的 PHP 版本（含小版本，如 8.2.12）、关键扩展（mbstring、openssl、json、curl、zip）一致，且项目不含需编译的扩展依赖（如 ext-redis 的 C 模块），vendor/ 就是可搬运资产，不是临时产物。

常见错误现象：Class not found 或 require(): Failed opening required 'vendor/autoload.php'——多数不是路径问题，而是 PHP 环境不匹配或 autoload.php 权限被改（尤其从 Windows 打包再解压到 Linux 时）。

打包前务必在源机运行：composer install --no-dev --optimize-autoloader，再用最小验证脚本确认可用：php -r "require 'vendor/autoload.php'; echo class_exists('Monolog\Logger') ? 'OK' : 'FAIL';"
打包命令要保留所有文件（包括被 .gitignore 排除但实际运行必需的资源）：tar -czf vendor.tgz -C /path/to/project vendor/，不要用 zip（Windows 下可能损坏 symlink）
目标物理机解压后，优先执行：composer dump-autoload -o --classmap-authoritative，它能绕过文件扫描，避免因权限或挂载方式导致的类加载遗漏

离线机必须禁用所有网络 fallback 行为

composer install 在离线物理机上仍可能触发 DNS 查询或 HTTP 请求，哪怕 vendor/ 已存在——这是默认行为，不是 bug。唯一可靠拦截方式是强制设置环境变量。

常见错误现象：Could not fetch https://repo.packagist.org/packages.json 或卡在 Loading composer repositories——说明某处配置未生效，或插件仍在尝试联网。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

执行安装时必须加：COMPOSER_DISABLE_NETWORK=1 composer install --no-plugins --no-scripts --no-interaction --no-dev
检查是否全局禁用了 packagist：composer config --global repo.packagist 应输出 null；若返回 composer https://packagist.org，立刻运行：composer config --global repo.packagist false
删掉项目 composer.json 中任何 "repositories" 里指向 https:// 的条目，哪怕你认为它“没被用到”

artifact 仓库适合多项目统一分发，但包命名不能错

如果你要在多台离线物理机上部署不同项目，且希望复用同一套依赖包（比如统一升级 monolog），artifact 类型仓库比复制 vendor/ 更可控——它让 composer install 只读本地 .tar.gz 文件，完全跳过元数据解析。

常见错误现象：Package monolog/monolog not found——不是包缺失，而是文件名或内容不满足 artifact 校验规则。

压缩包命名必须严格为：vendor-name/package-name-version.tar.gz（例如：monolog/monolog-2.13.0.tar.gz）
包内根目录必须含有效 composer.json，且其中 "name" 和 "version" 字段须与文件名完全一致（大小写、分隔符都不能差）
所有包平铺放在一个目录下（如 /opt/artifacts/），不要嵌套子目录；然后运行：composer config repositories.offline '{"type":"artifact","url":"/opt/artifacts/"}'
离线机执行：COMPOSER_DISABLE_NETWORK=1 composer install --prefer-dist，它会按 composer.lock 中的 dist.shasum 查找并校验对应文件

PHP 扩展和二进制兼容性是物理机迁移最易忽略的点

离线物理机往往运行在特定硬件架构（ARM64、x86_64）、内核版本或容器沙箱中，vendor/ 里的某些包可能含平台相关二进制（如 grpc/grpc 的 .so、ext-protobuf 的编译模块），这些无法跨平台复制。

常见错误现象：无报错但运行时 Fatal error: Class 'Grpc\Channel' not found，或 undefined symbol: SSL_CTX_set_alpn_protos——这类问题不会在 composer install 阶段暴露，只在首次 require 时崩溃。

确认目标物理机已预装所有 ext- 依赖：运行 php -m | grep -E '^(zip|openssl|mbstring|sockets|curl)$'
对含 C 扩展的包（如 ext-redis, grpc/grpc），不要复制 vendor/，改用 path 仓库 + 源码编译，或确保目标机已通过系统包管理器安装对应扩展（如 apt install php-redis）
若项目用了 bin 脚本（如 phpunit），检查目标机 php 是否在 $PATH 中，且 #!/usr/bin/env php 解析正确（某些精简版 Docker 镜像会删掉 /usr/bin/env）