离线安装依赖必须显式设composer_disable_network=1并执行composer install --no-interaction --no-plugins --no-scripts --no-dev --optimize-autoloader，再运行composer dump-autoload -o；vendor存在仍失败是因默认校验远程元数据且无法跳过，除非彻底禁用网络通路与fallback源。
离线安装依赖不是“断网就能自动切换”，必须提前准备 + 显式禁用所有联网行为，否则 composer install 一定会卡在 Could not fetch https://repo.packagist.org/packages.json 或报 Connection refused。
为什么 vendor 存在、lock 文件完整，install 还是失败
错误根源不在文件缺失，而在 Composer 默认行为：即使 vendor/ 已满，composer install 仍会主动请求远程元数据（比如校验包是否存在、版本是否合法、哈希是否匹配），这个步骤无法跳过——除非你切断所有触发路径。
-
COMPOSER_DISABLE_NETWORK=1是硬性前提，不设它，所有--no-xxx参数都无效 - 全局残留
repo.packagist配置会导致 fallback 校验，必须运行composer config --global repo.packagist false彻底禁用 - 若
composer.lock中有"source"类型条目（如"dev-master"或 Git URL），离线时无法校验，install 必然失败 - 项目
composer.json里写了"repositories": [{"type": "packagist", "url": false}]，在COMPOSER_DISABLE_NETWORK=1下也会直接退出，不是静默忽略
最稳的离线 install 命令组合
这组参数不是“可选优化”，而是防止意外联网的强制防护。前提是：vendor/ 已存在、composer.lock 未改动、PHP 版本和必需扩展（mbstring、openssl、zlib）完全一致。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer install --no-interaction --no-plugins --no-scripts --no-dev --optimize-autoloader-
--no-plugins：跳过插件初始化，避免phpstan/extension-installer等隐式联网 -
--no-scripts：屏蔽post-install-cmd，防止脚本调用外部 API 或生成前端资源 -
--optimize-autoloader：强制重建vendor/autoload.php，避免残留旧路径导致Class not found - 执行完必须立刻补一记：
composer dump-autoload -o，否则运行时大概率报错
离线添加新包只能靠 path 仓库
composer require 默认必须联网查包名和版本，离线不可用。唯一可靠方式是把本地目录当仓库用：
- 目标包根目录下必须有合法
composer.json，含完整"name"（如"acme/utils"）和"version"或分支标识（如"dev-main"） - 项目根目录
composer.json中添加："repositories": [{"type":"path","url":"./packages/my-utils"}]（注意：url必须是相对路径；Windows 下也用/分隔） - 然后运行
composer require acme/utils，Composer 会从本地路径读取，不触网 - 不能用
git或vcs类型仓库，因为离线时无法 clone 或 fetch
容易被忽略的兼容性硬伤
很多团队以为打包 vendor/ 就万事大吉，但实际部署时崩在运行时——问题往往出在环境细节上：
- PHP 小版本差异（如 8.2.12 vs 8.2.13）可能因内部 API 微变导致
Class not found，不是 Composer 的错，是 PHP 自身 ABI 不保证小版本兼容 - 含
bin/脚本的包（如phpunit）要求目标机php在$PATH中，且路径与源环境一致；否则vendor/bin/phpunit会因 shebang 找不到解释器而失败 - 某些包的
post-install-cmd逻辑是纯 PHP（比如生成配置），但若它依赖了未启用的扩展（如ext-redis），--no-scripts能跳过执行，却掩盖了运行时崩溃风险 -
.gitignore可能排除了某些包的 dist 构建产物（如resources/目录），直接tar -czf vendor.tgz vendor/会漏文件
