Composer不记录依赖的最后更新日期；lock文件中的time是下载快照时间，Packagist的publishedAt是版本发布时戳，二者均非本地升级时间，推荐用composer outdated检查版本过期。
Composer本身不记录依赖的最后更新日期
直接运行 composer show 或 composer list 都不会输出包的更新时间 —— Composer 的 lock 文件（composer.lock）只保存安装时的 commit hash、版本号和 dist/source 时间戳（即下载快照的时间），不是上游仓库的“最后更新日期”。你看到的 time 字段是该版本发布时 packagist.org 记录的 published at，不是你本地上次更新的时间。
查 Packagist 上的发布时间（最接近“最后更新日期”）
每个包在 Packagist 的元数据里有 publishedAt 字段，代表该版本被发布到 Packagist 的时间。这是你能合理获取的、最权威的“最后更新日期”来源：
- 用
composer show vendor/package --all查单个包所有已安装版本的time字段（即publishedAt） - 批量查全部依赖：运行
composer show --format=json | jq -r '.[] | "\(.name) \(.time)"'（需安装jq） - 注意：这个时间是 Packagist 收录该版本的时间，不是 GitHub/GitLab 仓库的 push 时间；如果包未及时同步，可能滞后
查本地 lock 文件中各包的安装快照时间
composer.lock 中每个包的 dist 或 source 下有 reference 和 time（如 "time": "2024-05-12T14:22:31+00:00"），这个 time 是 Composer 下载该归档/克隆该 commit 时记录的时间，可近似视为“你项目里最后一次拉取该版本的时间”：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 它不是 Git 仓库的 commit time，而是 Composer 执行 install/update 时写入 lock 的时间
- 用
jq '.packages[].time' composer.lock可提取全部时间（需按 package name 关联） - 如果执行过
composer update vendor/package而没 commit lock，这个时间会变，但你未必知道具体哪次更新了哪个包
想监控依赖是否过期？别依赖“日期”，用语义化检查
实际开发中，比“最后更新日期”更有意义的是“是否落后于最新稳定版”：
-
composer outdated --direct显示直接依赖中哪些有新版本（含版本号对比） -
composer outdated --major-only只看大版本更新，避免意外破坏 - 搭配
--format=markdown或--format=json方便脚本解析 - 真正需要“多久没更新”，建议结合 CI 脚本定期跑
outdated并告警，而不是靠时间戳判断 —— 很多维护良好的包半年发一次 patch，但每天都有 commit；反之，有些包 last updated 是昨天，但只是修了个 typo
日期字段容易误导，关键还是看版本兼容性与安全通告。lock 文件里的 time 和 Packagist 的 publishedAt 各有用途，但都不是“项目中某依赖上次被你主动升级的时间”——那个信息，Composer 没存。
