生成crc的速度有多快

使用更健壮的散列算法，如SHA1。

速度取决于图像的大小。大部分时间将花在从磁盘加载数据上，而不是花在CPU处理上。您可以缓存生成的哈希值。

但我也建议创建基于文件的最后更新日期的etag ，这是更快，不需要加载整个文件。

请记住，etag必须仅对特定资源是唯一的，所以如果两个不同的图像具有相同的最后更新时间，则没关系。

大多数实现使用最后修改日期或其他文件头作为ETag，包括微软自己的，我建议您使用这种方法。

取决于使用的方法和长度。通常很快，但为什么不缓存它们呢?

如果对文件的更改不会超过用于存储它的系统的分辨率(即文件系统的文件修改时间或存储在数据库中的SQLServer datetime)，那么为什么不将修改日期用于相关分辨率呢?

我知道RFC 2616建议不要使用时间戳，但这只是因为HTTP时间戳是1秒的分辨率，可能会有更频繁的变化。然而:

1. 如果你不改变图像超过一次，这仍然是好的。
2. 基于时间的电子标签也很好，只要精确度足够高，不会在相同资源的两个版本中出现相同的结果。

使用这种方法，您可以保证使用唯一的电子标签(大CRC不太可能发生冲突，但肯定是可能的)，这正是您想要的。

当然，如果您从未在给定的URI上更改过图像，那么使用固定字符串(我更喜欢字符串"immutable")会更容易。

我建议在将图像添加到数据库一次时计算哈希值，然后通过SELECT与图像本身一起返回。

如果你是使用Sql Server和图像不是很大(最大8000字节)，你可以利用HASHBYTES()函数能够生成SHA-1, MD5，…