^1.2.3不等于“安全升级”，因semver仅为约定，composer仅校验版本号格式而非实际兼容性，主版本不变仍可能含破坏性变更，必须通过--dry-run和release note人工验证。
旧依赖能向后兼容升级，前提是它没引入破坏性变更（BC break），且你的 composer.json 里用的是 ^ 约束而非精确版本或过窄范围——但别默认信任，得验证。
为什么 ^1.2.3 不等于“安全升级”
语义化版本（SemVer）只是约定，不是法律。有些包把不兼容的接口变更塞进次版本（比如 monolog/monolog 从 1.x 升到 2.x 是主版本跃迁，但某些小包会把重大重构放在 ^2.5.0 → ^2.6.0 里）。Composer 只认版本号格式，不管实际代码是否真兼容。
-
^约束只保证主版本不变，不保证行为一致：比如"symfony/http-kernel": "^5.4"允许升到5.4.38，但某次补丁可能悄悄改了事件监听器的执行顺序 - 框架插件常踩这个坑：Laravel 的
spatie/laravel-permission在5.x内部重写了权限缓存逻辑，没改 API，但并发场景下表现不同 - 运行
composer update --dry-run看拟安装版本，再查对应 release note，重点关注 “Breaking changes” 和 “Deprecated” 条目
composer outdated 显示的版本到底该不该升
composer outdated 列出所有可更新版本，但带 (major) 标记的不能直接升；没标记的也未必都安全——关键看变更类型和你用到了哪些功能。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 优先处理带
!的条目（如guzzlehttp/guzzle 7.5.0 → 8.0.0 !）：这是 Composer 主动标出的主版本跃迁，必须人工介入 - 对次版本更新（如
doctrine/dbal 3.6.0 → 3.7.2），检查你是否用了被标记为@deprecated的方法：搜项目里有没有$connection->getDatabasePlatform()这类调用，DBAL 3.7 已弃用它 - 忽略
dev-master或dev-main行：这些是开发分支，不稳定，除非你明确需要某 PR 的修复
升级后 Class not found 或服务找不到的常见原因
不是 autoload 没跑，而是路径映射、服务注册或配置加载机制变了——尤其在框架大版本过渡期。
- Laravel 9 升 10 后
AppProvidersAppServiceProvider找不到：删掉composer.json里多余的"App\Providers\": "app/Providers/"映射，只留"App\": "app/"，再跑composer dump-autoload -o - Symfony 5 升 6 后
doctrine.dbal.connection报ServiceNotFoundException：不是依赖没装，是 Bundle 默认不再暴露该服务，需在config/packages/doctrine.yaml里加doctrine.dbal.connection: ~ - 升级后测试通过但线上报错：检查
composer install --no-dev是否漏掉了require-dev里实际运行时需要的包（比如roave/security-advisories是纯 dev 工具，但phpunit/phpunit若被误放require就会导致生产环境多装几十 MB）
真正麻烦的从来不是版本号跳变，而是那些没改接口、却悄悄改了执行时机、缓存策略或错误处理逻辑的“温和”更新——它们不会让 composer update 报错，但会让某个边缘请求突然超时或返回空数组。
