应分层放宽、逐级验证：先运行 composer outdated --major-only 查看可升主版本的包，该命令仅显示语义化版本规则下可升级且未被锁定或压制的候选包；若输出为空，说明当前约束已允许跨主版本。
Composer旧项目升级时不能直接“放开所有约束然后update”，那样大概率导致依赖图爆炸、冲突无法解析，甚至装不上任何包。真正可行的做法是分层放宽、逐级验证，核心在于控制影响范围和保留回退路径。
先确认当前哪些包卡在旧主版本
运行 composer outdated --major-only，它会列出所有可升到新主版本（如 2.x → 3.x）但被当前约束拦住的包。注意：这个命令只显示“有新版且满足语义化版本规则”的候选，不包含已锁定或被其他依赖压制的包。
- 如果输出为空，说明当前约束本身已允许跨主版本（比如用了
*或>=1.0 ），无需放宽 - 如果某包显示 “2.8.5 → 3.2.0”，而
composer.json里写的是"foo/bar": "^2.5"，这就是要动手的地方 - 别信
outdated的全部建议——有些包升主版本后要求 PHP 8.2+，而你还在用 7.4，得先查文档
手动修改 composer.json 的约束格式
对每个目标包，把紧约束换成能覆盖目标主版本的宽松写法。不是无脑换 *，而是按需选择：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 升一档主版本（如 2.x → 3.x）：
"foo/bar": "^3.0"—— 最常用，兼容性较可控 - 允许多主版本共存（极少见）：
"foo/bar": "^2.0 || ^3.0"—— 仅当该包明确声明支持双版本且你代码做了适配 - 临时放开试探（仅开发环境）：
"foo/bar": "dev-main"或"foo/bar": "dev-develop"—— 适合想快速验证 API 变更，但别提交到 git - 绝对不要用
"*"或"dev-master"，它们绕过 Composer 的版本解析逻辑，update可能选到破坏性变更的快照
执行 update 时必须加限制参数
改完 composer.json 后，别直接 composer update。它会尝试更新所有包，把没动过的也拉新，容易引入无关变更：
- 只更新刚改过约束的包：
composer update foo/bar bar/baz --with-all-dependencies -
--with-all-dependencies是关键：它让 Composer 重新计算整个子图，避免只升顶层包却留着旧版间接依赖 - 加上
-v参数看详细解析过程，一旦出现Conclusion: don't install xxx类错误，说明约束仍有隐含冲突，得回退检查 - 如果失败，用
composer why-not vendor/package:3.0查哪个包在死守旧版本
vendor 目录和 lock 文件的清理时机
composer.lock 不是“缓存”，它是精确安装依据。升级过程中它必须被重写，但不能靠删 lock 文件硬来：
- 每次成功
composer update xxx后，composer.lock会自动更新对应条目，其余保持不变——这是渐进升级的安全基础 - 不要手动删
vendor/再install，那会丢失当前已验证的依赖状态；update本身就会替换 vendor 中对应包 - 升级完成后，用
git diff composer.lock看哪些包真变了版本，比git diff composer.json更真实 - 如果中途失败想回滚，直接
git checkout composer.json composer.lock即可，vendor 会随下次install自动恢复
最常被忽略的一点：放宽约束只是第一步，真正的成本在后续——你要跑全量测试，检查日志是否多出弃用警告（E_USER_DEPRECATED），并确认所有插件、自定义扩展仍能加载。没有自动化能代替人眼验证 API 断点变更。
