Express+MongoDB项目API图片最佳存储方案咨询

针对你项目里Park、Rides实体关联的轮播图、卡片图存储需求，三个方案的实际适用场景和踩坑点直接说透，不用绕弯：

各方案实际表现对比 #

• 存MongoDB
  本地写demo临时用可以，生产环境直接排除。MongoDB单文档有16MB的硬上限，真要存图片二进制就得走GridFS，平白多套一层读写逻辑：前端要图的时候你得先从库读流再转接口响应，延迟比静态资源直出高一大截；而且MongoDB存储成本是对象存储的好几倍，后续做数据备份、迁移的时候，光图片就能把备份包撑到几十上百G，运维成本极高。
• 存应用本地磁盘
  仅适合本地开发阶段图省事临时用，上线绝对别选。只要你后续做多实例负载均衡、服务器故障迁移，本地存的图片大概率出现不同实例文件不一致、甚至直接丢失的问题；其次图片传输占应用服务器带宽，访问量稍高你的Express服务就会被图片请求占满CPU和带宽，正常业务API直接卡成PPT。图片压缩、缓存、断点续传这些通用能力全要你自己手写实现，纯纯重复造轮子。
• 存AWS S3（含兼容S3协议的对象存储服务）
  生产环境首选方案。首先存储成本极低，标准存储单GB月成本不到一毛钱，远低于服务器磁盘和MongoDB的存储成本；其次天生支持对接CDN，配置完之后用户加载图片的速度比你自己服务器返图快数倍；另外S3自带多副本容灾、权限控制能力，不用你自己做数据备份，文件基本不会丢。对接Express的SDK非常成熟，甚至可以实现前端直传，不用经过你的后端服务中转，能省大量服务器带宽。你只需要在MongoDB的Park、Rides文档里存图片的S3访问地址、尺寸、文件hash这类元数据就行，查询接口直接把URL返回给前端，前端直接走CDN拉取资源，性能拉满。

落地实操提示 #

本地开发阶段不用直接连线上S3，可以本地搭个MinIO服务，完全兼容S3协议，代码逻辑和线上保持一致，还能省开发阶段的存储成本。

• 上传接口一定要在服务端做文件格式、大小校验，别什么文件都往存储桶里传
• 提前配置好存储桶跨域规则和防盗链，只允许你自己的业务域名拉取资源，避免被人盗刷流量
• 轮播图、卡片图这类展示类图片，上传时自动生成2-3种不同尺寸的缩略图，前端根据场景加载对应尺寸的图，减少不必要的流量消耗
• 配置公共读权限时一定要仔细核对存储桶策略，别把存敏感文件的私有桶直接开公网访问，避免数据泄露

内容的提问来源于stack exchange，提问作者Clément