Java博客应用上传图片至AWS S3是否需存储原始文件名

这个场景不存在“必须存储原始文件名”的硬性要求，就算不存，你当前的图片上传、前端渲染流程也能正常跑通。但从实际开发运维的长期成本来看，花极低的代价存下原始文件名是性价比极高的选择，非常推荐做。

• 问题排查效率提升非常明显：你用哈希值做S3存储文件名，最终存在bucket里的都是无意义的随机字符串，一旦出现图片加载报错、文件异常偏大导致S3流量费突增、疑似违规内容需要溯源的情况，你根本没法直接通过哈希值定位到这张图属于哪个用户、关联哪篇博客，总不能全表扫描所有博客正文去匹配对应的哈希路径。存了原始文件名的话，哪怕是用户随手命名的项目上线报错截图.png、2024旅行随拍.jpg，都能帮你快速缩小排查范围，少走很多弯路。
• 给后续功能迭代留缓冲：你当前的规划是图片仅用于前端展示、不开放下载，但业务需求是会变的——后续如果要加博主导出个人所有文章素材、后台素材管理列表、博主批量整理自己上传的图片这类功能，有原始文件名的话，用户看到的是自己熟悉的命名，不用面对一堆看不懂的哈希值挨个手动重命名。如果现在不存，等后面要加这类功能的时候，历史上传的图片原始文件名已经找不回来了，根本没法补数据。
• 极端场景下的兜底校验：哪怕你用的是碰撞概率极低的哈希算法，理论上还是存在不同文件算出相同哈希值的可能，一旦出现这种极端情况，你可以结合原始文件名、文件大小、上传人信息做二次校验，避免新上传的文件直接覆盖掉S3里的老文件，导致之前发的博客展示错图。
• 降低内容审核的成本：如果后续要做图片内容合规校验，原始文件名本身就是一个可参考的弱特征，比如文件名本身带违规关键词的文件，可以直接提高审核优先级，不用完全依赖图片内容解析做判断，能省不少审核资源。

补充：存储原始文件名完全不会影响你现有的业务逻辑，你只需要在存储图片信息的表上加一个长度合适的字符串字段存原始名就行，额外占用的存储成本几乎可以忽略。而且这个字段只存在你的服务端数据库里，前端渲染还是用你拼接好的S3哈希路径，不会把原始文件名暴露给公网用户，也不会和你“不开放下载权限”的规则冲突。

内容的提问来源于stack exchange，提问作者Kate