在讲 SAP UI5 的 Cache Buster 之前，先把问题本质讲清楚：浏览器缓存的目标是快。一旦某个静态资源被缓存（例如sap-ui-core.js、Component-preload.js、i18n.properties、manifest.json，甚至某些OData元数据），下一次访问时浏览器可能直接从 memory cache 或 disk cache 读取，连网络请求都不发。对用户体验来说这很美好，对发布来说却很危险：你明明已经上线了新版本，部分用户却仍在运行旧版本资源，甚至出现新旧资源混跑导致的诡异报错（模块找不到、函数签名不一致、绑定路径突然失效、控件渲染异常等）。
很多团队一开始会走一条看似直接的路：把所有资源都设置Cache-Control: no-cache或max-age=0，每次都让浏览器去服务器校验。这能降低拿到旧资源的概率，但代价是每次启动都会产生大量请求与协商（典型是304/NOT MODIFIED），在 UI5 这种模块化加载、资源数量多的框架里，网络往返成本会被放大，最终伤的是启动性能与稳定性。OpenUI5 的文档就明确指出：默认的缓存策略要么是缓存一段时间，要么在开发模式使用304/NOT MODIFIED做校验，但在最终生产场景并不理想，这也是引入 Cache Buster 机制的根本原因。 (
