Composer使用内置环境替换选项在CI环境自动化去除开发版依赖-composer-PHP中文网

会失效，composer 2.2+ 已明确弃用 composer_no_dev=1，行为不稳定且常被覆盖；唯一可靠方式是显式使用 composer install --no-dev，且要求 composer.lock 文件本身不含 dev 包记录，否则报错“dev dependencies not found”。

composer使用内置环境替换选项在ci环境自动化去除开发版依赖

CI脚本里用 COMPOSER_NO_DEV=1 会失效吗

会失效，而且是明确弃用的行为。Composer 2.2+ 已移除对 COMPOSER_NO_DEV 环境变量的支持，CI 脚本里设了也大概率被忽略或覆盖——它不参与依赖解析逻辑，也不影响 composer install 的实际行为。

常见误判是看到 CI 日志里写了 COMPOSER_NO_DEV=1，就以为 dev 包没装。结果上线后 vendor/phpunit 还在，composer show --dev 仍能列出一堆包。

唯一可靠方式是显式加 --no-dev 参数，比如：composer install --no-dev --prefer-dist
CI 配置中若用 env 设置变量，必须同步删掉旧的 COMPOSER_NO_DEV 行，避免误导后续维护者
某些 CI 平台（如 GitHub Actions）会自动注入环境变量，可能意外覆盖你设的值，直接参数化更可控

composer install --no-dev 报错 “dev dependencies not found” 怎么办

这不是命令错了，而是 composer.lock 文件本身还存着 dev 包记录。--no-dev 要求 lock 文件“干净”，即里面不能有 packages-dev 或 require-dev 相关条目；否则 Composer 会拒绝执行并报这个错。

典型场景：本地开发时跑过一次没带 --no-dev 的 composer install，然后把带 dev 包的 composer.lock 提交到了 Git —— CI 拉下来直接卡住。

Discussion Composer

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

下载

修复方法：在干净环境（无 vendor/、无 composer.lock）下运行 composer update --no-dev --lock，再提交新 lock 文件
CI 中可加前置清理：git clean -xffd vendor/ && rm -f composer.lock，强制从头生成
检查 lock 文件是否干净：打开 composer.lock，搜索 "packages-dev" 或直接搜 "phpunit"、"mockery"、"symfony/debug-bundle"，结果应为空

CI 构建后怎么验证 --no-dev 真生效了

命令行输出 “Installing dependencies from lock file” 不代表成功。必须进构建产物（容器镜像、部署目录）里查真实文件和 autoload 行为。

检查 vendor 目录：ls vendor/ | grep -E "phpunit|mockery|symfony/debug"，输出应为空
验证 autoload 是否剔除 dev 类：grep -r "Tests\|TestCase" vendor/composer/autoload_classmap.php 2>/dev/null，不应匹配到任何内容
运行 composer show --dev，应提示 No dependencies installed for development 或直接报错 Command 'show' is not defined（说明 dev 区块未加载）
特别注意：--no-dev 不清理 vendor/bin/ 下残留二进制文件（如 phpunit），需额外 rm -f vendor/bin/phpunit

为什么不能靠修改 composer.json 切换环境依赖

有人想在 CI 里用脚本临时删掉 composer.json 里的 require-dev 块，再跑 composer install —— 这会导致 lock 文件哈希不一致，本地和线上行为分裂，是反模式。

Composer 的依赖解析强绑定 composer.lock，而 lock 文件由 composer.json + 当前平台 + PHP 版本 + platform config 共同决定。手动删字段后，composer install 会按新 JSON 重新计算依赖树，但旧 lock 文件已失效，CI 构建可能失败或引入意外版本。

正确做法：始终保留 require-dev 在 composer.json 中，靠 --no-dev 控制安装行为
如果真要模拟不同环境约束（比如禁用 xdebug），用 config.platform，而不是删配置
Dockerfile 中应固化命令：RUN composer install --no-dev --optimize-autoloader --no-scripts，而非依赖外部变量或脚本替换

最常被忽略的是 autoload-dev 的路径注册残留：即使 --no-dev 成功，vendor/autoload.php 里仍可能包含 autoload-dev 的 require 语句，导致测试类路径被意外加载。检查 vendor/autoload.php 文件末尾，确认没有 require __DIR__ . '/autoload_real.php'; 之外的 dev 相关 require。