企业级项目选包必须以packagist和composer show -a的last update为硬性门槛，超6个月未更新即标记观望，ci应拦截；abandoned包立即替换；conflicts含php:>=8.3而项目用php8.3表明已放弃兼容；security提交超12个月视为事实停更；composer outdated --direct须集成ci并设非0退出码中断构建；镜像源延迟需执行composer update --refresh验证真实状态；活跃度核心是响应issue、合并pr、发布security patch，非表面commit。
企业级项目不能靠“下载量高”或“GitHub star 多”选包，必须把第三方包的更新周期和维护活跃度变成可校验、可阻断的硬性门槛。
composer show -a 和 Packagist Last update 是唯二可信信号
别信 README 里写的“actively maintained”，也别翻 commit 记录数——真正能快速验证的只有两个字段：composer show -a vendor/package-name 输出里的 Last update（来自 Packagist 元数据），以及 Packagist 页面右上角那个实时刷新的 Last update 时间戳。
- 两者都超 6 个月没动 → 直接标记为“观望”，CI 中应拦截安装
- Packagist 显示
This package is abandoned→ 立即替换，不接受任何例外 -
composer show -a中conflicts字段含php: >=8.3但当前项目用 PHP 8.3 → 表明作者已放弃兼容，不是“还没适配”，而是“不再适配”
GitHub commit 时间必须查真实分支，且看 security/fix 提交
打开 composer show 返回的 source 或 homepage URL，重点不是 master/main 分支顶部的“Updated X days ago”，而是直接点进 commits 标签页，筛选 security、fix、patch 关键词。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 最近一次
security提交距今超 12 个月 → 基本可判定事实停更 - main 分支无动作，但
dev或next分支有近期fix提交 → 需确认该分支是否被 Packagist 收录为稳定版本（查 Packagist 的 version history） - commit 消息全是 Merge pull request #xxx → 不算活跃，要看 author 是否为真实维护者，而非 CI bot
composer outdated --direct 必须集成到 CI 流水线
企业 CI 中不能只跑 composer install 就完事。每天至少一次执行 composer outdated --direct --minor-only，并设置退出码非 0 时中断构建。
- 输出为空 ≠ 安全，需检查
minimum-stability是否设为stable导致过滤掉安全补丁版 - 若输出含标
security的包，必须人工确认：是已知漏洞但无修复？还是作者已发 patch 但未打 tag？ - 搭配
composer update --dry-run验证升级可行性，避免因间接依赖锁死导致实际无法升
镜像源同步延迟会导致活跃度误判
阿里云、腾讯云镜像虽快，但存在小时级同步延迟。如果 Packagist 已更新，而 composer outdated 没反应，不能直接判定包已停更——得先刷新元数据。
- 执行
composer update --refresh（要求 Composer ≥ 2.5）强制重载镜像源的packages.json - 再跑
composer outdated --direct，此时结果才反映真实状态 - 若仍无更新，且 Packagist 页面显示新版本已发布超 24 小时 → 可信度大幅上升，视为真实停滞
最易被忽略的是：活跃度不是“有没有人提交”，而是“有没有人响应 issue、合并 PR、发布带 security 标签的 patch”。一个包可能每月都有 commit，但全是文档 typo 修正或 CI 脚本调整——这种“假活跃”比完全沉默更危险，因为它掩盖了实质维护缺失。
