Composer 本身不提供依赖包 EOL 的原生监控能力，仅按版本约束拉取包，不检查维护状态、PHP 兼容性或 Packagist 废弃标记；需借助外部工具（如 composer show --outdated、roave/security-advisories、composer-unused）和元数据源（Packagist、GitHub、PHP 官方支持表）协同识别 EOL 风险。
composer 本身不提供依赖包 EOL（End-of-Life）生命周期的原生监控能力。它只负责按 composer.json 中声明的版本约束拉取包，不会主动检查某个包是否已停止维护、PHP 版本是否过期、或 Packagist 上该版本是否被标记为废弃。
真正能感知 EOL 的，是外部工具 + 元数据源的组合 —— 你得自己搭这层“雷达”。
为什么 composer update 不会警告你依赖已 EOL
Composer 解析依赖时只看三件事：composer.json 的版本约束、composer.lock 锁定的精确版本、Packagist 返回的可用版本列表。它不查 PHP 官方支持周期，不读 Symfony 或 Laravel 的维护日历，也不对接 packagist.org 的“abandoned”标记（除非你显式启用）。所以即使一个包在 2025 年 12 月就终止维护了，只要它的 composer.json 还写着 "php": ">=7.4"，composer install 就照装不误。
常见错误现象：
- 项目还在用
monolog/monologv1.x，但官方早在 2023 年就 EOL，且不兼容 PHP 8.2+ 的某些类型提示 -
guzzlehttp/guzzlev6 已于 2023 年 10 月结束维护，但^6.5仍能通过composer require装上 - CI 流程通过，但上线后因底层包不支持新 PHP 版本而报
Fatal error: Uncaught TypeError
用 composer show --outdated + 外部元数据交叉验证
这是最轻量、无需额外工具的实操路径。核心思路：先让 Composer 列出可升级项，再人工或脚本比对是否属于已知 EOL 包。
执行命令：
composer show --outdated --direct
输出示例：
monolog/monolog 1.27.1 3.9.0 Sends logging messages to multiple handlers
接着你需要查：
- 访问 https://www.php.cn/link/6daab15a4f57549b7f236d7f0cfca3c8 → 看顶部是否有
abandoned标记（如monolog/monolog已标为 abandoned，推荐用monolog/monolog？不对，其实是它自己标自己废弃？等等 —— 实际是monolog/monologv1 是 abandoned，v2/v3 是主线） - 查该项目 GitHub 的 README 或 Releases 页面，确认 v1.x 最后一个 tag 时间（如
v1.27.1发布于 2022-03-15） - 对照 PHP 官方支持表：PHP 7.4 EOL 是 2022-11-28，而 monolog v1.x 声明
"php": ">=5.3.0"，但它实际测试矩阵早已停在 7.4
⚠️ 注意：--direct 很关键 —— 否则你会看到几十个间接依赖，干扰判断；EOL 风险主要来自你 require 的顶层包，不是它们的子依赖。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
集成 roave/security-advisories 和 composer-unused 做被动防御
这两个包不能直接告诉你“这个包 EOL 了”，但能大幅降低因 EOL 引发的实际风险。
roave/security-advisories 是一个“禁止清单”式依赖：它把所有已知有安全漏洞、且无修复版本（即事实 EOL）的包版本，以 conflict 形式写死。一旦你的项目依赖了其中任一组合，composer update 就会失败。
安装方式：
composer require --dev roave/security-advisories:dev-latest
composer-unused 则帮你发现“已 EOL 且没人用”的包：它扫描你的代码，找出 require 了但从未 use 或 new 的包 —— 这类包往往就是历史遗留、早已弃用、却还躺在 composer.json 里的“僵尸依赖”。
安装并运行：
composer require --dev composer-unused/composer-unused vendor/bin/composer-unused
它不会告诉你某包是否 EOL，但能帮你快速识别出那些“连自己代码都不用了，还留着干啥”的嫌疑对象 —— 这类包十有八九就是 EOL 后被遗忘的。
真正要盯住的，是 PHP 版本和包自身 php 约束的错位
很多 EOL 问题本质不是包死了，而是你 PHP 升级了，而包没跟上。比如你从 PHP 8.1 升到 8.3，但 symfony/console v5.4 只声明 "php": ">=7.2.5"，没提 8.3 兼容性 —— 它可能跑得动，也可能某天突然 fail。
检查方法：
- 运行
composer show symfony/console，看其requires里php字段值 - 查该包对应版本的
composer.json原始文件（如 GitHub tag v5.4.42 的根目录下） - 对比 PHP 官方支持周期：PHP 8.3 支持到 2027-11，若包未声明
"php": "^8.3"或类似，就得手动验证
最容易被忽略的一点：Packagist 上显示的 php 约束，是该包**发布时**填的，不是实时检测结果。哪怕它现在在 PHP 8.3 下崩了，只要没发新版，约束就不会变。
