> ## Documentation Index
> Fetch the complete documentation index at: https://forgekit-docs-mintlify-4374fee9.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 用 radar 保持依赖时效

> forge radar 按时效性把依赖分组到同心圆里,让陈旧或漂移的依赖在咬人之前浮现。

<Note>
  `forge radar` 正在 v0.19 系列中落地。本指南描述它如何契合既有的依赖时效性纪律;请运行 `forge --help` 以确认你所安装版本中的可用性。
</Note>

Forge 的一条工程规则是:*在添加依赖之前,从实时来源核实当前最佳选项,并优先使用项目已经用了的东西。* `forge radar` 让依赖的当前状态可见,让这条规则有数据可依。

## 思路:时效同心圆

`forge radar` 按当前程度把项目的依赖分组到同心的**时效圆**里 —— 从中心的最新到边缘的陈旧或漂移。读这些环是回答"我们让什么漂移了?"最快的方法,不需要手工审计每个包。

```bash theme={null}
forge radar
```

## 依赖清单来自哪里

Radar 基于与 `forge stack` 相同的清单读取逻辑,后者从依赖清单中检测仓库的真实技术栈:

```bash theme={null}
forge stack     # languages, frameworks, package managers, real test commands
```

由于检测是数据驱动的、且跨生态(`package.json`、`pyproject.toml`、`go.mod`、`Cargo.toml`、`Gemfile`、`composer.json`、`pom.xml` / `build.gradle`、`*.csproj`)都失败开放,radar 可以对 `stack` 理解的同一批清单进行时效性推理。

## 在循环中使用它

<Steps>
  <Step title="在修改依赖之前查看这些环">
    在添加或升级依赖之前,运行 `forge radar` 看看已经有哪些依赖在漂移。
  </Step>

  <Step title="优先使用已经最新的依赖">
    如果一个能胜任、且当前的依赖已经在内圈里,就复用它,而不是再引入一个新依赖 —— 最小的贴合改动获胜。
  </Step>

  <Step title="记录决策">
    当你确实要升级或替换一个依赖时,记下原因:

    ```bash theme={null}
    forge decide "bump <dep> to <version> — <reason>"
    ```

    这样未来会话读到这个选择,而不是重新争论一遍。
  </Step>
</Steps>

<Warning>
  Radar 报告时效性,不替你升级。把它的环当作给人类决策的建议性输入 —— 并在称之为"完成"之前用仓库真实的测试 (`forge verify`) 校验任何一次升级。
</Warning>

<Card title="校验这次变更" icon="arrow-right" href="/zh-CN/cli/quality">
  依赖升级之后,运行 Quality 门 —— `forge verify` 和 `forge precommit`。
</Card>