GitHub 报告的依赖检测结果可能与其他工具返回的结果不同。这背后有充分的理由，了解 GitHub 如何为您的项目确定依赖关系十分有帮助。
依赖关系图是否只在清单文件和锁文件中查找依赖？
依赖关系图会自动包含您环境中明确声明的依赖信息。也就是说，清单文件或锁文件中指定的依赖会被记录。依赖关系图通常还会包括传递依赖，即使它们未在锁文件中列出，系统也会通过检查清单文件中依赖的依赖来捕获这些传递依赖。
依赖关系图不会自动包含“松散”依赖。“松散”依赖指的是直接从其他来源复制到仓库中，或放在压缩包（如 ZIP 或 JAR 文件）内部的单个文件，而不是通过包管理器的清单或锁文件进行引用的依赖。
不过，您可以使用依赖提交 API将依赖添加到项目的依赖关系图中，即使这些依赖未在清单或锁文件中声明，例如在项目构建时解析得到的依赖。通过依赖提交 API 提交的依赖会显示使用了哪种检测器以及提交的时间。有关依赖提交 API 的详细信息，请参阅 使用依赖提交 API。
检查：缺失的依赖是否来自仓库清单或锁文件中未指定的组件？
依赖关系图是否能检测使用变量指定的依赖？
依赖关系图会在清单文件推送到 GitHub 时进行分析。因此，它无法访问项目的构建环境，也就无法解析清单中使用的变量。如果您在清单中使用变量来指定依赖的名称，或更常见的版本号，则该依赖不会自动出现在依赖关系图中。
不过，您仍可通过依赖提交 API 将这些仅在构建时解析的依赖添加到项目的依赖关系图中。有关依赖提交 API 的详细信息，请参阅 使用依赖提交 API。
检查：缺失的依赖是否在清单中通过变量来声明其名称或版本？
是否存在影响依赖关系图数据的限制？
是的，依赖关系图对其将处理的清单文件的大小、数量和位置都有限制。
这些处理限制会影响 GitHub 中显示的依赖关系图，并且会阻止生成 Dependabot 警报。
大于 10 MB 的清单文件会被忽略，且不会生成 Dependabot 警报。
默认情况下，GitHub 每个仓库最多处理 150 个清单文件。超出此限制的清单不会触发 Dependabot 警报，且若超过该限制，Dependabot 警报的行为可能变得不可预测。
存放在通常用于供应商依赖的目录中的清单文件将不会被处理。名称匹配以下正则表达式的目录会被视为供应商依赖目录：
(3rd|[Tt]hird)[-_]?[Pp]arty/(^|/)vendors?/(^|/)[Ee]xtern(als?)?/(^|/)[Vv]+endor/
示例
- third-party/dependencies/dependency1
- vendors/dependency1
- /externals/vendor1/dependency1
我的依赖看起来不对，我该怎么办？
如果项目的依赖表未准确反映仓库中的清单文件，您可以触发重新构建依赖关系图。
在仓库的 Dependabot 选项卡中，点击警报列表顶部的按钮。从下拉菜单中选择 刷新 Dependabot 警报。系统将把一次后台任务加入队列，以处理仓库的清单文件、检测任何新出现或变更的依赖，并更新警报。
注意
您需要拥有管理安全警报的权限才能刷新仓库的依赖关系图。有关配置此权限的信息，请参阅 管理仓库的安全和分析设置。为进一步降低滥用风险，刷新 Dependabot 警报选项每个仓库每小时只能触发一次。
点击 刷新 Dependabot 警报仅会扫描清单文件。如果您的依赖关系图还包括通过依赖提交 API 提交的构建时依赖信息，重新运行生成并提交依赖信息的 Action 或外部进程也会触发仓库依赖关系图的重建。有关依赖提交 API 的更多信息，请参阅 使用依赖提交 API。
如果您使用自动依赖提交，推送更新了仓库清单文件的提交将触发自动提交 Action 运行。
在所有情况下，警报列表顶部的时间戳均表示依赖关系图最近一次构建的时间。