我之前排查过类似的Chrome缓存异常行为，结合对Chrome缓存机制的理解，给你梳理下可能的原因和验证方向：

1. Chrome内存缓存的自动驱逐机制是核心原因 #

Chrome的缓存体系中，Memory Cache是优先读取的层级（速度最快），但它是易失性缓存——当标签页处于后台、浏览器内存占用过高时，Chrome会自动把体积较大的内存缓存资源驱逐到Disk Cache中释放内存。
如果这时候页面刚好有后续操作需要再次请求该JS资源（比如延迟加载的组件、路由切换后的逻辑校验），就会触发从Disk Cache读取，看起来像是“重复加载”，但本质是内存缓存被回收后的降级读取。

为什么只有JS受影响？因为JS资源通常体积更大，在内存紧张时会被Chrome优先从Memory Cache中驱逐，而图片等资源因为和渲染上下文绑定，留在内存的时间会更长。

2. 页面内的重复请求触发逻辑放大了这个现象 #

你提到请求头存在无规律差异（比如其中一条带Referer），大概率是页面内存在对同一JS资源的两次请求触发点：

• 第一次是页面初始化时的正常加载，命中Memory Cache；
• 第二次可能来自异步回调、路由跳转后的页面上下文、弹窗/iframe的加载逻辑，这时候Referer会变化，但资源路径一致。刚好第二次请求发起时，Memory Cache里的该资源已经被驱逐，就命中了Disk Cache，最终在Network面板显示两条缓存记录。

3. DevTools的显示特性容易造成误解 #

Chrome DevTools的Network面板会把不同缓存层级的读取行为分成独立的记录，但这不是真正的网络请求——你可以看两条记录的Size列，都是标注from memory cache/from disk cache，没有实际的字节下载，所以不会影响页面性能，只是日志显示的差异。

验证与优化建议 #

• 内存占用验证：打开Chrome任务管理器（Shift+Esc），关闭其他闲置标签页释放内存，再刷新页面，大概率不会出现Disk Cache的读取记录；反之，打开多个内存密集型标签页，这种现象会更频繁。
• 请求逻辑排查：检查前端代码中是否存在重复加载同一JS的逻辑——比如路由守卫、异步组件加载、自定义预加载脚本里的重复调用。
• 资源拆分优化：把大体积的JS拆分成小模块，降低单文件内存占用，减少被Chrome从Memory Cache驱逐的概率。

内容的提问来源于stack exchange，提问作者isznjm