@NewYear 设置 max-age=0 肯定不是抬杠，如果大于 0 ，那么浏览器就自动默认资源在有效期内，是不会发起网络请求的。

这时候就算你把验证的 integrity 值给修改了，network 面板也不会有新的请求发起。

唯一变化就是资源认证不通过，加载失败。

@ryd994 你说的 immutable 就是彻底相信 max-age ，js 在有效期内是不会变的。

可是 js 内容改动是很正常的一件事情，为什么要去设置永恒不变呢？

这里讨论的是新思路，只要思路对了，用 JS 在 localStroage 里自己管理缓存，代码实现是很容易，回个贴不需要那么激动。

@NewYear “我不知道你怎么测试的”

我用的是 chrome96, 不管改不改 integrity ，只要 max-age=0 ，资源过期了，浏览器就必定会向服务器发起新连接。

不是你说的，浏览器就直接不请求了。

这个测试结果是符合预期的。

integrity 改了，只会让你的资源加载失败，和网络缓存真没关系。不信你可以把相关的搜索资料给贴出来。

B 站啊，查 figma 。

小破站是万能的自学老师。

@kop1989smurf 肯加班都不错了，我看到面向工资编程的人，基本上都是下班直接闪人的。

编程水平和人生是一样的，很多人没太多挫折，还不是光涨年龄，没涨阅历。

隔壁贴刚毕业小女生拿 24k 月薪，我觉得挺高的，人家还不满足。只能说这行企业不缺钱，给得起高薪。

@kop1989smurf "靠工作时长来换取薪资的他们自信从何而来。"

我观察下来，V 站有一部分大佬也并不是前端。

你比如后端，死命加班，还是能出点成绩，加点工资的。

@NewYear 我用 Chrome 实测没测出来。

官方没任何文档说 integrity 和浏览器本地缓存有什么必然联系。可能只和第三方 CDN 刷新机制有关系。

Chrome 下不匹配 integrity ，就是直接阻止脚本运行，弹出 The resource has been blocked 。

至于缓存没任何区别。

@lujiaosama “LZ 都限定了 ts 了, ts 没你说的那些缺点. 现在连前端都不直接写 js 了.”

这就和那句 Any application that can be written in JavaScript, will eventually be written in JavaScript.一样。

理论上你能用 JS/TS 写出任何代码。

而事实上，那些复杂的大应用，大家都在用别的语言，翻译成 WASM 后，使劲往 JS 里搬运。

当然你要说公司前端写来写去，就是那些表单开发，没任何深层次的功能和算法，那么 TS/JS 还是够用的。

@ryd994 你还是没理解我的意思，我是说 revalidate 就完全没有存在的必要！

如果 HTML 文件里有 JS 的 hash 值，那么问题就很简单。

* hash 和缓存一样，那浏览器获取了 HTML 后，就无需发起任何后续的网络连接。
* hash 和缓存不一样，那浏览器就直接去取最新的 JS 。

这样逻辑就清晰多了。浏览器去问服务器，某某 JS 文件要不要更新，本身就是一件多余的操作。

@ryd994 “你建议 script src='file.js' last-modifed-time='utctime
这和 script src='utctime/file.js'
有什么区别？”

上面一句浏览器可以本地缓存比对，如果文件缓存里有，就不需要发一条 URL 请求去服务器。
下面一句浏览器必须去访问一下服务器，哪怕返回的是 304 。

“如果 你设置 max-age 为最长时间”
就是设置 max-age 才会导致这种不合理的情况发生，在 max-age 没到期前，浏览器默认就是 CSS/JS 有效的，和服务器不同步。

@ryd994 “服务器直接把你说的 last-modify 的 tag 加到 css 的 URI 里，你看你得到了什么？”

就是不希望加在 URI 里。问题的核心，我就希望只请求一个 HTML ，里面包含了足够的 js/css 校验信息给浏览器。

浏览器本地匹配完缓存资源后，如果没有新资源更新（属于常态），那后续没有任何的服务器 URL 请求！

我就想把这 css/js 校验流量，给节省下来，在我看来是完全多余的。HTTPS 返回 304 是很快，可是 DNS 解析，有时候会卡半天，属于客户端不可控因素。

@NewYear integrity 是内容强校验 hash ，仅仅只是确保内容是否正确。

integrity hash 和缓存里的 etag hash 是完全隔离的，又不能相互调用。

你说让我用，问题是这样写，没法用啊。我觉得你搜到的 cache ，应该是 cdn 的 cache,不是浏览器的 cache 。

当然是选择用 unity 开发前端啦。

@lujjjh “前端发布不是原子操作，发布过程中至少需要有两个版本共存”

这样一想，确实也有点道理。

如果一个新版 JS 要强制更新，万一有几十万个 Web 用户，同时下载 JS ，给服务器的压力也不少。

允许多个版本同时存在，渐进更新就没这个问题。

@wonderfulcxm "如果你愿意，可以修改响应头，css/js 可以用 html 一样的缓存策略。"

我本地测试用一样的策略啊，都是 max-age=0 ，本地流量无所谓，这样浏览器会自动获取新数据。

但是给客户用 max-age=0 ，页面有多少个 css 和 js ，就会多出多少条 HTTPS 链接，这设计显然不太合理。

所以我才说有缺陷。浏览器既然能识别 script 标签的 integrity 做内容校验，那顺便判断 ETAG ，节省网络资源的新 HTTPS 链接，就是举手之劳。

@serge001 "至于你说的方案，对于引入的第三方 js 怎么处理？"

引入第三方 JS ，就更需要我说的这个方案了。

举个例子，假设第三方 JS 被黑，很可能导致你主网站用户的 cookie ，全部被恶意泄漏。

能避免这样方法，就只有给 script 标签加上 hash ，做文件的内容二次校验。这和我说的标签加 ETAG ，是一回事。

@mxT52CRuqR6o5 “http1 的话也许可以尝试在业务层自行实现一次性的向服务器请求 HTML 里所有 css/js 的最后更新时间”

我确实是这样处理的，还是觉得麻烦。

直接修改 JS 文件嘛，如果不用 webpack ，每次还要用 ctrl+F5 刷新一下，真是累人。

@mxT52CRuqR6o5 “有这个特性啊，你在 js/css 的 response 里声明不走强缓存，就可以走协商缓存了”

不走强缓存，那用户每次刷新一下主页，HTML 有十个 js/css 文件，HTTPS 就会连续去请求十次！

这在移动互联网时代，是很难接受的，没准哪个请求就卡住，拖慢了页面整体载入后腿。

@serge001 比如 HTML 里有 10 个 JS 和 CSS ，服务器有变动了，明明可以在 HTML 里通知浏览器的。

只要设计有《 meta jsname='file.js' cache-control-etag='hash'》类似的语句就行。

总比浏览器自己去访问十次服务器，对比 10 次 HASH ，浪费流量来的好吧。