我们正在构建基于网络的音频编辑器的概念模型。我们遇到的第一个问题是客户端缓存系统。在我看来，作为在客户端拥有巨大缓存的服务器端程序员是完美的主意，因为在许多情况下，除了多次加载相同数据外，它会占用服务器负载。此外，这种缓存可能是提供每个轨道操作（如过滤）的缓冲区的良好候选者。
我们的 flex 程序员说这是一个很大的麻烦，几乎在任何情况下都是不可能的。但我非常怀疑，因为我知道实际的 Google Chrome 浏览器版本可以简单地在 localStorage 中保持高达 2 Gb。此外，我发现了这个在线曲目编辑器的例子，看起来它的缓存机制工作得很好。
是否可以使用 flash 和 js 在客户端缓存一些数据（大约 100-200mb）？
如果您使用的是 html5，那么您可以使用html5 内置数据库在客户端存储大量数据。
也参考这个链接
您可以使用 SharedObject 来存储数据。
我很确定默认大小限制对于您的需求来说太低了，因此您的应用程序需要要求用户接受您的新限制： http:
//www.macromedia.com/support/documentation/en/flashplayer/help/help06 .html
SharedObject 比浏览器缓存更可靠，您可以从应用程序中控制它。
我们在编写视频编辑器时做了什么。好吧，实际上，在 Flash 中，您可以将文件保存到用户的机器上，但限制是它必须对用户透明（即用户启动操作，通过操作系统对话框并保存文件，因为他们通常会保存任何下载），类似地，您可以从用户的计算机加载文件，但限制是用户必须启动操作（例如通过使用指点设备单击或按键）。
这与不同的本地存储策略相比具有一定的优势，这些策略对用户来说大多是不透明的（人们通常不知道如何擦除更现代浏览器附带的 cookie、SharedObjects 或 Web 存储，但它们几乎能够保存和删除系统上的文件）。此外，所有其他不透明的本地存储可能具有一些限制，不太精明的用户可能不知道如何克服/可能无法克服一般情况——这些限制是大小、位置和所有权。
这对您的听众来说仍然会有些障碍，因为每次他们需要保存文件时，他们都必须通过操作系统的对话框，而不是执行 Ctrl+S / Cmd+S / Cx Cs... 但是考虑到所有其他选项，这个，IMO，给用户留下最多的选择/提供最好的体验。
另一个建议——原则上，你可以为你的应用程序提供一个基于浏览器的“增强”版本，用户可以将其安装为浏览器插件（如果这是他们经常使用的编辑器——为什么不呢？），在这种情况下，您将不会受到网络技术提供的笨拙选项的限制。基于 Chrome 和 Mozilla 的浏览器鼓励这种开发，但它不是标准化的。尽管如此，由于这两个浏览器几乎可以在任何操作系统上运行，这听起来并不特别像将您的用户锁定在某个平台上......