composer update vendor/package --with-dependencies是最小破坏性升级的起点，它仅重算指定包及其直系依赖，避免全量更新引发的连锁冲突与隐式BC break，必须显式指定包名且不加引号或版本修饰符。
composer update --with-dependencies 是最小破坏性升级的起点
直接 composer update 全量升，等于让 Composer 自己猜哪些包能一起动、哪些会打架。大批量自动化升级时，这极易触发连锁冲突或隐式 BC break。必须锁定主目标包，只让它带起必要依赖。
常见错误现象：Your requirements could not be resolved 报错里夹着十几行 requires php ^7.4 或 conflicts with monolog/monolog 3.0，其实是某个间接依赖被意外拉高了版本。
- 用
composer update vendor/package-name --with-dependencies，比如composer update guzzlehttp/guzzle --with-dependencies - 避免加
--dry-run后就停——它只模拟，不装包，躲不过运行时类加载失败 - 每次只操作一个主依赖，等 CI 测试通过再推进下一个
- 若
composer.lock变更超过 15 行，说明影响面已失控，暂停并查composer show -t vendor/package-name看依赖树深度
测试套件必须在升级前 clean exit，否则全是假阳性
升级后测试挂了，八成不是新包的问题，而是你本地的 PHPUnit 根本没跑通。Composer 不管你测试写得对不对，它只管装包；但你得确保 autoloader、bootstrap、环境变量全在线。
典型报错：Class 'Tests\TestCase' not found 或 ReflectionException: Class App\Models\User does not exist，本质是 autoload 没刷新或 phpunit.xml 里 bootstrap 路径错了。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 升级前先跑一次
vendor/bin/phpunit，确认 exit code 是 0 - 执行
composer dump-autoload再试；Laravel 项目额外跑php artisan config:clear - 检查
APP_ENV=testing是否生效，尤其注意config/database.php中 testing 连接是否可连 - CI 中强制加
--no-cache，避免复用旧的 opcode 缓存干扰结果
composer.lock 变更必须人工核对，不能靠 diff 工具自动合并
composer.lock 不是普通 JSON 文件，它是依赖解析的快照。Git 自动 merge 它，大概率把两个不同 PHP 版本下解出的包版本混在一起，导致 composer install 在某台机器上失败。
容易踩的坑：团队有人 git commit -a 忘记加 composer.lock，或者 .gitignore 里误写了 composer.lock —— 这不是“可能出问题”，是“一定出问题”。
- 每次
composer update后，composer.lock必须手动git add并提交 - 对比变更时重点看三列：
version（是否跨大版本）、source（是否从 dist 切到 source）、require子项（是否有新增或删减） - 对
monolog/monolog、symfony/*、doctrine/*这类基础包，只要version从2.x变成3.x，就得立刻停下，查 changelog 是否含 BC break - 别信
composer show --outdated的 “(major)” 标记——它只看版本号，不看实际 API 是否变动
回滚不是靠 git checkout composer.lock，而是靠 reinstall + 锁定版本
单纯 git checkout 旧版 composer.lock 再 composer install，只适用于小范围变更。大批量升级出问题时，vendor 目录里可能已混入部分新包的 classmap，autoload 映射错乱，光换 lock 文件没用。
真正可靠的回滚动作是清现场、重安装、锁死版本。
- 删掉整个
vendor/和composer.lock - 用
composer install拉取上一个稳定 commit 对应的 lock 文件内容 - 若需快速恢复单个包，用
composer reinstall vendor/package-name，它按当前 lock 文件精确重装，不重新解析 - 临时锁定版本可写进
composer.json："require": {"vendor/package-name": "2.8.0"}，再composer update vendor/package-name
