composer install卡住、版本不一致、ci失败，主因是require与install混用破坏lock一致性；require改声明并更新lock，install只按lock还原，ci应固定用install而非update，且必须提交composer.lock。

国内用 Composer 安装扩展包，镜像配对了但 install 还卡住、版本不一致、CI 失败——问题八成不在镜像本身，而在扩展安装流程没规范。

composer require 和 composer install 的适用场景别混用

require 是改依赖声明，install 是按声明落地；两者语义和副作用完全不同，混用会破坏 lock 文件一致性。

• composer require monolog/monolog 会修改 composer.json 并立即写入 composer.lock（相当于自动触发一次 install），适合新增依赖
• composer install 只读 composer.lock，严格还原已知状态，适合部署、CI、协作拉代码后初始化
• composer update 会重算整个依赖树并刷新 composer.lock，除非明确要升版本，否则别在生产环境或 PR 合并前执行
• CI 脚本里写 composer update 等于放弃版本控制，应固定为 composer install --no-dev（生产环境）或 composer install（测试环境）

require-dev 里的包为什么线上找不到类？

不是 autoload 没生效，是 require-dev 的包根本没被装进生产环境 vendor 目录。

Discussion Composer

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

下载

• composer install 默认跳过 require-dev 中的包，除非显式加 --dev 或设 COMPOSER_DEV_MODE=1
• autoload-dev 配置只影响 dev 包的自动加载路径，它不会让 dev 包的类在生产可用
• 把 phpunit/phpunit 放到 require 里，会导致线上也装 PHPUnit，体积膨胀且可能引入安全扫描告警
• 真正需要运行时能力的包（如日志、缓存驱动）必须放 require；纯工具链（PHPStan、PHP-CS-Fixer）必须放 require-dev

镜像配好了，为什么还连 packagist.org？

不是镜像失效，是配置没落到实际执行命令的用户或项目上下文里。

• 运行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 后，用 composer config -g repo.packagist 验证输出——若为空或报错，说明 -g 写错、repo.packagist 拼错（比如写成 repos.packagist）、或 composer type 值漏了
• 宝塔、Docker、CI 流水线常以 www 或 runner 用户运行，但你是在自己的 shell 里配的 -g，配置写进了 /root/.composer/config.json，而实际进程读的是 /home/www/.composer/config.json
• 项目级更可靠：进项目根目录执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它会安全写入 composer.json 的 repositories 字段（前提是原 repositories 是对象而非数组）
• 临时验证镜像是否可用？直接加参数：composer install --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/，不改任何配置

composer.lock 不提交，等于没锁

lock 文件不是缓存，是精确依赖快照；不提交它，团队和 CI 就永远在盲装。

• composer.lock 记录了每个包的确切版本、SHA256 hash、PHP 扩展要求、甚至嵌套依赖的 exact 版本——这些信息 composer.json 里根本没有
• Git 忽略 composer.lock 的后果：你本地 composer install 装的是 v2.4.1，同事拉代码后装出来是 v2.4.3，差异可能引发静默 bug
• 只有纯 library 项目（即自己不跑，只被别人 require）可不提交 composer.lock；所有应用型项目（Web、CLI、API）必须提交
• 修改 composer.json 后，立刻运行 composer update --lock 或 composer install 刷新 lock，再一起提交

最常被忽略的一点：换镜像后删掉 vendor 和 composer.lock 再重装，不是为了“清缓存”，而是避免旧 lock 文件里的元数据 hash 和镜像源返回的不一致，导致下载失败或校验报错。