数据库里存图片地址那些事儿，分享几个我觉得挺管用的小技巧

根据个人项目经验及与同行交流的常见实践总结）

数据库里存图片地址那些事儿，分享几个我觉得挺管用的小技巧

这事儿估计每个做开发的都遇到过，用户上传个头像，商品得配个图，文章里要插图，这些图片到底该怎么存？直接把图片塞进数据库？除非是那种特别小、几乎不变化的图标，否则我劝你千万别这么干，为啥？太伤数据库了，图片一大，数据库体积蹭蹭涨，备份恢复慢得像蜗牛，而且读取出来还得转换成二进制流，麻烦不说，还特别耗服务器的内存，现在大家基本都达成共识了：数据库里只存图片的访问地址（其实就是个字符串，比如一个URL）,图片文件本身放在专门的文件服务器或者对象存储上。

听起来很简单对吧？不就是个字符串嘛，存进去，读出来，完事儿，但真干起来，里头有不少细节能让你掉坑里，今天我就分享几个在实际项目中摸爬滚打总结出来的小技巧，能让这事儿做得更稳妥、更高效。

第一招：地址别只存一个“光杆司令”，拆开存更灵活

很多人图省事，直接存一个完整的URL，https://cdn.yourdomain.com/images/2024/05/20/abc123.jpg，这么做不是不行，但灵活性差了点，万一哪天你的域名换了，或者想换个CDN服务商，难不成要把数据库里成千上万条记录全都更新一遍？那简直是噩梦。

我的习惯是拆开来存，至少拆成两个字段（或者用JSON串存成一个字段，但结构要清晰）：

1. 基础路径（base_url）：https://cdn.yourdomain.com，这个可以配置在系统的配置文件里，数据库里甚至可以只存一个配置项的键名，或者如果全局统一，这个字段都可以省略,程序里直接读配置。
2. 相对路径（relative_path）：images/2024/05/20/abc123.jpg,这个才是真正标识图片唯一位置的信息。

这样做的好处太大了，当你要切换存储环境时，可能只需要改动一下配置文件里的基础路径，所有图片的访问地址就自动生效了，完全不用动数据库,在代码里拼接URL也非常方便。

第二招：给图片地址上个“保险”——存个哈希值校验

这个技巧是从文件传输怕出错的场景里学来的，用在图片存储上也特别香，用户上传图片后，我们在服务器端对图片文件计算一个哈希值（比如MD5或SHA1），然后把这个哈希值也存到数据库里,跟图片地址对应上。

它能干嘛用呢？

• 校验文件完整性：有时候文件在传输过程中可能会损坏，或者从一台服务器迁移到另一台时可能出错，当需要的时候，你可以用存的哈希值去校验一下现在文件服务器上的文件是否还是“原装”的,确保数据没出问题。
• 快速判断图片是否重复：如果新上传的图片计算出的哈希值在数据库里已经存在，那很可能就是同一张图片，这时候你可以选择不再重复上传，直接复用已有的图片地址，节省存储空间,这个在用户重复上传相同头像或者商品有共用图片的场景下很有用。

第三招：处理好“图片不见了”这种尴尬情况

你肯定见过网上那个裂开的小图片图标，那就是图片地址失效了，用户删了图、文件服务器迁移失误、手动清理文件时误删，都可能导致这个问题，如果页面上大片大片的图片裂开,体验非常差。

怎么办呢？我们可以搞一个统一的默认图片机制，在拼接图片URL的地方，加一层判断，如果根据数据库里的地址去访问，发现图片不存在（比如得到404错误），就自动替换成一个我们事先准备好的默认图片地址，这个默认图片可以是一张友好的“图片暂无”的占位图。

这样，即使真的发生了图片丢失，前端展示出来的也是一个体面的提示图，而不是丑陋的裂痕，对用户更友好，这个逻辑可以在后端接口里实现，也可以在更前端的层面（比如Nginx）通过一些错误处理配置来实现,减轻后端压力。

第四招：地址也要“分门别类”，方便管理

如果你的系统里有多种类型的图片，比如用户头像、商品主图、商品详情图、文章封面图等等，我建议你在数据库里加一个type字段来区分它们。

这么做的好处是管理起来一目了然。

• 统计方便：你想知道系统里总共用了多少张商品主图,一个简单的查询就搞定了。
• 清理方便：当某个商品下架了,你可以根据类型快速定位到需要清理的图片文件。
• 处理策略不同：不同类型的图片可能对应不同的处理规则，比如头像可能需要多种尺寸的缩略图，而文章详情图可能只需要一种尺寸，有了类型字段,你的图片处理程序就能更好地分工。

最后啰嗦一句，存地址虽然主流，但别忘了定期备份图片文件本身！数据库里的地址丢了还好说，要是文件服务器上的原始图片没了，那才是真正的灾难，文件服务器的备份策略一定要做好，最好能有多重保障,比如同步到另一个地方做异地备份。

这些技巧都不是什么高深的技术，但就是在这些细节上多想一想，做出来的系统 robustness （健壮性）和可维护性就能提升一大截,希望对你有点启发。