Next.js公共文件夹静态资源与云存储方案：为何不选前者存图片？

阻碍大家用public文件夹存图片的原因不止你提到的两点，核心问题主要有这些：

• 动态内容维护太麻烦：如果图片是用户上传、后台动态更新的内容，存在public文件夹等于把媒体文件和代码绑定了——新增/删除图片都要改代码仓库，重新构建部署。这对UGC（用户生成内容）场景完全不适用，总不能用户传个头像你就发个应用版本吧？多人协作时还容易出现文件冲突。

• 部署包与存储容量限制：Next.js部署时会把public文件夹的所有文件打包进部署包，图片多且大的话，部署包体积会暴增，不仅部署时间变长，还可能触发平台的包大小上限。另外，应用服务器的存储容量有限，塞满图片会挤占服务器资源，成本也远不如云存储划算。

• 性能优化跟不上：云存储自带全球CDN加速，能让各地用户快速加载图片；而public文件夹的图片默认从应用服务器加载，跨区域访问速度慢。而且云存储能自动做图片压缩、格式转换、自适应分辨率这些优化，public文件夹里的图片得手动处理，效率极低。

• 缓存与版本管理混乱：public文件夹的图片文件名不变的话，浏览器会缓存旧图，用户看不到更新；如果每次改图都重命名，又会导致历史链接失效。云存储支持版本控制和灵活的缓存策略，能轻松解决这个矛盾。

• 权限控制做不到：public文件夹的文件是公开可访问的，没法给特定图片加权限（比如付费内容的配图）。云存储可以生成临时访问链接、设置Bucket权限，精准控制谁能访问哪些资源。

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