是否应该用文件 MD5 作为文件名？

文件名再加个用户信息区分？

看有没有删除文件和剪切文件的需求

都用 md5 了 为啥不用 uuid ？

@killergun 如果要考虑 MD5 冲突的话，可能加用户信息不如加时间戳？

@maichael 暂时计划软删除，而且图片多为 UGC 内容，连带删除可能性不大，数据库有记录文件被使用信息。

强迫症患者表示，写个 VFS 不香吗？服务器一堆小文件，等到要异地备份的时候，完全受不了。

这个其实看需求，用 md5 命名，我觉得最主要是，不需要另外搞个数据库保存文件 md5 值
怕不同文件但 md5 冲突，就加个字段呗，例如字节数、抽固定几个字节 base64/md5 作为二步校验
我觉得在出现冲突时才考虑加上就够了，不必所有文件预先加上

不要 MD5，实现碰撞很多年了 /t/169241

你这个可能不如另一个问题明显：
用户把同一个文件用两个不同的名字传上来，咋办呢

如果能做到可能哈希冲突的数量级，直接用第三方对象存储就行了，不会差钱的。

不考虑攻击的话, 百亿级的文件数量, md5 冲突概率小于 1e-18

@Licsber 用 md5 实际上是想避免相同的文件存多份的。

@3dwelcome 能力有限，直接用 OSS 了

@imn1 文件没有存本地，所以没有能力判断冲突的文件是否相同。

@huobazi 已经用上了，。

@lxilu 如 11 楼 不考虑攻击的话，其实日常应该 概率不大？

@Vegetable 针对的就是这种情况，用 md5 可避免，但是真正怕的是 md5 相同的两个不同的文件。

@rimutuyuan 就是在 OSS 上了，所以又来问了。

@vance123 有这个数字心理放心多了。

感谢以上大佬们的回复，谢谢。

摘要其实是不靠谱的，他的作用是在一定可靠程度下去验证两个东西是不是同一个，而这可靠程度只要你碰到了就是确定的。
所以你不能靠摘要去给用户文件去重，只能后台完全比较。不然很容易就像之前 SHA 那样两个 PDF 一样。这东西人为制造一个碰撞很难，但是你没法保证用户上传的不碰撞。到时候没法跟用户解释你就是那 1%。你自己上传的照片为什么变成了冠希。
个人建议，上传直接 UUID，同时另存一份摘要。然后后台跑个程序定期对摘要相同的文件做完整比较，如果完全一样那么直接把另一个文件在数据库里记录的 UUID 替掉。
当然这是不考虑删除的情况。

不考虑攻击的话，MD5 碰撞概率真的太小了。
如果真的不放心，可以补一个别的 Hash 算法，比如说 MD5+XXH128，那要是能被攻破了，就能写论文发表了。

@Mithril 1%是不是有点过分了，128bit Hash 的空间，0.000000001%还差不多，几千亿个文件能撞上一次的概率都微不足道。如果是淘宝这个体量，是要考虑碰撞的，但是普通人连下辈子转生了都不一定能遇上一次随机 MD5 碰撞。
现在的 MD5 碰撞，也是密码学攻击碰撞而不是随机 Hash 空间内碰撞。

MD5 已知能构造碰撞，肯定有人攻击啊！你也不是非 MD5 不可吧