packagist 包的 time 字段是作者在 composer.json 或 git tag 中声明的发布时间，并非安装时间，不可靠；应通过官网“last update”或 api 查询，且不能单凭 time 判断包是否过期。
Composer 包的 time 字段不是安装时记录的本地时间，而是包在 Packagist 上注册时由其元数据（composer.json 中的 time）或 Packagist API 返回的发布时间 —— 它不可靠，也不反映你实际安装/更新的时间。
怎么看 Packagist 上包的发布时间？
Packagist 官网页面（如 https://packagist.org/packages/vlucas/phpdotenv）右上角显示的 “Last update” 是最直观来源，但它其实是该包最新版本的 time 值，来自其 composer.json 或 GitHub/GitLab 的 tag 时间。这个字段由包作者维护，可能被手动修改、填错，甚至留空（此时 Packagist 会 fallback 到 Git tag 的提交时间）。
实操建议：
- 打开
https://packagist.org/packages/{vendor}/{package}，直接看 “Last update” - 用 API 查：运行
curl -s "https://packagist.org/packages/{vendor}/{package}.json" | jq '.package.time'（需安装jq），注意返回的是最新稳定版的time - 如果包未显式声明
time，Packagist 会从 VCS tag 提取 —— 所以它本质是 Git tag 的authored date，不是发布动作发生时间
为什么 composer show 不显示 time？
composer show 默认只展示已安装包的本地元信息（如 name、version、source），不请求远程 Packagist 数据，所以不会输出 time。它读的是 vendor/composer/installed.json，而这个文件里压根没存 time 字段。
常见错误现象：
- 执行
composer show vlucas/phpdotenv --all仍看不到time - 误以为
composer show --outdated会附带发布时间，其实只比对版本号
想临时查某个已安装包的发布时间，只能回源：去 Packagist 页面或调 API，别指望本地命令。
如何判断一个包是否“过期”？别只看 time
单看 time 容易误判。比如一个包三年没发新 time，但仍在维护安全补丁（通过分支更新）；另一个包每月都有新 time，却只是自动化 CI 推的无意义版本号 bump。
更有效的做法：
- 检查
composer show {package} --all输出里的source地址，点进去看 GitHub/GitLab 的最近 commit 和 issues 活跃度 - 用
composer outdated --direct看是否落后于稳定版，再结合 Packagist 的 “Latest version” 对比 - 关注
security-advisories：运行composer audit（Composer 2.5+）或装roave/security-advisories，时效性比time更关键
自定义脚本抓取多个包的发布时间？小心限流和结构变化
Packagist API 有速率限制（约 10–20 请求/分钟），且响应结构可能随版本微调（例如 .package.time 在 v2 API 中变为 .package.versions.*.time）。直接循环调 API 容易失败。
实操建议：
- 优先用
composer show+ 手动查关键包，别写全量扫描脚本 - 真要批量查，加
sleep 3间隔，并捕获 HTTP 429 错误 - 别解析 HTML 页面 —— Packagist 不承诺前端结构稳定，API 才是唯一正路
- 注意：私有仓库（如 Satis、Private Packagist）的
time行为可能不同，得查对应服务文档
真正影响项目稳定的，从来不是某个 time 字段的数字，而是你依赖的版本是否还在维护周期内、有没有已知未修复漏洞、CI 是否能正常构建。Packagist 上那个时间戳，最多帮你快速排除明显停更的包 —— 别当真，也别太信。
