ECS磁盘告警引发的OSS迁移实践：从本地存储到对象存储的完整记录

凌晨四点被监控电话叫醒，我爬起来看了一眼：ECS数据盘使用率98%，上传目录占了大头。点开日志，全是昨天用户集中上传的产品图片和视频。临时清了一轮过期文件，但我知道这治标不治本。项目从第一天起就是“文件上传—本地存储”的简单链路，nginx直接暴露一个upload目录，代码也好写，前端收文件，Java接手往磁盘一扔完事。可是当文件量从几个GB涨到几百GB，本地存储的方案开始处处掣肘。

这篇文章就是想把这次从本地存储迁到阿里云OSS的完整过程写下来。里面没有炫技，有的是一步步踩出来的方案选型、签名直传代码骨架、存量文件迁移策略，以及上线后真正会遇到的坑。适合那些文件量正在变大、开始琢磨“要不要换OSS”的团队参考，也适合第一次接OSS的开发者直接抄作业。

1. 磁盘告警那晚之后，我决定把上传文件从本地挪到OSS

先复盘一下当时盘面的真实情况，不然为什么换OSS很容易被人理解成“换个地方存文件，把磁盘换成云服务”。如果只是这样，那问题依然存在，只是换了个地方而已。

1.1 事故复盘：本地存储不只是“多一块磁盘”的问题

那天晚上我顺手查了几个关键指标，越查越睡不着。ECS数据盘是500GB高效云盘，单价不高，但已经用了大半。真正让人头疼的不是容量，而是三个长期被忽略的隐患。

第一个隐患是备份。文件直接在系统盘外的数据盘上，我下意识以为“数据盘坏了大不了重启”，但云服务商对本地盘的可靠性从来不做承诺。我们能做的备份方案是什么？把几百GB文件定时rsync到另一个目录？那不叫备份，那叫复制，机器没了数据照样没。如果打包传到OSS，那才是把鸡蛋分到了另一个篮子。

第二个隐患是扩容。磁盘快满时最直接的方案是买一块更大的云盘挂载上去，把数据rsync过去，再改fstab挂载点。听起来不复杂，但涉及停机窗口，涉及rsync期间新增文件的丢失风险，还要处理历史目录里那些只知道路径、不知道归属的孤儿文件。我第一次尝试扩容时就发现，rsync跑完后，有几万个临时文件因为还在被进程占用而跳过，第二天接口图片大面积404。做这种运维操作，运维同学心里是发虚的。

第三个隐患是访问路径。文件存在本地时，访问链路通常是nginx直接alias到指定目录，代码里存的是/uploads/2024/xx.jpg这种相对路径。一旦文件不在当前机器，比如以后要多加一台服务器做负载均衡，那文件又要想办法搞共享存储，要么NFS要么自建分布式文件系统，成本陡增。

所以本地存储的架构并不是“写代码方便”那么简单，它把容量、可靠性、扩展性全部耦合在了那一台ECS里。文件上传这件事看似简单，但文件数量一旦上来，底层存储怎么选，直接决定了线上会不会半夜响警报。

1.2 换方案前先梳理：我们的文件系统到底需要什么

很多文章一上来就教你怎么在OSS控制台建Bucket、怎么调用SDK，却很少问一句：你的系统需要文件存储提供什么能力？我按自己的场景梳理了一圈，列了下面这六条需求：

• 至少两份冗余，机器损坏不会导致用户上传的图片永久丢失。
• 容量不需要提前规划，今天10GB，明年100GB，都能平滑增长。
• 上传接口不能阻塞太久，尤其视频、大图这种动辄几十MB的文件，不能卡住一个HTTP请求在那儿推数据。
• 下载和预览要快，图片加载不能比原来本地nginx慢一个量级。
• 路径规则能兼容老数据，不要把老文件全部重命名，否则数据库里的存量记录全都需要清洗。
• 权限要可控，至少要满足“哪些人能上传、哪些人能读”的简单判断。

对照这六条，再把“自建FastDFS”“继续扩本地盘”“上OSS”三个方案放在一起比，结论就很清晰。FastDFS能解决分布式和冗余问题，但要自己维护tracker、storage，还要处理小文件存储效率低的问题，对小团队来说运维成本偏高；继续扩本地盘只解决容量，不解决备份和扩展；OSS几乎是为这些需求量身定做的。

这里多说一句，OSS不是唯一选择，其他云厂商的对象存储也都行，关键是“对象存储”这种产品形态才匹配我们的需求。对象存储的底层是海量分布式对象，每个文件都是一个带元数据的对象，天然没有单机容量限制，自带冗余，访问走HTTP接口，和业务代码解耦。理解这一点，后面很多“为什么OSS这么设计”的问题就都好解释了。

2. 迁移选型：先别急着写代码，服务端中转和客户端直传必须二选一

在本地存储阶段，文件流向是“浏览器→后端接口→磁盘”。换成OSS之后，多了一个问题：文件到底是继续先到后端，由后端再传给OSS，还是浏览器直接往OSS传？这两条路差别极大，一开始我就想直接照搬旧逻辑，让后端把文件流透传给OSS，代码简单，和原来几乎一样。后来评估了真实的压力和网络链路，才意识到这个选择要谨慎。

2.1 OSS的基础概念：Bucket、Endpoint、AccessKey与权限控制

不管选哪条路，有四个概念绕不开。

Bucket是存储空间的名字，相当于一个全局唯一的顶层文件夹。Endpoint是OSS服务的访问地址，比如华东2（上海）的Endpoint是oss-cn-shanghai.aliyuncs.com。同一个地域的ECS访问OSS还有一个内网地址，形如oss-cn-shanghai-internal.aliyuncs.com，走内网不产生流量费用，速度也快，这个细节后面排查问题时会再次提到。

AccessKey是访问密钥，包含AccessKeyId和AccessKeySecret，相当于账号密码。无论用服务端SDK还是客户端SDK，都会用到它。最忌讳的做法是把主账号的AccessKey写在代码或前端配置里。正确做法是创建RAM子账号，只授予目标Bucket的读写权限，权限范围越小越好，即使泄露也能把损失控制在一个存储空间内。

我见过不少团队直接把Bucket设为公共读，所有对象任何人都能通过URL访问。这在小项目里可能足够，但一旦有私密文档、账单、用户证件照，这就是事故。OSS默认的权限是私有读写，如果不想让文件公开，就不要开启公共读。外网需要临时访问时，用签名URL或者配合CDN鉴权解决。

2.2 模式A：服务端中转上传，适合内网工具和流量小的管理后台

服务端中转是指后端接口先接收到前端传上来的MultipartFile，再用OSS SDK写进Bucket。逻辑简单，改造面小，FastAdmin这类PHP后台的OSS插件也基本都是这个思路，把上传类里的本地保存动作换成OSS SDK调用。

代码结构大概是这样：

java复制@Service
public class OssStorageService {

    @Value("${aliyun.oss.bucketName}")
    private String bucketName;

    @Value("${aliyun.oss.endpoint}")
    private String endpoint;

    private final OSS ossClient;

    public OssStorageService(OSS ossClient) {
        this.ossClient = ossClient;
    }

    public String upload(MultipartFile file, String bizType) throws IOException {
        // 目录用日期分片，避免一个目录下对象数量过多
        String key = "uploads/" + bizType + "/" + LocalDate.now() + "/"
                + UUID.randomUUID() + getExtension(file.getOriginalFilename());

        ObjectMetadata metadata = new ObjectMetadata();
        metadata.setContentLength(file.getSize());
        metadata.setContentType(file.getContentType());

        try (InputStream in = file.getInputStream()) {
            ossClient.putObject(bucketName, key, in, metadata);
        }

        // 这里返回的是对象Key，不是完整URL。实际下载时再根据Bucket权限拼接域名或签名
        return key;
    }
}

服务端中转最大的优点是可管可控。改造时，原来的Controller完全不用动，Service层的接口签名也可以保持不变，只是“存储”这一层从本地磁盘换成OSS。迁移期间想双写，想加消息队列，想先压缩再上传，都方便。

缺点也很明显：文件先经过后端服务器，再上传到OSS，带宽压力全在ECS上。用户上传一个100MB的文件，后端服务器就要先收下这100MB，再往OSS吐100MB，而客户端直传时ECS只承担中转流量费的一小撮签名请求。如果上传量不大，或者系统本身就是内网管理后台，服务端中转完全够用，没必要为了“直传”而直传。

2.3 模式B：客户端签名直传，适合公网访问的高并发场景

客户端直传的流程是：前端先请求后端一个签名接口，后端用AccessKeySecret对上传策略签名，然后把签名、 Bucket地址等信息返回给前端。前端拿到这些临时凭证后，再直接向OSS发起上传，整个文件数据流不再经过业务服务器。

我在这条路上纠结了很久，因为直传的代码链条明显更长。但后来算了一笔账：我们业务高峰期每秒钟可能同时有几十个人上传，假设每人平均传10MB，如果走服务端中转，这部分流量全部打到ECS上，按当时服务器的带宽配置，很快就把出口带宽占满。而直传可以把这部分流量直接分流到OSS，业务服务器只需要处理轻量级的签名请求。

直传还有一个额外的好处，OSS的断点续传、分片上传可以由前端SDK直接触发，大文件上传体验比后端中转流畅得多。OSS上传SDK对分片并发做了优化，网速波动时还能自动重试。

代价是，签名接口的安全性直接决定了Bucket会不会被滥用。如果你把“全权限AccessKey”在前端暴露出来，别人只要抓到请求，就能把你的Bucket当免费网盘用，甚至删除里面所有文件。所以直传方案通常配合STS临时凭证来使用，临时凭证限时、限权限，过了有效期自动失效。

2.4 双模式的取舍：我是怎么定下来的

最终我采用的是混合方案：常规的图片、文档上传走客户端签名直传；管理后台的一些内部导入文件，以及需要服务端做病毒扫描、格式转换的文件，走服务端中转。

这样取舍的原因其实很简单：对外部用户开放的接口，流量大且不可控，必须直传；内部运营使用的后台，量小、权限要求高，可能还需要在文件入库前做一轮自定义处理，这时服务端中转反而更灵活。

如果你在纠结自己项目选哪个，先看两个指标：一个是同时上传的并发量，一个是文件平均大小。并发低、文件小，直接服务端中转最省事；并发高或者文件动不动几十MB，那就上直传。

3. 直传OSS的签名接口与前端实现细节

既然要直传，这里就把整条链路拆开讲。很多人第一次看直传代码会犯迷糊，因为涉及“上传策略(Policy)”“签名(Signature)”“POST表单域”这几个概念。一句话解释就是：后端写一张“允许上传的凭证”，前端带着这张凭证去OSS柜台办理上传，OSS验过凭证才收你的文件。

3.1 为什么签名要在服务端算，token为什么不能下发全权限AK

先明确一个安全底线：任何情况下都不能把AccessKeySecret下发到前端。AccessKeySecret是用来生成签名的密钥，一旦暴露，等于把Bucket的管理权限拱手送人。

所以主流做法是服务端持有AccessKeySecret，生成一个短期的上传凭证。凭证内容可以自定义，比如允许上传的目录前缀、文件大小上限、有效期。前端只拿到这些经过签名的内容，上传时OSS会验证签名是否合法、文件是否在允许的范围内。

如果想更进一步，服务端可以不直接用自己的AccessKeySecret签名，而是调用STS服务申请一个临时AccessKey。临时AccessKey包含AccessKeyId、AccessKeySecret和SecurityToken，有效期最短可以设置900秒，最长几小时。STS的优势是即使某个前端页面被人恶意刷请求拿走了临时AK，它也只能在短时间内上传到指定目录，破坏范围被压缩得很小。

两种方式我在项目里都实现了。简单说，如果只是给自有前端用，服务端直接签名完全可以接受；如果担心临时凭证泄露面，或者第三方开放的场景比较多，就上STS。

3.2 签名接口的Java代码骨架

我用的是Spring Boot，签名接口本质上就是两个步骤：构造Policy JSON，用HmacSHA1算出签名。先给出一份可运行的代码：

java复制@RestController
@RequestMapping("/oss")
public class OssSignatureController {

    @Value("${aliyun.oss.accessKeyId}")
    private String accessKeyId;

    @Value("${aliyun.oss.accessKeySecret}")
    private String accessKeySecret;

    @Value("${aliyun.oss.bucketName}")
    private String bucketName;

    @Value("${aliyun.oss.endpoint}")
    private String endpoint;

    /**
     * 生成客户端直传凭证
     * dirPrefix 表示允许上传的目录前缀，比如 user/avatar
     */
    @PostMapping("/policy")
    public Map<String, String> policy(@RequestParam String dirPrefix) {
        String dir = "uploads/" + dirPrefix + "/" + LocalDate.now().toString();
        long expireTime = System.currentTimeMillis() / 1000 + 300;

        SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
        format.setTimeZone(TimeZone.getTimeZone("UTC"));

        // 构造OSS PostObject Policy，限制文件大小最大100MB，并且必须上传到dir前缀下
        String policyJson = "{\"expiration\":\"" + format.format(new Date(expireTime * 1000))
                + "\",\"conditions\":["
                + "[\"content-length-range\",0,104857600],"
                + "[\"starts-with\",\"$key\",\"" + dir + "\"]"
                + "]}";

        String base64Policy = Base64.getEncoder()
                .encodeToString(policyJson.getBytes(StandardCharsets.UTF_8));

        String signature = Base64.getEncoder().encodeToString(
                HmacSHA1(base64Policy, accessKeySecret));

        Map<String, String> result = new HashMap<>();
        result.put("accessid", accessKeyId);
        result.put("policy", base64Policy);
        result.put("signature", signature);
        result.put("dir", dir);
        result.put("host", "https://" + bucketName + "." + endpoint);
        return result;
    }

    private byte[] HmacSHA1(String data, String key) throws Exception {
        SecretKeySpec spec = new SecretKeySpec(key.getBytes(StandardCharsets.UTF_8), "HmacSHA1");
        Mac mac = Mac.getInstance("HmacSHA1");
        mac.init(spec);
        return mac.doFinal(data.getBytes(StandardCharsets.UTF_8));
    }
}

几个容易被忽略的细节：

• expiration必须用UTC时间，并且格式是ISO8601，很多第一次写签名的人本地调试时用的是本地时区，结果OSS始终报Policy expired。
• Policy里建议带上content-length-range，否则token能传任意大小的文件，服务端没法从源头限制。
• starts-with限定key前缀，相当于只允许上传到某个目录。这个目录由后端根据自己的业务逻辑生成，不能让前端随意传，否则别人可以任意覆盖路径。
• host建议由后端拼好返回给前端，避免前端写死一个域名，以后换地域或绑定自定义域名又要改前端。

如果完全不知道Policy怎么构造，最简单的方式是先到OSS控制台的“客户端直传”文档里复制一个示例，理解字段后再改造成自己的接口。我一开始就犯了想当然的毛病，以为把服务端SDK的Client搬到前端就算直传，结果前端SDK用起来一直报签名错误，后来逐字对比Policy才发现expiration的时区没转。

3.3 前端上传流程与CORS配置

前端拿到签名后，用表单方式把文件和签名参数一起POST到OSS，我的简化实现如下：

javascript复制async function uploadToOss(file, dirPrefix) {
  const resp = await axios.post('/api/oss/policy', { dirPrefix });
  const { accessid, policy, signature, dir, host } = resp.data;

  // 按日期 + UUID 拼接最终对象名
  const key = `${dir}/${generateUuid()}-${file.name}`;

  const formData = new FormData();
  formData.append('key', key);
  formData.append('policy', policy);
  formData.append('OSSAccessKeyId', accessid);
  formData.append('signature', signature);
  formData.append('success_action_status', '200');
  formData.append('file', file);

  // 如果使用STS临时凭证，还需加上token字段
  // formData.append('x-oss-security-token', token);

  const uploadResp = await axios.post(host, formData, {
    headers: { 'Content-Type': 'multipart/form-data' },
    onUploadProgress: (e) => {
      console.log('upload progress', e.loaded / e.total);
    }
  });

  return key;
}

这里有个跨域问题，所有浏览器直传OSS的请求必然跨域。需要在OSS控制台对Bucket配置CORS规则，允许来源填你的业务域名，比如https://your.domain.com；允许方法勾选GET、POST、PUT、DELETE、HEAD；允许Headers填*，如果需要读取上传ETag，再把ETag加进Expose Headers。配置完之后，生产环境前端的表单上传请求才不会因为浏览器同源策略被拦截。

调试CORS时最容易遇到的坑是浏览器缓存了旧的规则，改了CORS后要强制刷新或无痕模式重新测试，不然你会一头雾水地发现规则明明改好了但请求还是被拦截。

3.4 上传完成后的业务入库：控制权的取舍

直传有个天然的麻烦：文件已经到OSS了，但业务数据库里的记录还没更新。如果用户传完就关掉页面，业务库里可能根本不知道这个文件的存在，日积月累就会产生一堆“孤儿文件”。

针对这个缺口，我建议不要在OSS回调上绕太多弯子。最简单的做法是：前端上传成功后，再调用一次业务接口把key、文件名、大小等信息写库。后端在写库时可以顺手校验key是否真的存在，或者通过OSS的HEAD请求确认对象元数据，防止前端伪造入库记录。

OSS本身支持上传回调，也就是文件上传成功后OSS向你的应用服务器发一个HTTP请求，把上传信息同步给你。这个机制能解决“上传和业务入库不在一个事务”的问题，但也要求你的回调接收地址稳定可靠，且要防范回调和业务请求之间的时序问题。实际项目里我先把回调的逻辑做出来了，最后又因为排障成本高，还是换成了“前端成功回调业务接口”。如果你团队人少、排障精力有限，从简单方案开始，等真的需要再上OSS回调也不迟。

4. 存量文件迁移与切换策略，这一步比想象中容易翻车

新文件走OSS之后，老文件还躺在ECS磁盘上，怎么把存量文件安全地搬过去，是整个迁移过程中最容易翻车的一步。这里说的“翻车”不只是拷贝失败，而是搬完以后用户访问老图片的URL全都失效。

4.1 用ossutil搬历史数据：先小批量试，再全量并发

ossutil是阿里云提供的命令行工具，用来批量操作OSS。大目录迁移时我用的命令大概是这样：

bash复制ossutil cp -r /data/www/uploads oss://my-bucket/backup/2024/ \
  --update \
  --bigfile-threshold 200m \
  --jobs 5 \
  --parallel 5

参数解释一下：--update表示只覆盖源端比目标端新的文件，适合多次增量执行；--bigfile-threshold 200m表示超过200MB的文件自动走分片上传，文件大时更稳；--jobs和--parallel控制并发，刚开始不要设太大，否则容易把带宽打满，影响线上业务。

但真正重要的不是命令参数，而是先跑一个几十GB的小目录做试验。我当时先迁了一个测试Bucket，用小目录验证文件完整性和时间戳，再拿几个关键路径排查遗漏，最后才启动全量任务。因为ossutil是基于文件列表并发拷贝的，一旦中途失败它会自动重试，但不会保证每条日志你都看得到，所以迁移完一定要抽检。

抽检的最有效方式是随机取一部分对象做HEAD请求，对比Content-Length和LastModified。ossutil日志里也有输出，建议日志输出到一个文件，迁移完成后用grep筛Error。全量迁移跑完后，把源目录和Bucket里文件数量对一下，差得多就说明有漏网之鱼。

4.2 双写与切读：切换过程不能只说“改一行store实现”

代码层面把存储接口抽象出来不难，定义FileStorage接口，本地实现和OSS实现各写一个，通过配置切换就行。但生产环境切换不是在配置中心改个值那么简单。

我采用的切换策略分三步：

第一步，双写阶段。代码里同时写本地磁盘和OSS，写本地是为了万一OSS有问题可以立刻回滚，写OSS是为了让新产生的文件在OSS上积累起来。这一步要持续一段时间，观察OSS上传成功率、耗时和错误日志。

第二步，切读阶段。把读取逻辑优先指向OSS，如果OSS上不存在这个对象，再回退到本地路径读取。这一步要依赖OSS的doesObjectExist判断，但是每次读取都先HEAD一次会有额外开销，所以我在关键路径上做了内存缓存，短时间内重复请求同一个key不会反复查OSS。

第三步，停写本地。确认OSS读写稳定后，把双写里的本地写停掉，同时保留一段时间的本地历史数据，不要立刻删磁盘，至少要保留一个完整的备份周期。

这样设计的好处是，每一步都有回滚路径。本地磁盘在迁移期间并没有立刻成为历史包袱，它反而是最可靠的兜底。

4.3 平滑期方案：OSS镜像回源是存量URL最稳的兜底

如果老文件的URL已经被外部引用了很多，比如短信、邮件、其他系统里都存着老路径，那就不能只依赖业务代码内部切换。更稳的方式是利用OSS的镜像回源能力。

镜像回源的意思是，当用户请求OSS上的某个对象时，如果该对象不存在，OSS会自动到配置的源站地址拉取这个文件并保存到OSS，然后返回给用户。简单说，OSS充当了“读到没有就回源拉取”的缓存层。

我把Bucket的镜像回源地址配置成原来那台ECS上的nginx地址，这样存量老URL即使没有提前迁移到OSS，用户第一次访问时OSS也会自动从源站拉取并缓存下来。这个机制大大减少了迁移窗口期的数据同步压力，不需要在切换前把所有文件一次性搬完，而是“访问到哪个，就补哪个”。

使用镜像回源有几点要注意。回源地址必须在OSS控制台或API配置成可信的域名，否则OSS会变成某种意义上的代理，存在被刷流量的风险。回源拉取的文件大小也会计入流量，如果某个超大文件被频繁首次访问，流量账单会有一点波动。所以镜像回源适合作为过渡手段，长期稳定后还是要靠全量同步来兜底。

5. 上线一个月后遇到的坑，按排查路径逐一盘

迁移完成不等于万事大吉。OSS SDK接入后，真正消耗时间的是那些“代码看着没问题，实际表现很奇怪”的线上问题。我挑几个印象最深的，按排查路径写出来。

5.1 内外网Endpoint混用导致本地调试通过、线上超时

这个坑的隐蔽程度极高。开发环境在本地笔记本上跑后端，访问公网Endpoint没问题；部署到生产ECS后，同一个Bucket如果用公网Endpoint访问，也能通，就是慢，而且流量费用一直在涨。

问题是ECS和Bucket在同一个地域时，最合理的方式是使用内网Endpoint，比如华东2地域的Bucket内网地址是oss-cn-shanghai-internal.aliyuncs.com。内网Endpoint不会收取流量费，因为数据走的是云厂商的内网骨干，不经过公网，而且在同地域访问时延更低。

排查方法很简单：在ECS上执行curl -v对比两个Endpoint的响应时间。如果你发现生产上OSS上传耗时从几十毫秒变成几百毫秒甚至超时重试，先检查配置里是不是用了公网Endpoint。

我当时的翻车点在于：配置中心里Endpoint写在了一个公共配置里，本地和测试环境都用公网地址，结果上了生产就各种慢。后来把配置按环境拆开，生产环境注入内网Endpoint，问题立刻消失。

5.2 Content-Type“不听话”与下载文件名乱码

上传文件到OSS后，如果用浏览器直接访问对象URL，可能会发现PDF没有直接预览而是被下载，中文文件名变成一串百分号编码，图片Content-Type变成了application/octet-stream。

原因在于客户端上传时没有正确带上Content-Type，或者服务端SDK上传时用默认的application/octet-stream覆盖了真实类型。OSS存储的是对象元数据，如果写入时Content-Type就不对，后续回调URL、预览、下载都会跟着错。

解决方向有两个。一是前端在上传前通过文件二进制判断MIME类型，通过x-oss-meta-自定义元数据把原始文件名一起传过去；二是上传完成后，服务端再用SDK对对象做一次元数据修正，调用copyObject并重新指定Content-Type。

我后来在Service层写了一个统一处理逻辑：任何方式上传的对象，都会同步把原始文件名存到自定义元数据originalName里，业务系统需要下载时会读取这个自定义元数据再拼到Content-Disposition头中，避免中文文件名下载乱码。

5.3 大上传文件的选型：简单上传、分片上传、追加上传

很多初次接OSS的人会把所有文件都用putObject一把梭，文件小的时候没问题，文件超过几百MB或者网络不稳定时，一个连接断了整次上传就失败，只能重来。

OSS提供了三种常用上传方式，需要按场景选择：

在我们的业务里，图片、普通的文档用简单上传就够；视频和超过200MB的安装包，切换到分片上传后，上传成功率明显提升。分片上传需要先initiateMultipartUpload拿到uploadId，再把每个分片分别上传，最后调用completeMultipartUpload合并。如果中途断了，下次可以用同一个uploadId从已完成的分片继续传，而不是全部重新上传。

要留意的是，分片上传的状态不会自动清理，如果客户端一直不调用complete，OSS会保留一个未完成的分片任务，时间长了会占用存储空间。OSS有生命周期规则可以清理过期分片，建议在控制台配置一条针对uploads/前缀、保留7天的分片清理规则。

5.4 Bucket权限、防盗链与文件头校验：安全这关怎么补

既然和文件上传有关，安全就是一个绕不开的话题。外部用户能直传OSS之后，业务侧的防护不能只依赖OSS的签名，因为签名只解决“谁能传”，不解决“传的是什么”。

我自己踩过的最典型问题是，最初只在前端限制文件类型，后端签名接口也只检查了文件名的后缀，结果有人用脚本改了POST请求的Content-Type，绕过前端限制往Bucket里丢了一个可执行的HTML文件。虽然没有造成直接危害，但一旦该文件被当成静态资源访问，就是存储型XSS的入口。

事后我做了三层防护，不是只改一个点。

第一层，后端签名接口不信任“文件名后缀”和前端传来的Content-Type。服务端在生成Policy前，可以对文件内容进行预检，或者约定所有上传文件在业务代码入库后立即做一次内容检测。对图片、文档这类静态资源，最实际的是把上传对象的Content-Disposition设置为attachment，让浏览器不要直接执行。

第二层，开启OSS的防盗链。在OSS控制台配置Referer白名单，只允许自己域名下的页面引用对象URL，这个防不住所有恶意请求，但能挡住大部分“别人拿了URL到处贴”的场景。

第三层，Bucket权限收敛。Bucket不开启公共读，所有对外访问统一经过业务域名或CDN签名。如果你一定要做公开分享，那就生成带有效期的签名URL，而不是让整个Bucket裸奔。

OSS的权限模型很灵活，RAM Policy可以精确到某个子账号只能操作哪个目录、只能调哪几个API。不要怕建子账号麻烦，按业务线拆AccessKey才是最省心的。

最后再说一点感受。OSS的接入难度其实很低，最耗精力的环节永远是“文件路径怎么设计”和“权限边界怎么划”。我见过不少团队把本地存储的一切习惯原封不动搬到OSS，比如用原文件名直接当ObjectName，也不做任何路径规划，结果对象一多，前缀混乱，生命周期规则根本没法按目录配置。对象存储虽然叫“存储”，但它更像一个无限大的KV数据库，Key的设计直接决定后续的运维成本。所以设计目录前缀时，一定要把业务类型、日期分片、随机文件名这些因素都考虑进去，这是我在整个迁移过程中觉得最值回票价的一步。