--ignore-platform-reqs仅跳过安装前php版本、扩展、系统库校验，不解决运行时缺失扩展（如class 'redis' not found）或php语法不兼容（如php 8.1运行8.2的match表达式）导致的崩溃。
composer update --ignore-platform-reqs 为什么不能解决运行时错误
它只跳过 PHP 版本、扩展缺失等安装前检查，不改变包本身的兼容性。比如在 PHP 8.1 上用 --ignore-platform-reqs 强装一个声明 "php": ">=7.4, 的包，<code>composer install 能过，但运行时遇到 MatchError 或 Attribute 语法报错就无法避免。
常见误用场景：
- 看到
Your requirements could not be resolved就加--ignore-platform-reqs，结果部署后Class not found - 本地 PHP 版本低，靠它硬升 Laravel 11（要求 PHP ≥ 8.2），artisan 命令直接退出
- 忽略
ext-gd缺失警告，后续图片处理逻辑抛Call to undefined function imagecreatefrompng()
composer require --no-update 不等于锁定版本
composer require vendor/package:1.2.3 --no-update 只改 composer.json，不更新 composer.lock，也不校验约束是否可满足。冲突依然存在，下次 composer install 还会失败。
真正生效的锁定方式只有两种：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在
composer.json的require中写死版本号（如"monolog/monolog": "2.9.1"），再执行composer update monolog/monolog - 用
composer update vendor/package --with-dependencies，强制连带更新其子依赖，避免父包升级而子包卡在旧版 - 若需全局压制某类版本（如避免 dev 分支干扰），临时加
"prefer-stable": true到composer.json，但别提交
为什么 composer update vendor/package 可能比全量更新更危险
它不是“只更新这个包”，而是以该包为根重新计算整个子依赖图。当目标包声明了宽松约束（如 "^1.0 || ^2.0"），Composer 可能回退到一个更老、但与其他包冲突更小的版本——比如从 guzzlehttp/guzzle:7.5.0 降级到 6.5.8，导致你代码里用的 Promise 接口突然失效。
更隐蔽的风险：
- 该包是
require-dev里的（如phpunit/phpunit），升级后拉高 PHP 要求，与主项目config.platform.php冲突 - 它间接引入了一个被
conflict标记的包（如某私有组件声明"conflict": {"laravel/framework": ">=11"}），而你没装 L11，却因其他依赖链触发了全局冲突 - 输出里没报错，但
composer.lock中该包的dist.url指向已删除的 GitHub release ZIP，下次install直接 404
强制操作后必须立刻验证的三件事
任何绕过默认校验的操作，都意味着你主动承担了兼容性判断责任。不能只看 composer update 是否成功。
- 跑
composer show -a vendor/package，确认它当前实际安装的版本，以及它的requires和conflicts字段是否与项目其余部分兼容 - 手动执行
vendor/bin/phpunit --stop-on-failure，重点盯Call to undefined method和ArgumentCountError—— 这些不会在安装阶段暴露 - 检查日志中是否有
Deprecated:行，它们不会中断流程，但下个主版本大概率变成Error，比如ContainerInterface::get()返回类型收紧
最常被跳过的环节是验证 autoload：强制更新后若出现 Class not found，先查 composer.json 里 psr-4 映射是否还覆盖新类路径，再跑 composer dump-autoload -o，别直接怀疑依赖冲突。
