THREE.Cache enabled for repeat loader requests vs. disabled for mid-session asset freshness

An application uses TextureLoader and GLTFLoader to pull assets into a three.js scene, and the art pipeline can publish updated textures or models while users remain connected. The documented choice is between enabling THREE.Cache to short-circuit repeated FileLoader requests for the same URL, or leaving it disabled so later loads are not blocked by the in-memory map. Enabling the cache improves load performance but introduces a manual invalidation burden because Cache.files has no TTL, revalidation, or automatic purge; a changed server file stays invisible until Cache.remove(url) or Cache.clear() runs. Leaving the cache disabled avoids that in-memory staleness, yet it does not guarantee a fresh network response because the browser HTTP cache still applies independently. Loader behavior and defaults can differ across three.js releases, so the exact lookup path should be confirmed for the installed version.

Which invalidation strategy is appropriate when asset updates must appear mid-session without forcing a full page reload? Does appending a version query string to asset URLs provide sufficient invalidation across TextureLoader and GLTFLoader when THREE.Cache is enabled? How can an application detect that a cached entry is stale when neither THREE.Cache nor the browser exposes revalidation metadata?