直接改composer.json后运行update最危险，因会强制重算依赖图、跳过兼容性验证、掩盖平台冲突，导致CI失败；应先备份lock、删vendor、用install生成新lock并验证。

直接改 composer.json 然后跑 composer update 是最危险的升级起点——它会跳过兼容性验证、绕过锁文件比对、掩盖平台约束冲突，90% 的 CI 失败都源于这一步。

为什么不能直接改 composer.json 后运行 update

Composer 不是“改完就生效”的配置文件工具。composer.json 只是声明意图，真正决定装什么的是 composer.lock。直接改 composer.json + update 会强制重算整个依赖图，可能触发：

• 隐式降级：某个间接依赖因新约束被回退到不兼容旧版（比如 psr/log 从 3.x 退回 1.x）
• 平台误判：PHP 版本或扩展限制（如 ext-gd）在 update 过程中被忽略，直到 vendor/autoload.php 加载时报错
• 插件失效：自定义 installer 或事件监听器（如 pre-autoload-dump）因依赖版本突变而跳过执行

本地测试必须走 install 而非 update

目标是验证“新声明”能否在当前环境生成可运行的 vendor/，而不是让 Composer 自动调和新旧状态。正确流程是：

wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support

基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。

下载

• 备份原 composer.lock（例如重命名为 composer.lock.bak）
• 修改 composer.json 中目标包的版本约束（如 "guzzlehttp/guzzle": "^7.8" → "^8.0"）
• 删除 vendor/ 目录（不能只删部分子目录）
• 运行 php -d memory_limit=-1 composer install --no-interaction（加 --no-interaction 避免卡在交互提示）
• 检查输出是否有 Root package requires ... but it is not installable 或 Package x is abandoned

对比 lock 文件才能发现真实变更

composer install 成功后，新生成的 composer.lock 和旧版差异才是关键证据。重点关注：

• packages 和 packages-dev 下目标包的 version、source.type（应为 "zip"，不是 "git" 或 "path"）、dist.shasum
• platform 字段是否仍匹配你部署环境的 PHP 版本（如 "php": "8.1.26"）
• 是否有意外新增或消失的包（尤其 psr/*、symfony/polyfill-* 类轻量依赖）

测试失败时怎么快速回滚

别手动改 composer.json 或删 lock 行——残留字段会导致下次 install 仍拉错版本：

• 先执行 git checkout composer.lock.bak -- composer.lock（还原 lock）
• 再运行 composer install（重建 vendor）
• 确认测试套件 green 后，再针对性调整 composer.json，比如加 "--with-all-dependencies" 或显式 require 传递依赖

最容易被忽略的是：composer install 成功不代表自动加载就通——务必跑一次 composer dump-autoload --no-dev 并检查 vendor/autoload.php 是否能正常 require 你的核心类，否则 CI 里 --no-dev 模式下第一行就崩。