~1.2.3 等价于 >=1.2.3 <1.3.0，表示允许补丁和次要版本更新，但不自动限制为仅安全补丁；安全更新需结合 composer audit 和 --with-dependencies 等策略实现。
Composer 默认的版本约束行为不会自动限制为仅安全补丁更新，~（波浪号）本身不是“只允许安全补丁”的开关，它只是语义化版本的范围控制符——能否实现安全补丁级更新，取决于你如何写约束、是否启用 composer update --with-dependencies 等策略，以及是否配合 composer audit 主动检查。
理解 ~ 波浪号的实际行为
~1.2.3 等价于 >=1.2.3 ，即允许更新到 <code>1.2.x 中任意更高小版本或补丁版本；~1.2 等价于 >=1.2.0 。它不区分“安全补丁”和“功能更新”，只按 SemVer 位数做范围截断。
也就是说：~ 不过滤漏洞，只限定版本区间。如果你依赖的 monolog/monolog 在 2.8.x 中被发现 CVE，而你锁的是 "monolog/monolog": "~2.8"，那么 composer update monolog/monolog 仍可能升到 2.9.0（如果该版本修复了漏洞），但也可能跳过修复版直接到 2.10.0（含新功能）——只要没破 就合法。
-
~1.2.3→ 允许1.2.4,1.2.10，但不允许1.3.0 -
~1.2→ 允许1.2.9,1.9.9，但不允许2.0.0 - 它无法阻止
1.2.3 → 1.3.0，除非你显式写死^1.2.3或1.2.*并配config.platform锁定最小稳定版
用 composer audit 主动识别已知漏洞
Composer 2.5+ 内置审计能力，它不修改依赖，但能告诉你当前锁文件里哪些包存在已披露的安全问题：
composer audit
输出类似：
Security vulnerability detected in monolog/monolog (CVE-2023-46804) - Upgrade to ^2.10.0 or ^3.0.0
这时你才清楚：该升哪个版本来修复。注意：audit 不自动升级，也不保证所有 CVE 都被收录（依赖 Symfony Security Advisory Database）。
- 运行前确保
composer.lock是最新（composer install后再审） - CI 中建议加
composer audit --no-dev --format=json | jq 'length == 0'做门禁 - 它对未发布到 Symfony DB 的私有包或零日漏洞无效
组合策略：约束 + 审计 + 锁定
真正接近“只更新安全补丁”的做法，是人为控制升级粒度，并靠工具辅助验证：
- 开发时用
"package/name": "1.2.*"（等价于>=1.2.0 ）比 <code>~1.2更窄，限制在补丁层 - 升级前先跑
composer audit，确认目标版本是否含修复 - 执行
composer update package/name --with-dependencies，避免间接引入不兼容变更 - 提交前检查
composer.lock变更：只应出现version字段微调（如"1.2.3" → "1.2.4"），而非"1.2.3" → "1.3.0"
没有一键开关让 Composer “只装安全补丁”。它的设计哲学是：版本约束由人定义，安全决策由人确认。
为什么不能依赖 composer update --dry-run --minor-only？
Composer 没有 --minor-only 或 --patch-only 参数。所谓“仅小版本更新”只能靠人工写约束（如 1.2.*）+ 手动验证。试图用 composer update --dry-run 预览再筛选，容易漏掉依赖树深层的间接升级——比如你锁 foo/bar: 1.2.*，但它依赖的 baz/qux 从 0.5.1 升到 0.6.0，这就不在你的主约束控制范围内。
最易被忽略的一点：安全补丁常需要跨小版本（例如 CVE 修复在 2.10.0，而你卡在 ~2.8），此时 ~ 反而成了障碍——你得主动放宽约束，而不是指望它自动适配修复路径。
