会失效，Composer 2.2+ 已明确弃用 COMPOSER_NO_DEV=1，行为不稳定且常被覆盖；唯一可靠方式是显式使用 composer install --no-dev，且要求 composer.lock 文件本身不含 dev 包记录，否则报错“dev dependencies not found”。
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）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “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。
