我将从一个坚实的例子开始：我有一个生成哈希值（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Ó§XeμZì`“dhõÕqÂ7z¥Ðㅗq¤ㅉT！ºㅙ4ÈㅐZ2R¥½Oメ3äòCæcマ/ =
19个哈希值，76个字节的数据（其中有一些不可打印的字符）
这节省了63.8％。
现在，我很清楚localStorage默认提供5MB的存储空间。我可以用第一种方法轻松存储成千上万的哈希，完全没有问题。但我喜欢高效。我当然不希望在我的计算机上有一个5MB的文件，因为我可以拥有1.8MB的相同数据（压缩比与上面相同）。这就是为什么我尽可能将所有PNG保存为索引调色板的原因。
这是一个很好的心态吗？还是我只是在迂腐？我想这个问题可归纳为：我应该压缩，还是因为拥有的资源超出我的需要而不在乎？
答案 0 :(得分：1)
当来到代码时，迂腐是好的。尽可能压缩，但要确保在阅读代码时，仍然可以理解哈希以任何方式保存。
我的意思是，不要牺牲代码的可读性和可维护性来提高效率。