Composer通过向Packagist API请求元数据检查"abandoned"字段发现包被废弃，该字段由作者显式设置为true、替代包名或空；镜像缓存可能导致警告延迟，需切官方源验证；warning不中断安装但CI易忽略，建议用--fail-on-warning或grep校验；lock文件中"abandoned"字段为写死快照，grep -A1 -B1 '"abandoned"' composer.lock最准；"Use xxx instead"仅同步Packagist字段，可能过时、模糊或缺失，唯一权威来源是Packagist页面右上角「Replaced by」横幅。
Composer 怎么发现包被废弃了
它不是靠猜，也不是扫描代码，而是每次执行 composer install 或 composer update 时，主动向 Packagist API 请求依赖包的元数据，检查其中 "abandoned" 字段。这个字段由包作者在 Packagist 后台或通过 API 显式设置，值可能是 true（彻底废弃）、字符串（如 "guzzlehttp/guzzle"，表示官方推荐替代），也可能是空。
注意：镜像源（如阿里云、腾讯云）可能缓存旧元数据，导致警告延迟出现或消失。若怀疑误报，可临时切回官方源验证：composer config -g repo.packagist composer https://packagist.org。
为什么 warning 不中断安装，但 CI 里容易被忽略
这条提示是 notice 级别，exit code 仍是 0，所以 shell 脚本里 && 不会断，CI 日志也可能被折叠或重定向吞掉。更危险的是——composer require 默认不触发该检查，你升级某个包后悄悄引入了废弃子依赖，却完全没看到警告。
建议在 CI 中显式启用阻断：composer install --fail-on-warning（Composer 2.5+ 支持），或用 grep -q "is abandoned" composer.log 做后置校验。
废弃状态在 lock 文件里怎么存的
composer.lock 里每条包记录都可能带 "abandoned": true 或 "abandoned": "new/vendor" 字段，这是 Composer 解析远程元数据后写死的快照。它不可篡改，也不随本地 vendor 目录变动而变化——哪怕你手动删了那个包，只要 lock 文件里还记着，下次 install 就仍会报。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
查证最稳的方式是：grep -A1 -B1 '"abandoned"' composer.lock。如果输出为空，说明当前锁文件里没记录废弃状态；若有，则代表该包在解析那一刻已被标记。
警告里写的 “Use xxx instead” 可信吗
不可全信。这行文字只是原封不动抄了 Packagist 页面上维护者填的 replaced by 字段，而这个字段可能：
- 过时：比如指向一个已同样被废弃的新包
- 模糊：写成
"psr/log"这种接口，而非具体实现 - 缺失：作者只标了
abandoned: true，根本没填替代项
唯一权威来源是打开 https://packagist.org/packages/vendor/package-name 页面，看右上角「Replaced by」横幅。它不会骗人，也不会缓存错。
真正麻烦的不是警告本身，而是废弃包往往藏在子依赖深处，且它的替代者可能连命名空间都变了——use Old\Class 换成 use New\Namespace\Class 这种事，不 grep 全局代码根本发现不了。
