不能直接看出，但可通过 composer show 的 source 和 homepage 字段跳转 GitHub 查看最新提交时间及内容，结合 Packagist 的 abandoned 标识、依赖版本陈旧度、tag 间隔与安全补丁缺失等综合判断是否停更。
composer show 能看出包还在维护吗？
不能直接看，但能拿到关键线索。执行 composer show vendor/package-name 后，重点盯两个字段：source 和 homepage——它们通常指向 GitHub 仓库地址。别只扫一眼 README，点进去后立刻看右上角「Latest commit」和顶部「Updated X days ago」。如果超过 12 个月没提交，且最近几次提交里没有 security、fix、chore(deps) 这类关键词，基本可判定事实停更。
常见错误现象：
- 只看 master 或 main 分支，忽略作者已切到 dev 或 next 分支持续开发；
- 把 fork 的仓库当原仓，误判活跃度；
- 看到有 PR 就以为项目活，其实作者半年没合并过一个。
Packagist 页面比命令行更准？
是的，Packagist 是 Composer 的元数据源，它的 Last update 时间戳反映的是真实发布节奏，比 GitHub 提交更贴近“是否还在管这个包”。访问 https://www.php.cn/link/84ff7015cca989303244d13f1a8146fd，注意三处：
- 是否有
This package is abandoned标识——有就立刻换； -
Requires里是否还锁着php: ^7.2或symfony/console: ^4.4——说明作者没跟进主流生态； - 版本历史里最近三次 tag 间隔是否超 18 个月，且无
security类 patch 版本。
使用场景：CI 流程中做依赖健康检查时，应优先抓 Packagist API（/packages/{vendor}/{package}）而非仅靠本地命令，避免缓存偏差。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer outdated 为什么有时不报过时？
因为它默认只比对「当前版本约束范围内」的最新稳定版，不是比对绝对最新版。比如你锁了 "monolog/monolog": "^2.8"，而作者已发 3.0.0，composer outdated 默认不显示——它认为主版本升级超出允许范围。
实操建议：
- 加 --all 强制列出所有更高主版本（含 3.x），但要人工判断 BC-breaking 风险；
- 加 --direct 缩小范围，只看你自己写进 composer.json 的依赖，避免被间接依赖淹没；
- 如果输出为空，先运行 composer update --lock 刷新锁文件，再试；
- 某些包显示 dev-main → dev-main，说明你用的是开发分支，outdated 压根没法比，得手动查对应分支的 commit 时间。
怎么发现“表面更新、实际废弃”的包？
最可靠的信号是 Packagist 上明确标出 abandoned，但有些包没标，却早已无人响应 Issue 和 PR。这时得人工验证：
- 打开 GitHub 的
Issues标签页，看近 6 个月是否有 closed issue —— 如果全是 open 状态，且作者没 comment 过，基本等于失联； - 点开
Pull requests，看 merge rate：如果 PR 平均等待超 90 天，或最近一次 merge 是 2024 年，风险极高； - 搜
composer audit输出里有没有该包——即使版本新，也可能存在未修复 CVE，而outdated完全不报这类问题。
容易踩的坑：把“有新 release”等同于“有人维护”。有些包靠自动化脚本每月打 tag，但从不看 Issues，也不修 bug。真要确认，得看 commit author 是否还是原作者，以及最近三次 commit 是否都带 meaningful message。
