网站主页放置图片，第一件事不是打开代码编辑器，而是想好图片存储位置。很多人上来就写上传按钮，图片直接保存在服务器本地磁盘，一旦服务器迁移或者重新部署，图片文件全部丢失。这个问题比图片上传功能本身更需要优先考虑。
存储空间分为两块，一块是运行网站程序的应用服务器，另一块专门存放文件的对象存储。小型站点、个人博客，访问量不大的时候，图片直接放到服务器某个目录，例如 /var/www/uploads，数据库只记录文件名或者路径。优势是简单，不用额外配置，程序调用move_uploaded_file就能完成保存。缺点很明显，磁盘容易写满，扩容麻烦，多台服务器部署还需要同步文件；图片数量变多之后，备份和迁移工作量很大。
稍微正式一点的方案选择对象存储。国内阿里云OSS、腾讯云COS、七牛云、又拍云，国外AWS S3或者Cloudflare R2。这类服务本质是依靠HTTP接口读写文件的存储仓库，上传图片拿到URL，数据库保存这个URL，前端直接引用图片地址。应用服务器不存放图片本体，只负责生成上传凭证和记录地址。这样应用服务器可以随意扩容、重启、更换机器，图片访问地址保持不变。费用方面，存储本身很便宜，每月几块钱可以存放大量图片，真正消耗费用的是下行流量和请求次数，图片访问量越高，流量花费越高。
主页图片上传分为两种场景。第一种是站长后台上传，文章封面、产品图这类。一般通过后台管理页面表单选择文件，提交之后服务器接收文件，转存到对象存储或者本地目录。第二种访客上传，用户头像、晒图等。这种场景不能把存储密钥暴露在前端，后端生成临时上传凭证，前端拿着凭证直接上传对象存储，上传完成把返回URL传给后端存入数据库。直传优势是文件不经过应用服务器，节省带宽和内存，大文件效果更明显。
前端选择文件最基础的方式是input type="file"，增加accept="image/*"限制文件类型。移动端拍照上传可以加上capture属性。想要图片预览，用FileReader读取为base64放到img标签，或者用URL.createObjectURL更节省内存。多图上传开启multiple，获取FileList循环处理。拖拽上传实现不难，监听drop事件，从dataTransfer.files拿到文件，复用上传流程。这些不需要框架，原生JS就能够实现。
上传之前最好压缩图片。手机拍摄照片动辄四五兆，直接上传速度慢，占用存储空间，也消耗用户流量。前端借助canvas缩小图片尺寸，导出jpeg或者webp，质量设置0.8，体积通常减少七成以上，肉眼看不出明显差异。服务端再做一轮压缩，使用sharp或者imagemagick，顺带生成缩略图。原图保留一份，列表页加载缩略图，详情页加载大图，这个习惯能省下大量带宽。
图片格式选择，webp兼容性现在已经很好，同等画质体积相比jpeg小三成，新版Chrome、Firefox、Safari全部支持。avif压缩率更高，但编码速度慢，兼容性还在完善，暂时不用优先选用。如果用户群体存在老旧设备，可以使用picture标签做降级，优先加载webp，不支持的浏览器加载jpeg。成本很低，收益不错。
文件路径和命名不要使用中文，也不要直接沿用用户上传原始文件名。中文名称在部分服务器、CDN环境会出现乱码，原始文件名还可能携带特殊字符，存在路径穿越安全隐患。常用方案是md5或者时间戳拼接随机字符串，加上原始文件后缀。目录按日期划分，例如2026/09/15/xxxx.jpg，避免单个目录文件数量过多，排查问题也方便。
权限和安全很容易被忽略。上传目录绝对不能配置执行权限，防止有人上传伪装成图片的php文件直接执行。Nginx配置上传目录仅允许静态文件访问，关闭该路径php解析。文件类型校验不能只依靠后缀名，同时校验MIME类型和文件头，服务端调用getimagesize这类函数确认文件确实是图片。限制文件大小，超出阈值直接拒绝，不要等待文件完整传输之后再判断。
公开访问的图片最好搭配CDN。对象存储直接对外访问，跨地域访问延迟偏高。CDN把图片缓存到靠近用户的边缘节点，首次回源之后后续请求直接读取缓存，访问速度提升，还可以扛住突发流量。配置只需要添加CNAME，图片这类静态资源缓存时长可以设置较长，半年都没问题。更新图片更换文件名或者增加版本参数，避免用户浏览器读取旧缓存。
备份单独说明。保存在服务器本地的图片，跟着服务器做快照或者定时rsync同步。对象存储存放的图片，开启版本控制或者跨区域复制，误删之后可以恢复。数据库保存URL，如果存储桶更换域名，批量替换链接工作量很大。所以一开始尽量使用自定义域名，不要用服务商默认域名，后续迁移只修改DNS解析，数据库链接不用改动。