我将从一个可靠的示例开始：我有一个生成哈希（32 位整数）并将它们保存在 localStorage 中的函数。这是为了实现常见通知的“不再显示”功能：如果哈希在列表中，则不显示通知。
在我第一次尝试编写此解决方案后，我的 localStorage 条目如下所示：
616845040,796177849,848184043,1133088406,1205053317,1478518197,1525440546,1686606993,1753347541,1908577591,2056496592，-864967541，-1185668678，-835401591，-1017499054，-559563441，-1842092814，-1069291933，-1887162563
19 个哈希，210 个字节的数据。
稍后，我重新访问了代码。我不只是将整数转储为十进制字符串，而是将它们转换为实际的二进制数据。换句话说，每个哈希现在都是一个长度为四个字符的字符串，表示整数的二进制值。我的 localStorage 条目现在看起来像这样：
$ÄNð/tµ¹2BëCGÓ§X eµZì`"dhõÕqÂ7z¥Ðￌq¤ﾹT!ºￎ4ÈￃZ2R¥½Oﾒ3äòCæcﾏ/=
19 个哈希，76 个字节的数据（那里有一些不可打印的字符）
节省了 63.8%。
现在，我很清楚 localStorage 默认提供 5MB 的存储空间。我可以使用第一种方法轻松存储数万个哈希，完全没有问题。但我喜欢高效。当我可以在 1.8MB 中拥有相同的数据（与上述相同的压缩率）时，我当然不希望在我的计算机上拥有 5MB 的文件。这就是为什么我尽可能将所有 PNG 保存为索引调色板。
这是一种良好的心态吗？还是我只是迂腐？我想这个问题可以概括为：我应该压缩，还是因为拥有比我需要的更多的资源而不在乎？