摘要

  • Docker 当前运行文档列匿名用户 100 次／六小时、已登录 Personal 用户 200 次／六小时；价格 FAQ 写匿名每 IP 每小时 10 次、Personal 每用户每小时 100 次。
  • Docker 的 2025 年 4 月 8 日更新明确说，原定 4 月 1 日的限流变更没有执行。两套公开时钟会把同一次采购讨论带向不同的容量假设。

开发团队最不需要的额外任务，是在供应商官网上解一道时间应用题。Docker Hub 的运行文档把免费拉取额度写成六小时窗口，价格 FAQ 却按小时回答。这两只钟都挂在 Docker 自己的墙上。

截至此次查阅，运行文档中的匿名额度是每个 IPv4 地址或 IPv6 /64 子网六小时 100 次，已登录 Personal 用户六小时 200 次。价格 FAQ 则写着，匿名用户每 IP 每小时 10 次，已登录 Personal 用户每用户每小时 100 次。数量和时间单位一起换了，不能当作两种排版。

撤回的变更，仍需要一条清楚的出口

Docker 的《Revisiting Docker Hub Policies》发表于 2025 年 2 月 21 日，并在 4 月 8 日增加更新：原定 4 月 1 日执行的限流变更没有执行，匿名 100 次、Personal 200 次的六小时额度继续保留。今天的运行文档与这条说明一致。

价格 FAQ 的小时数字仍在。页面还把读者引向运行文档与政策更新。于是，采购入口、操作说明和有日期的纠正并没有给读者同一个答案。要拼出供应商已经公开表达的状态，读者得自己走完这条链接链。

公开页面 匿名用户 已登录 Personal 用户
当前运行文档 每 IPv4 或 IPv6 /64 六小时 100 次 六小时 200 次
当前价格 FAQ 每 IP 每小时 10 次 每用户每小时 100 次
2025 年 4 月 8 日更新 保留六小时 100 次 保留六小时 200 次

这个表证明的是公开说明存在冲突。它没有测量任何团队的端点响应。买方实际构建路径上的当前额度响应或响应头，能确定该客户端拿到的额度，并可能改变容量安排。

把小时数字乘六也解决不了问题。一个小时能承受的峰值、跨更长窗口累计的用量，以及任务什么时候集中发生，会产生不同的排队结果。平均值看起来顺眼，构建开始的那一分钟却不认识平均值。

小单位，会带着大采购走错门

免费额度是一笔有条件的生产投入。团队用它估计构建什么时候能开始、哪些任务要排开、何时值得购买付费计划。数字越接近采购入口，越容易直接进入表格，继而成为审批理由。时间单位如果来自另一套页面，后面的计算可以全部正确，前提仍然错位。

这里的成本首先是人的工作：解释两个页面、改容量假设、重新安排任务，再决定是否购买。同一个供应商让购买者面对两种公开口径，而操作团队必须选用一种可执行的口径。

付费也有自己的范围。运行文档把已登录的 Pro、Team、Business 普通镜像拉取率列为不设次数上限，同时保留合理使用条件。另有防滥用限流，按 IPv4 地址或 IPv6 /64 统计网络来源，适用于各账户等级，阈值随负载等因素变化。

因此，购买理由必须指向实际约束。普通拉取额度、身份归属和网络来源的防滥用限制，分别回答不同的问题。把官网时钟读错后直接升级，可能把采购带到另一个边界上；增加付款本身不会替团队辨认原来的问题。

让一条政策走完到读者的最后一段路

Docker 控制套餐、说明和执行规则。客户控制购买决定与获得授权的身份使用；第三方构建平台可能控制共享出口。承担构建等待的团队，则要把这些东西接成一条工作路径。公开数字不一致时，供应商节省的页面整理工作，会成为买方重复进行的解释工作。

修正这一处冲突的商业价值很朴素：让购买者不用在销售语境和运行语境之间猜测。把有效时间窗口、计量对象和已撤回变更放在同一条清楚的说明中，就能减少错误前提进入排程与采购的机会。无需一个新的仪表盘来解释另一个旧问答。

开发工具卖的是少花一些协调时间。容量规则是这份交易的一部分。Docker 已经公开写下了没有执行那次变更的日期；让相邻的购买页面跟上，比要求每个构建团队兼职做官网考古更划算。

来源