composer update 不能用 --min-stability 或 --prefer-lowest 限制版本范围，因二者仅改变依赖解析策略而非筛选已锁定版本；真正限制范围需显式指定包名与约束，如 composer update "guzzlehttp/guzzle:^7.5"。
composer update 为什么不能用 --min-stability 或 --prefer-lowest 限制版本范围
这两个参数不是“限制取值范围”的开关，而是改变依赖解析策略的全局行为。它们不筛选已锁定的版本，只影响 composer update 重计算时的候选集。
-
--min-stability=dev允许引入 dev 分支包（即使 composer.json 里写的是"minimum-stability": "stable"），但不会让已 lock 的 stable 版本“降级” -
--prefer-lowest强制所有约束取下界（如^7.4→ 实际装 7.4.0），但它只在 update 过程中生效，且会忽略某些隐式稳定性要求（比如 require-dev 中的包若没显式标 stability，仍可能 fallback 到 stable） - 真正能“限制范围”的只有显式指定包名+版本约束：例如
composer update monolog/monolog:2.8.*或composer update "guzzlehttp/guzzle:^7.5"（注意引号防 shell 解析）
如何用 require 命令精准控制单个包的版本上限和下限
composer require 是唯一支持直接写版本区间的命令，但语法必须严格，否则会被当成新包安装或报错。
- 写法正确：
composer require "monolog/monolog:>=2.8.0 —— 这会更新 lock 文件，强制该包落在 2.8.x 区间内 - 常见错误：
composer require monolog/monolog~2.8看似合理，但~2.8等价于>=2.8.0 ，而 Composer 会把它当作“新约束追加”，若原 lock 已含 3.0.0，则触发冲突并退出，不会自动 downgrade - 想安全降级？先
composer remove monolog/monolog，再require带区间的新版本；或者直接编辑composer.json的require字段后跑composer update monolog/monolog
composer install 能不能跳过某些包、只装指定子集
不能。install 是精确还原 lock 文件的流程，没有“按需安装”机制。所谓“限制范围”，只能靠提前干预 lock 文件或拆分依赖结构。
- 如果只是不想加载某些包的类（比如测试工具），用
--no-dev即可，它不删 vendor，但会跳过 autoload-dev 和 require-dev 下的包 - 若要彻底排除某包（如私有组件未授权时不让装），得在
composer.json里删掉对应条目，再composer update --lock重写 lock 文件 - 别指望
--ignore-platform-reqs或--dry-run能绕过范围控制——前者只跳过 PHP 扩展/版本检查，后者只是模拟，不改任何文件
为什么 --with-dependencies 和 --with-all-dependencies 容易误判“范围”
这两个参数不缩小范围，反而大幅扩大求解空间，常被当成“精细控制”误用。
-
--with-dependencies表示：你指定了 A 包，那么 A 的直系依赖（如 A → B → C）也允许浮动版本；但它不会动 C 的间接依赖（如 C → D） -
--with-all-dependencies则把整个依赖图谱都拉进来重算，包括 require-dev 里的包所依赖的底层库（比如 phpunit → sebastian/exporter → symfony/polyfill-ctype） - 实测显示：加了
--with-all-dependencies后，一个只改guzzlehttp/guzzle的 update 命令，会导致 lock 文件中平均 40+ 个无关包版本变更——这不是“限制”，是放任
实际操作中最容易被忽略的一点：Composer 没有运行时“版本过滤器”。所有所谓“范围控制”，本质都是通过修改 composer.json 或 composer.lock 来影响下一次 update 的输入条件。一旦 lock 文件写死，install 就完全失去弹性。
