Composer update默认不区分安全补丁，仅按composer.json约束安装最新兼容版；安全更新需人工触发并依赖composer audit验证漏洞，无全自动开关。
composer update 默认不区分安全补丁，它只按 composer.json 里的约束拉最新兼容版本；所谓“安全更新”，必须靠人主动触发 + 工具辅助验证，没有全自动开关。
composer audit 是识别真实漏洞的唯一可靠入口
版本号新 ≠ 安全，composer outdated 显示有更新，不代表当前版本有 CVE。只有 composer audit 会查 Symfony Security Advisory Database，告诉你 symfony/http-foundation 的 5.4.22 是否已被标记为含 CVE-2023-45802。
- 加
--no-dev排除开发依赖干扰（比如phpunit的漏洞通常不影响生产） - 加
--format=json适合 CI 脚本解析，例如用jq '.advisories[] | select(.severity == "critical")'过滤高危项 - 输出
No security vulnerabilities found不代表绝对安全——数据库可能未同步，或漏洞尚未公开收录
只升补丁版：靠约束写法，不是靠命令参数
composer update --patch-only 是 Composer 2.5+ 新增命令，但它只在满足特定条件时生效：当前锁文件中该包版本必须是 x.y.z 形式，且约束本身允许补丁升级（如 "monolog/monolog": "2.8.*" 或 "~2.8.0"）。它不会强行把 ^2.0 缩窄成只升补丁。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"package/name": "2.8.*"→ 允许2.8.1→2.8.27，但不升2.9.0 -
"package/name": "~2.8.0"→ 等价于>=2.8.0 ，效果同上 -
"package/name": "^2.8"→ 允许升到2.9.0甚至2.10.0，哪怕只是修一个补丁 - 写死
"2.8.1"？那composer update根本不会动它，audit 报了漏洞也无解——得手动改composer.json
强制升到已知修复版：绕过约束限制的实操路径
当 composer audit 明确指出漏洞在 laravel/framework 7.2.4，修复版是 7.2.5，但你的约束是 "^7.0" 却没自动升上去，说明 Composer 认为 7.2.4 仍满足范围、无需更新。这时就得人工干预：
- 运行
composer update laravel/framework:7.2.5 --with-dependencies：指定精确版本 + 同步检查子依赖是否兼容 - 别用
composer require laravel/framework:7.2.5—— 它会重写composer.json并可能触发不必要的依赖调整 - 执行前先加
--dry-run，确认它只改目标包及其必要子依赖，不牵连其他 - 升级后立刻跑
composer show laravel/framework和composer audit双重验证
锁文件与安全更新的关系常被误读
composer.lock 固定的是安装结果，不是安全状态。你删掉 lock、再 composer install，装出来的仍是旧版——除非 composer.json 约束已放宽或显式指定新版本。真正起作用的是三者联动：composer.json 的约束宽度 + composer.lock 的当前快照 + composer audit 的漏洞情报。
- 改了
composer.json里非依赖字段（如description），导致 lock 哈希不匹配？用composer update --lock-only（Composer 2.2+），它不碰 vendor，只重算哈希 - 想刷新 lock 文件格式或校验和？用
composer update --lock，它无视composer.json变更，纯对 vendor 快照 - 二者名字像，但行为完全相反：
--lock-only响应 json 变更，--lock忽略 json 变更
安全更新最易被忽略的一点：它从来不是“一次命令解决”的事。audit 发现问题 → 约束是否允许升 → 升哪个具体版本 → 是否带入新冲突 → 锁文件是否同步 → 生产环境是否真生效——每一步都可能断链。别指望工具替你做判断，它只负责告诉你“哪里不安全”和“怎么改”。
