3步把S3图床变成"只认主"的保险箱，后端小白看完直接抄作业

去年有个做电商的朋友跟我吐槽：用户上传的头像存在MySQL里，数据库半年涨了800G，备份一次要通宵。我让他把图片迁到S3，只存引用，DB瞬间瘦回30G——这就是对象存储和关系型数据库的分工逻辑。

但迁上去只是第一步。真正让后端头疼的是：怎么防盗链？怎么让前端安全读取？怎么不让桶变成公共图床？

这篇指南从Node.js上传逻辑到IAM策略、CORS锁死，把每一层都拆开讲。适合已经会用AWS SDK、但还没搞懂权限体系怎么搭的开发者。

第一步：桶的创建和"假公开"陷阱

很多人创建S3桶时顺手点了"允许公共访问"，或者以为Block Public Access全开就万事大吉——这两种都错。

正确的姿势是：用CLI创建时显式指定区域，然后关闭ACL级别的公共访问，但保留桶策略的口子。

代码如下：

aws s3api create-bucket \

--bucket your-app-images \

--region ap-south-1 \

--create-bucket-configuration LocationConstraint=ap-south-1

aws s3api put-public-access-block \

--bucket your-app-images \

--public-access-block-configuration \

"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=false,RestrictPublicBuckets=false"

注意最后两个参数是false。我们要的不是"完全封闭"，而是"只认规则的封闭"——接下来用桶策略精确控制谁可以读。

第二步：桶策略的"Referer白名单"机制

S3的权限体系有两层：IAM（谁可以操作桶）和桶策略（什么条件下允许访问）。这里我们专注后者。

核心思路是利用HTTP的Referer头。当浏览器从你的网站加载图片时，会自动带上你的域名；直接复制URL到地址栏，或者别的网站嵌套你的图，Referer就不匹配。

策略文件长这样：

"Version": "2012-10-17",

"Statement": [

"Sid": "AllowOnlyFromMyWebsite",

"Effect": "Allow",

"Principal": "*",

"Action": "s3:GetObject",

"Resource": "arn:aws:s3:::your-app-images/public/*",

"Condition": {

"StringLike": {

"aws:Referer": [

"https://yourwebsite.com/*",

"https://www.yourwebsite.com/*"

应用策略：

aws s3api put-bucket-policy \

--bucket your-app-images \

--policy file://s3-bucket-policy.json

这个方案只适用于"公开但防 hotlink"的场景，比如商品图、文章配图。如果是用户私有文件（身份证、合同），别用Referer策略，直接走预签名URL——下面会讲。

第三步：CORS配置和前端的"跨域焦虑"

桶策略管的是"能不能读"，CORS管的是"浏览器让不让读"。如果你的前端用fetch或XMLHttpRequest直接请求S3，没配CORS会报经典错误：

Access to fetch at 'https://your-bucket.s3...' from origin 'https://yourwebsite.com' has been blocked by CORS policy.

配置CORS允许你的域名：

"AllowedHeaders": ["*"],

"AllowedMethods": ["GET", "HEAD"],

"AllowedOrigins": ["https://yourwebsite.com"],

"ExposeHeaders": [],

"MaxAgeSeconds": 3000

这里有个细节：AllowedOrigins不要写*，哪怕你暂时只有一个域名。未来加子域名或换主域时，你会感谢自己当初没偷懒。

第四步：Node.js上传逻辑——流式处理+元数据

前端把文件传给Node.js API，API再上传到S3。这个设计有两个好处：一是可以预处理（压缩、格式校验、病毒扫描），二是隐藏真实的S3桶名和路径结构。

用@aws-sdk/client-s3和@aws-sdk/lib-storage实现流式上传：

import { S3Client } from '@aws-sdk/client-s3';

import { Upload } from '@aws-sdk/lib-storage';

const s3Client = new S3Client({ region: 'ap-south-1' });

async function uploadImage(fileBuffer, fileName, mimeType) {

const s3Key = `public/${Date.now()}-${fileName}`;

const upload = new Upload({

client: s3Client,

params: {

Bucket: 'your-app-images',

Key: s3Key,

Body: fileBuffer,

ContentType: mimeType,

Metadata: {

'uploaded-by': 'user-id-123',

'original-name': fileName

const result = await upload.done();

return s3Key; // 只返回key，不返回URL

关键细节：Metadata字段可以存业务信息，比如上传者ID、原始文件名，方便后续审计和迁移。但别存敏感信息，S3元数据是明文的。

数据库只存s3Key，查询时动态生成URL。这样即使未来迁移到别的存储（Cloudflare R2、MinIO），只需改URL生成逻辑，不用改数据库。

第五步：预签名URL——私有文件的"临时通行证"

对于用户私有文件，桶策略那套Referer机制不够用：一旦URL泄露，任何人都能看。这时候需要预签名URL（Pre-signed URL）。

原理：用你账号的IAM凭证对请求进行签名，生成一个带过期时间的临时链接。S3验证签名有效且未过期，才返回文件。

实现：

import { getSignedUrl } from '@aws-sdk/s3-request-presigner';

import { GetObjectCommand } from '@aws-sdk/client-s3';

async function getPrivateImageUrl(s3Key, expiresInSeconds = 300) {

const command = new GetObjectCommand({

Bucket: 'your-app-images',

Key: s3Key

const signedUrl = await getSignedUrl(s3Client, command, {

expiresIn: expiresInSeconds

return signedUrl;

过期时间建议：用户头像5分钟，合同文件30秒，下载链接10分钟。根据场景调，太短用户体验差，太长有泄露风险。

预签名URL的生成是计算密集型操作吗？不是。它只是本地做HMAC签名，不调用AWS API，可以放在高频接口里。

第六步：IAM最小权限原则

你的Node.js应用需要IAM凭证来操作S3。千万别用根账号密钥，要创建专用IAM用户，并绑定最小权限策略。

"Version": "2012-10-17",

"Statement": [

"Effect": "Allow",

"Action": [

"s3:PutObject",

"s3:GetObject",

"s3:DeleteObject"

],

"Resource": "arn:aws:s3:::your-app-images/*"

注意Resource末尾的/*。如果写成arn:aws:s3:::your-app-images，策略对桶内对象不生效，这是新手常见坑。

生产环境建议用IAM Role而不是长期凭证。如果部署在EC2或ECS，直接绑定Role；如果是Lambda，用执行角色。这样密钥不会出现在代码或环境变量里。

一个容易忽略的细节：Content-Type

上传时如果不指定Content-Type，S3会默认application/octet-stream。这会导致浏览器下载图片而不是直接展示，用户体验崩掉。

务必从上传请求中读取MIME类型，或者通过文件魔数（file-type库）检测，显式设置Content-Type。

另外，如果你用了CloudFront做CDN，记得配置缓存行为，让Content-Type参与缓存键。否则不同格式的同名文件会互相污染缓存。

这套架构跑通后，一个中等规模的UGC平台（日活50万，人均3张图）的存储成本大概在每月200-400美元区间，取决于访问频率和是否走CDN。相比自建MinIO集群加运维人力，这个账不难算。

你现在的图片存储方案是什么？有没有遇到过Referer被绕过、或者预签名URL过期时间调不准的坑？