Chrome如何删除指定文件的缓存

日常工作中经常会遇到一些文件不符合发布预期，听到最多的解决方案就是“清空一下浏览器缓存”就好了。清理缓存的时候基本是“一把梭哈”式的清理，并没有针对某个文件进行清理。如何查看下载的文件缓存在哪里，缓存文件是什么呢？今天借apk包通过浏览器下载是0kb的问题展开分析一下，分享一下拙见。

事情起因

我们有个Echo apk包从浏览器下载提示文件大小异常: 0字节，不是全部同学不行，有些人就可以，有些人不行，我自己测试从Chrome下载也是0kb，如下图。

在终端中用wget下载确没有问题，浏览器开启隐身窗口进行下载也没有问题，手动把浏览器缓存清空一下再下载就又好了。

分析原因

准备测试环境

首先要做的是把这个问题现象尝试复现一下，能复现出来就进行分析就简单多了。

出问题的apk包的下载环境：

1. 有CDN加速
2. 经常更新，频繁刷新CDN文件
3. 有缓存时间

基于这个进行测试环境构建：

1. 简单的浏览器访问测试地址—>CDN加速—>s3源站测试文件。
2. 能查看Chrome缓存文件内容的软件（https://www.nirsoft.net/utils/chrome_cache_view.html），追踪测试文件。

浏览器的请求流程如下，这里不深入探讨缓存问题，可以参考之前的文章。

Windows下进行测试

1. Chrome升级到最新版本，

1. https://codown.youdao.com/oimage20240404/echo_DT10_encrypted.apk 测试文件地址

Chrome第一次访问https://codown.youdao.com/oimage20240404/echo_DT10_encrypted.apk，缓存的cache_name是f000001，如下所示：

Chrome第二次访问https://codown.youdao.com/oimage20240404/echo_DT10_encrypted.apk，缓存的cache_name是f000002，如下所示：

两次访问为什么生成不同的cache_name f000001和f000002，后面再讲。

现在使用echo命令把这个apk包文件置空（见下图），刷新CDN。

Chrome访问https://codown.youdao.com/oimage20240404/echo_DT10_encrypted.apk可以看到FileSize这边是1，连续两次的cache_name都是data_1。

把apk还原回去，再刷新CDN。

Chrome再访问https://codown.youdao.com/oimage20240404/echo_DT10_encrypted.apk，下载下来文件大小是0kb，查看缓存cache_name还是data_1，这种情况下再访问多次下载下来的文件也是0kb，使用edge浏览器下载是正常的。。

Chrome删除一下缓存

删除完缓存之后ChromeCacheView这边看不到任何缓存文件内容。

Chrome连续两次访问https://codown.youdao.com/oimage20240404/echo_DT10_encrypted.apk，文件大小恢复了，缓存的cache_name是f000001和f000002。

进一步观察，下载完成后缓存目录（C:\Users\lilj\AppData\Local\Google\Chrome\User Data\Default\Cache\Cache_Data）的f000001和f000002会删除。

查看Windows的Chrome缓存目录结构发现有f和data两类文件，这里的f和data有啥区别呢？

Windows Chrome缓存存储策略

Chrome浏览器针对不同大小的文件采用差异化的缓存存储策略，这种设计主要基于存储效率和性能优化的考量。

1. ​小文件合并存储（data_*文件）​​

• ​存储逻辑​：所有≤16KB 的文件会被合并存储到data_0/data_1/data_2/data_3等块文件中，每个块文件对应固定容量（如data_1对应1KB块）。
• 索引定位​：通过哈希算法将文件映射到块地址，索引文件记录块号、偏移量等元数据。这种集中存储减少了文件系统元数据开销（如inode占用），提升小文件读写效率。

2. 大文件独立存储（f_开头文件）

• ​文件命名​：每个＞16KB的文件生成唯一的以f_开头的独立文件（如f_0123abcd），文件名基于URL的SHA1哈希值
• 避免碎片化​：独立存储可减少大文件读写时的磁盘碎片，同时便于快速删除或更新。

Windows Chrome开启多个下载，会对应生成多个f缓存文件，下载完成后就自动删除了，但是data_*是不会自动删除的。

在终端wget 下载文件没有问题，但是从Chrome下载就是0kb，原因就是这个缓存在了data_*文件中，默认情况下浏览器优先使用了本地缓存导致的（HTTP的缓存策略可以参考https://www.rfc-editor.org/rfc/rfc9111.html）。

Mac下进行测试

在Chrome中输入“chrome://version/” 可以看到安装的Chrome信息，包括版本等信息，默认缓存目录在/Users/用户名/Library/Caches/Google/Chrome/Default/Cache/Cache_Data下，结构如下：

MAC Chrome缓存存储策略

新版Chrome 将缓存资源按 ​16MB 分片​存储，每个分片文件命名遵循 <16字节哈希，资源 URL 的 SHA-256 哈希值（截取前16字节）>_<分片编号，表示该文件属于缓存分片组中的第0号文件> 规则，哈希值基于 ​资源 URL + 请求头指纹​ 生成，确保唯一性。通过 index-dir/the-real-index 文件维护哈希到分片的映射关系，记录：

• 分片编号
• 文件偏移量
• 资源有效期
• 访问频率统计（用于 LRU-K 淘汰算法）

mac下的ChromeCacheView 是三年前的，没有办法在现在的系统下运行。搜了一下网上的解决方案，可以把exe用wine封装一下在mac下运行，可以看到缓存的文件信息。

删除了Chrome缓存后，新下载apk，生成缓存文件1eba42319a004824_0，大小和apk包大小一致。后续再多次下载，不会再生产新的缓存文件，只使用1eba42319a004824_0缓存文件。

hexdump -C 1eba42319a004824_0 | less 查看1eba42319a004824_0内容，可以看到这个apk包的信息，如下图。

把1eba42319a004824_0直接删除后再下载就会变成重新从CDN下载，后续再次下载又变成使用本地缓存。

删除缓存

遇到apk包浏览器下载是0kb的情况可以通过删除浏览器缓存、使用隐身窗口，或者打开调试工具勾选停用缓存来解决。

如果想删除指定文件的缓存，推荐使用ChromeCacheView进行识别处理。

写在最后

工作中遇到浏览器缓存引发的文件下载问题时，我们往往习惯性采取”清空缓存”这种简单粗暴的方式。就像这次遇到的APK包下载异常案例，通过深入分析才发现：看似相同的”清理缓存”操作，背后却隐藏着Chrome对不同大小文件的差异化存储策略——小文件合并存、大文件独立放，这种设计既优化了存储效率，又兼顾了性能需求。

面对缓存导致的各种问题，我们需要建立系统化的排查思路：从现象观察（如多次下载对应不同cache_name）、到工具验证（使用ChromeCacheView等工具）、再到根源分析（理解缓存策略和HTTP协议交互），每一步都不可或缺。正如案例中通过hexdump直接查看分片文件内容，最终确认问题根源的过程所示，技术问题的解决往往需要理论与实践的结合。

最后想强调的是，缓存机制的设计本质上是性能与实时性的权衡。作为开发者，我们既要合理利用缓存提升用户体验，也要在必要时精准控制缓存行为。这需要我们深入理解浏览器的工作原理，掌握各种调试技巧，才能在遇到问题时游刃有余。毕竟，优秀的工程师不仅要能解决问题，更要能透过现象看本质，从根本上优化系统设计。

参考文档：

• https://www.cnblogs.com/SiriusZHT/p/14310767.html#_82
• https://www.rfc-editor.org/rfc/rfc9111.html
• Chromium仓库（https://source.chromium.org/chromium/chromium/src/+/main:net/disk_cache/）