AngusRepo应用场景有哪些？

AngusRepo 管的是制品流转的三个环节。构建时，把外部依赖缓存在内网，构建更稳更快。发布时，把团队自己构建的包和镜像集中放在一处，流水线用专门的令牌推包。使用依赖时，让有高危漏洞的包拉不走，引入新依赖前也能先查一下风险。大多数团队会先从 Maven 和 Docker 开始，跑顺之后再加 npm、PyPI 等其他格式。

下面分别说怎么做。

构建时

1. 外部依赖缓存在内网

适合公网不稳定、构建经常卡在下载依赖的团队。

给 Maven Central、Docker Hub 这些外部源各建一个代理库，再用组库把托管库和代理库合成一个拉取地址，托管库排在前面。开发机和流水线安装时指向这个组库。推包仍用托管库的地址。

第一次构建时，依赖会从外面下载并缓存在内网；之后再用到同一个版本，就直接从内网取，构建不用每次都等公网。开发机和流水线也只需要记住一个地址。

发布时

2. 团队自己的包和镜像集中放在一处

适合 Java 包、前端包和 Docker 镜像分散在不同地方、地址各记各的团队。

给 Maven 和 Docker 各建一个托管库，在仓库设置页复制地址。Maven 把地址写进 settings.xml，Docker 先 docker login，然后照常 mvn deploy、docker push。开发机上的命令不用改，改的只是地址和登录方式。

做完之后，团队自己的 jar 包和镜像都在同一个产品里，可以按坐标搜索，也能看到谁在什么时候推了哪个版本。旧版本越积越多时，用「清理」按规则处理。先预览，试运行不会删除，确认之后再删。

3. 流水线用专门的令牌推包

适合流水线还在用个人账号密码推包的团队。

在要推包的仓库详情「安全」里生成一个 Deploy Token，它只对这一个仓库有效，填在构建工具的密码位。个人密码就可以从构建配置里拿掉了，人和流水线各用各的凭据，权限也更小。如果填成了登录密码，常见报错是 401 invalid_token，换成令牌就好。

使用依赖时

4. 不让有高危漏洞的包被拉走

适合希望包进库之后还能把住一道关的团队。

在「安全」页给托管库打开推送时扫描或定时扫描，再打开阻断下载，设一个严重级别，例如高危。之后超过这个级别的包仍然留在库里，但客户端拉不下来，等修复版本推上来再放行。还没扫描过的包，阻断不会替你判断，先别当成没有问题。需要给客户或审计方交材料时，可以导出软件物料清单（SBOM）。

5. 引入新依赖前先查一下风险

适合开发者在 Cursor、Claude 或 VS Code 里写代码，想在加依赖之前先确认安不安全的场景。

连上 AngusRepo 之后，直接问「这个包有没有已知漏洞、用的什么许可证」，助手会从制品库里查出已经扫过的依赖、许可证和漏洞数量。库里还没有这次扫描时，先别当成没有问题。确认之后再加进项目，拉包仍用原来的 mvn、npm 或 docker。

怎么开始：从两个格式到整条交付链路

不用一次把所有格式都迁过来，可以按四步慢慢扩展。

1. 先托管 Maven 和 Docker：各建一个托管库，推一个内部包、一张测试镜像，确认地址和令牌都没问题。
2. 加上依赖缓存：建代理库和组库，把开发机和流水线切到组库地址。
3. 流水线改用 Deploy Token：把个人密码从构建配置里拿掉。
4. 打开安全扫描并扩展格式：给关键仓库打开扫描和阻断下载，再逐步加入 npm、PyPI、Helm 等其他格式。

每个菜单的用途见同系列「AngusRepo 支持哪些功能」。

文档：https://www.anguskit.com/zh/docs/repo

AngusRepo 核心解决制品存储、依赖代理与发布管控问题。

构建时配置为私有源，缓存公网依赖加速下载，同时托管内部模块版本，确保构建环境一致可复现；发布时通过 CI 自动推送制品，结合权限策略限制覆盖写入，保障版本不可篡改；使用依赖时统一从 AngusRepo 拉取，避免直连外部源带来的安全与稳定性风险。

团队一般从搭建私有仓库并迁移现有构建配置开始，先接入一个试点项目验证代理缓存和发布流程，再逐步替换所有项目的依赖源。初期重点梳理高频使用的公共组件和内部模块，建立命名规范与版本策略，后续再扩展权限分级、漏洞联动等高级能力，避免一步到位导致落地阻力过大。

官方详细解决方案：https://www.aliyun.com/product/list/alibabacloudnative