--minor-only 不能限制更新范围，仅过滤 composer outdated 的输出结果，只显示 minor 或 patch 升级，排除 major 升级，不影响依赖解析与实际安装行为。
什么是 --minor-only，它真能只更新小版本吗？
不能。这是最常见的误解。composer outdated --minor-only 并不会「限制检查范围」，它只是**过滤输出结果**：只显示那些存在 minor 版本（如 2.1.0 → 2.3.4）或 patch 版本（如 2.3.0 → 2.3.4）更新的包，但排除 major 升级（如 2.x → 3.x）。它不改变依赖解析逻辑，也不影响 composer update 的行为。
换句话说：这个 flag 只管「给你看什么」，不管「能装什么」。
composer outdated --minor-only 的实际用途和典型误用
它的合理使用场景是：在 CI 或日常巡检中快速扫一眼「有没有可安全升级的小版本」，尤其适合维护长期支持（LTS）分支的项目。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 它会忽略所有
^1.0.0约束下可能发生的1.x → 2.x变更 —— 但前提是你的composer.json里确实没写死"some/pkg": "2.*"这类宽松约束 - 如果某个包的当前安装版本是
3.2.1，而最新版是3.2.5（patch）或3.4.0（minor），它会出现在列表里；如果是4.0.0（major），则被过滤掉 - ⚠️ 它无法识别「语义化版本之外的变更」：比如某些包把 breaking change 放在 patch 版本里（违反 SemVer），
--minor-only不会预警 - ⚠️ 它不检查子依赖（transitive dependencies）是否因主依赖升级而被连带更新 —— 那些变化仍可能引入不兼容
真正安全升级 minor 版本该怎么做？
光靠 outdated 命令远远不够。关键在「控制更新范围」和「验证边界」：
- 用
composer update vendor/package --with-dependencies显式指定要升的包，避免全量更新导致意外连锁反应 - 确保
composer.json中该包的版本约束是^x.y.0（推荐）或~x.y.0，而不是*、dev-main或>=x.y.0 - 运行
composer update后，立刻检查composer.lock文件中该包及其直接依赖的 version / source commit / dist shasum 是否符合预期 - 必须跑测试：特别是集成测试和任何调用了该包 API 的逻辑；小版本也可能修改返回结构、弃用方法（哪怕没报 Deprecated 警告）
- 若项目用 GitHub Actions / GitLab CI，建议加一步：
composer outdated --minor-only --direct | grep -q "." || echo "No minor updates available"
作为轻量健康检查，但别把它当升级依据
比 --minor-only 更值得依赖的替代方案
想系统性管理 minor 更新，与其依赖这个易误导的 flag，不如用这些更可控的方式：
-
composer prohibit --update（需插件dealerdirect/phpcodesniffer-composer-installer不适用，此处指社区常用实践）—— 实际上更推荐：composer update --dry-run --with-dependencies先预览变更树 - 用
composer-require-checker或roave/security-advisories检查是否引入已知风险版本，这比单纯看 minor 更实质 - 对关键包（如
monolog/monolog、symfony/http-kernel）设置config.platform锁定最低兼容版本，防止意外降级或错配 - 定期执行
composer update --dry-run+git diff composer.lock，人工审查变更 —— 小版本更新频繁时，自动化脚本容易漏掉上下文
最常被忽略的一点：很多团队以为 --minor-only 是「安全开关」，其实它连版本兼容性声明都不读，只按字面匹配版本号前缀。真正的安全来自约束收紧、变更可见、测试覆盖，而不是一个输出过滤参数。
