forge radar 正在 v0.19 线路上落地。这份指南描述它如何嵌入现有的
依赖新鲜度纪律；在你安装的版本里可用性以 forge --help 为准。forge radar 把你依赖的
当前状态可视化出来，好让这条规则有数据支撑。
想法：新鲜度环
forge radar 按每个依赖有多”新”把项目的依赖分到一圈圈新鲜度环里 ——
从中心的最新，到边缘的陈旧或漂移中。读这些环是一种快速回答
“哪些东西我们让它漂了？“的方法，不用一个包一个包地手工审计。
依赖列表从哪来
Radar 建立在同一套清单读取之上，它也是forge stack 的动力，后者从
仓库的依赖清单文件里探测它真实的技术栈：
package.json、
pyproject.toml、go.mod、Cargo.toml、Gemfile、composer.json、pom.xml /
build.gradle、*.csproj）上是安全失败的，radar 可以对 stack 认得的
同一批清单进行新鲜度推理。
在循环中使用它
1
改依赖之前先看看这些环
在添加或升级依赖之前，先跑一下
forge radar，看看哪些依赖
已经在漂了。2
优先用已经新鲜的
如果一个能胜任、又已经很新鲜的依赖已经在内圈里，那就复用它，
而不是再加一个新的 —— 最能合身的最小变更胜出。
3
把决定记下来
当你确实要升级或替换一个依赖时，把原因记录下来：这样将来的会话读到这份记录，而不是重新纠结一遍。
验证变更
依赖升级之后，跑一遍 Quality 门 ——
forge verify 和 forge precommit。