为什么 HTML5 离线重新缓存整个清单，并且仅在清单文件更改时？

Question

我一直在阅读 Dive Into HTML5 中的 chapter on offline，它给我留下了一些问题。

它说

每次更改离线 Web 应用程序中的资源之一时，都需要更改缓存清单文件本身。这可以像更改单个字符一样简单。我发现完成此操作的最简单方法是包含带有修订号的注释行。更改评论中的修订号，然后Web服务器将返回新更改的缓存清单文件，您的浏览器会注意到该文件的内容已更改，并会启动重新下载所有资源的过程清单。

但是，让我们以同一篇文章中讨论的 Wikipedia 示例为例。每当编辑文章时，必须更改清单文件以反映编辑，并且任何已离线存储页面的用户都会丢失它们，因为它们没有在清单中明确提及。这真的是可取的行为吗？如果是，为什么不执行以下操作：

1. 将文件存储在脱机缓存中，直到它们被明确删除，即使清单发生更改也是如此
2. 缓存中的文件被更改时更新（例如，当服务器未返回 304 Not modified 时）

如果一个人得到上述两点描述的行为，他的选择是什么？使用本地存储或其他什么？

Answer 1

首先，查看appcachefacts.info 以更好地了解这个令人困惑的规范。

AppCache 通常会以意想不到的方式工作，就像 Jake Archibald 在他的博文 Application Cache is a Douchebag 中解释的那样。

在其中，上述行为是通过一些 iframe 魔术实现的。我只是将静态页面添加到 appcache 清单并通过非缓存片段页面的 AJAX 调用加载正文内容，基于 onClick 等外部事件，并将正文数据存储在 WebSQL 数据库中以供将来（可能离线）参考.这实际上使我的离线应用程序完全基于 JavaScript，无需重新加载任何页面。

您也可以使用 HTML5 本地存储来代替 WebSQL，但可能会对 5MB 的存储限制感到不安。

至于原因，我只能推测。我认为：

1. Appcache 在明确删除之前不会存储文件，因此 appcache 大小将保持适度。在 Wikipedia 示例中，缓存每个访问过的页面并且从不清除（可能已删除！）页面似乎是个坏主意。
2. 清单中的文件不会在每次页面重新加载时重新检查，因为这意味着服务器请求的爆炸式增长。如果您的清单文件包含 30 个文件，它会在每次页面加载时发送 30 个额外请求。即使它们是异步执行的，这也是不可接受的。