composer install根本不看composer.json的版本号，因为其设计目标是“还原”而非“解析”，它只读取composer.lock中硬编码的精确版本、url和校验和，完全跳过^、~等约束符号；lock缺失或损坏时会静默退化为update行为。
composer install 为什么根本不看 composer.json 的版本号
因为 composer install 的设计目标就是“还原”，不是“解析”。它只读 composer.lock，完全跳过 composer.json 里的 ^、~、* 等任何版本约束符号。
只要 composer.lock 存在且结构合法，Composer 就会逐条按里面记录的：name、version、dist.url、dist.shasum 去拉包、校验、解压。哪怕你把 composer.json 中的 "monolog/monolog": "^2.0" 改成 "^3.0"，不运行 composer update，install 依然装 2.x。
- 如果
composer.lock缺失或 JSON 格式损坏，install会静默退化为update行为——这是 CI 构建失败最隐蔽的根源之一 -
composer.lock里硬编码了 provider 地址（比如https://packagist.org或镜像 URL），换源后不删 lock，Composer 仍会往旧地址发请求，导致 404 或 SSL 错误 -
install --no-dev只过滤 lock 文件中已标记为 dev 的包，不会重新计算依赖图；它不关心你composer.json里是否写了"require-dev"
报 “Your requirements could not be resolved” 其实不是 install 阶段的问题
这个错误根本不会在 composer install 过程中出现——它只属于 composer update 或 composer require 的求解阶段。一旦看到这个报错，说明你当前执行的一定不是纯 install，而是触发了依赖重解析。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
常见诱因包括：composer.lock 不存在、被删、格式非法，或者项目 composer.json 的 config.platform 被修改过（比如改了 PHP 版本），导致 Composer 认为 lock 已失效，必须重算。
- 运行
composer diagnose可快速确认 lock 是否有效：它会明确提示 “lock file is not up to date” 或 “lock file is corrupted” - 真正卡在 install 阶段的典型错误是：
file could not be downloaded、SSL certificate problem、failed to open stream—— 这些全是网络、证书、权限或缓存问题，和依赖冲突无关 - 如果你在 CI 脚本里写了
composer install && composer update，那第一条 install 实际上没起作用，第二条 update 才真正决定装什么
镜像配置写对了，但 install 还是走官方源？检查这三处
全局镜像配置（repo.packagist）极易被绕过，不是“没生效”，而是被彻底屏蔽。关键判断依据永远是 composer install -vvv 输出的第一行 Downloading URL。
- 项目级
composer.json中只要存在"repositories"字段（哪怕值是空数组[]），全局配置就完全失效——不是优先级低，是直接忽略 - 宝塔、Docker、CI runner 通常以非 root 用户（如
www或runner）运行命令，而你在终端用root配的-g配置，该用户根本读不到~/.composer/config.json - 验证是否真写进去了：
composer config -g repo.packagist必须输出完整 JSON 对象，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；输出为空或仍是https://packagist.org，说明配置根本没存成功
install 成功后类找不到？autoload 没生效才是真问题
composer install 成功只代表 vendor 目录被正确解压，不代表自动加载能工作。90% 的 “Class not found”、“Command not found” 报错，根源在 autoload 机制未触发或映射错位。
- 检查
vendor/autoload.php是否被项目入口（如index.php或artisan）正确引入；漏掉这一行，整个 autoload 体系就瘫痪 - 运行
composer dump-autoload强制重建映射表，尤其当你手动改过composer.json的autoload段后 -
composer install --optimize-autoloader生成的vendor/composer/autoload_classmap.php是扁平化映射，对 APCu 友好，但一旦 classmap 缓存未更新，就会漏加载新类
