> ## Documentation Index
> Fetch the complete documentation index at: https://forgekit-docs-mintlify-9e781f1d.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     # 语言、框架、包管理器、真实的测试命令
```

因为检测是数据驱动、且在各生态系统间安全兜底(`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-Hans/cli/quality">
  一次依赖升级之后,跑一遍 Quality 关卡——`forge verify` 和 `forge precommit`。
</Card>