registry:2仅是底层存储网关，缺乏鉴权、审计等管理能力，需自研控制面做策略代理；权限用rbac即可，元数据应异步同步，存储后端需抽象适配。
为什么不用 registry:2 直接当私有镜像仓库用
因为 registry:2 本身不提供鉴权、审计、镜像扫描、多租户隔离这些内部管理必需的能力，硬加 nginx 或 htpasswd 只能解决基础登录，但无法控制谁拉取哪个命名空间、谁可以推送 latest 标签、谁的操作被记录——这些得自己写逻辑。
Go 适合做这类工具：二进制单文件部署方便，标准库对 HTTP、JSON、Docker Registry API 支持直接可用，不需要额外 runtime。
- 别把
registry:2当成“仓库服务”，它只是底层存储网关；你的管理工具才是真正的“仓库控制面” - 所有鉴权、配额、策略检查必须在调用
registry:2前完成，不能依赖它的中间件或后端插件（它没这个设计） - 注意
registry:2的DELETE接口默认关闭，要启用需配置storage.delete.enabled=true，否则你写的“删除镜像”功能永远 405
怎么对接 Docker Registry v2 API 做代理转发
核心不是重实现 registry，而是做带策略的反向代理：解析请求路径（如 /v2/myapp/nginx/manifests/latest），提取 repo 和 reference，查权限，再透传给后端 registry。
关键点在于保留原始 header（尤其是 Docker-Distribution-API-Version、Authorization）和正确处理 401 挑战响应——registry 返回 WWW-Authenticate 时，你的服务不能吞掉，得原样透传，否则 docker client 会卡住。
立即学习“go语言免费学习笔记（深入）”；
dboxShare 是一款简便易用的免费开源企业网盘，基于 .NET 技术开发，用于构建安全高效的文件云存储及云管理平台。 用户无需改变工作习惯，文件双向同步将会根据相应的权限自动进行上传、下载及版本更替，为共享协作提供便捷高效的解决方案。 系统具有安装简单、部署灵活和维护量小的特点，适用于企业组织及团队搭建安全高效的私有云网盘。
- 用
httputil.NewSingleHostReverseProxy而不是手写http.Client，它自动处理 host rewrite、header 传递、upgrade 协议（比如 blob upload 的 chunked） - 拦截
RoundTrip时只改req.URL.Host和必要 header，别动req.Header里的Authorization——鉴权是你自己做的，registry 后端不需要再校验 - 对
GET /v2/这类根路径健康检查请求，可直答 200，避免每次都打到后端 registry
用户权限模型该用 RBAC 还是 ABAC
RBAC 够用且好维护。内部私有云场景下，角色通常就几种：admin（全库读写删）、developer（自己命名空间 push/pull）、auditor（只读所有镜像元数据）。ABAC 在这里反而增加复杂度，比如基于镜像 label 做策略，实际没人真这么用。
重点不在模型选型，而在权限检查的时机和粒度：
- 必须在每个 registry API 路径上做检查：
GET /v2/{name}/manifests/{reference}是 pull，PUT /v2/{name}/manifests/{reference}是 push，DELETE /v2/{name}/manifests/{reference}是删——不能只在入口做一次鉴权 - 命名空间（
{name}）解析要防路径遍历：../../etc/passwd这种字符串必须在解析阶段就被拒绝，别等拼进 URL 再发请求 - 别把 token 存数据库里做 session 管理；用
jwt-go签发短期 token，payload 里直接塞role和namespaces列表，省去每次查 DB
镜像元数据同步和 GC 怎么不阻塞主流程
registry 本身不暴露镜像列表的可靠接口（_catalog 分页不稳定，且不包含 manifest digest），所以你的管理工具得自己存一份元数据快照：镜像名、tag、digest、push 时间、大小、uploader。但写入不能在 push 请求链路里做——否则一个大镜像上传几小时，你的元数据入库就卡住整个连接。
做法是：收到 PUT /v2/{name}/manifests/{reference} 成功后，异步投递一个消息（哪怕只是内存 channel 或简单 goroutine）去解析 manifest、fetch config blob、存 DB。失败了也别回滚 registry 操作，只记 error 日志。
- GC 不要主动扫 registry 存储目录；等你的元数据 DB 里发现某 digest 已无任何 tag 关联，再调用 registry 的
DELETE /v2/{name}/manifests/{digest} - DB 字段必须建复合索引：
(name, tag)用于 tag 覆盖检测，(digest)用于 GC 查重，否则列表页加载慢、GC 脚本跑一天 - 别用
time.Now()记 push 时间；从 manifest 的created字段（config blob 里）取，更准确，且能跨 registry 迁移时保持一致
最麻烦的其实是 registry 存储后端类型混用：本地磁盘、S3、Azure Blob——每种的 list/batch delete 行为差异很大，这部分抽象层一旦没设计好，后面换对象存储就得重写半套代码。
