对象存储（OSS）面试题

星辰逐梦2026/7/1大约 21 分钟

对象存储（OSS）面试题

导语：对象存储是海量非结构化数据的标准解法，面试重点在三种存储的差异、多副本与纠删码、前端直传的三种授权方式（预签名 URL / STS / Post Policy）、分片上传与断点续传、秒传去重，以及安全与 CDN 结合。本篇只覆盖高频考点，共 12 题。

一、概念与底层原理

1. 什么是对象存储？与块存储、文件存储有什么区别？

答：三者的本质区别在于数据组织方式与访问协议：

维度	块存储（Block）	文件存储（File）	对象存储（Object）
数据单位	固定大小的块（512B / 4KB）	文件 + 目录树	对象 = 数据 + 元数据 + 唯一 Key
访问方式	裸设备（`/dev/sdb`），需格式化 + 文件系统	POSIX / NFS / SMB，可 `mount`，可随机读写	HTTP RESTful API（GET/PUT/DELETE），不支持部分修改
命名空间	无	层级目录树	扁平（Bucket 下全是 Key，`/` 只是命名约定）
典型协议	SCSI / iSCSI / NVMe	NFS / CIFS / SMB	S3 / OSS / Swift
性能特征	低延迟、高 IOPS，适合随机读写	中等（元数据操作有开销）	高吞吐高并发，但单对象延迟高于块存储
扩展性	有限（受阵列规模限制）	中等（元数据服务器易成瓶颈）	近乎无限（水平扩展）
典型产品	云硬盘 EBS、Ceph RBD	NAS、NFS、CephFS	阿里云 OSS、AWS S3、MinIO、Ceph RGW
典型场景	数据库、虚拟机磁盘、容器持久卷	共享文件、代码仓库、配置分发	图片/视频/备份/日志/静态网站/数据湖

一句话记忆：

块存储：给数据库和虚拟机用，像"一块裸盘"；
文件存储：给人用，像"共享文件夹"，有目录树、可改文件；
对象存储：给海量非结构化数据用，像"无限大的网盘"，按 Key 访问、只能整存整取。

对象存储最关键的两个特性（面试加分）：

对象一旦写入不可修改——没有"修改第 100 字节"这种操作，更新只能覆盖整个对象（PUT 新版本）。这既是它高扩展性的代价，也是它与文件存储最本质的差异；
扁平命名空间——没有真正的目录，a/b/c.jpg 中的 / 只是 Key 的一部分，只是控制台"看起来像目录"。

2. 对象存储的核心概念有哪些？

答：

概念	说明
Bucket（存储空间）	对象的顶层容器，类似命名空间。名称全局唯一（同一云厂商所有用户内唯一）；拥有独立的权限、地域、计费属性
Object（对象）	存储的基本单位 = 数据 + 元数据 + 唯一标识（Key）；大小从 0 字节到 TB 级
Key（对象键）	对象在 Bucket 内的唯一标识，相当于"路径 + 文件名"；`/` 只是命名约定，不是真目录
Region（地域）	数据所在的物理区域，选型时考虑延迟、合规（数据主权）、成本
Endpoint（访问域名）	访问入口，如 `oss-cn-hangzhou.aliyuncs.com`
AccessKey / STS 凭证	访问凭据（长期密钥 vs 临时凭证）
ACL / Bucket Policy	权限控制（私有 / 公共读 / 公共读写，或细粒度策略）
Storage Class（存储类型）	标准 / 低频访问 / 归档 / 冷归档 / 深度冷归档

两个高频考点：

Bucket 名称全局唯一：因为 Bucket 名会直接出现在访问域名里（如 https://my-bucket.oss-cn-hangzhou.aliyuncs.com），所以不同用户之间也不能重名；
存储类型分层是降本的核心手段：以阿里云 OSS 为例有五档——标准 → 低频访问 → 归档 → 冷归档 → 深度冷归档，成本递减、取回时间与取回费用递增（从"实时可读"到"解冻需数小时"），价格差距可达十几倍。实践中通过生命周期规则自动转档（如"30 天未访问转低频、90 天转归档、到期删除"）。

3. 对象存储如何保证数据可靠性与可用性？（多副本 vs 纠删码）

答：两种冗余机制，工程上按数据冷热组合使用：

维度	多副本（Replication）	纠删码（Erasure Coding, EC）
原理	把同一份数据完整复制到 N 个节点/磁盘	把数据切成 k 个数据块 + m 个校验块（如 4+2、8+3），用数学编码提供冗余
空间开销	3 副本 = 300%（有效利用率约 33%）	4+2 = 150%（利用率约 67%）；8+3 ≈ 137%（利用率约 73%）
容错能力	3 副本可容忍 2 个副本故障	4+2 可容忍任意 2 块丢失；8+3 可容忍任意 3 块
读性能	高（直接从任一副本读）	较高（可并发读多个块，但需解码）
写性能	好（写多份，但无需计算）	差：需计算校验块，写放大明显、CPU 开销大
重建 / 恢复速度	快（直接拷贝副本），但会冲击源节点带宽	慢：需读取 k 个块做数学重建，CPU 与网络压力大
CPU / 内存消耗	低	高（编码/解码计算）
适用数据	热数据、小文件、低延迟业务	冷数据、大文件、归档、备份

工程上的组合策略（加分点）：

热数据用多副本，冷数据用纠删码——成熟系统会按数据年龄自动转换（如"7 天内三副本保证低延迟，7 天后转 EC 降低成本"）；
MinIO 默认使用纠删码（按磁盘数自动计算 k/m），这是它"单机也能用、磁盘利用率高"的关键原因；
Ceph 同时支持副本池与 EC 池：对象存储场景常用 EC，但块存储（RBD）与文件存储（CephFS）的元数据部分通常仍需副本池，因为元数据要频繁更新、对延迟敏感；
EC 池一旦创建，k/m 参数不可更改。

⚠️ 修正一个常见说法：不少资料称"对象存储只能提供最终一致性"，这过于简化、且多数场景已经过时。主流云厂商的对象存储对单个对象的读写（PUT 后立即可读）等多数操作已提供强一致语义，具体要查厂商文档。回答时更稳妥的表述是："通过多副本 / 纠删码 + 跨可用区分布保证极高的持久性（如 11 个 9），一致性语义视厂商与具体操作而定"。

二、前端直传的三种授权方式

4. 什么是预签名 URL（Presigned URL）？如何使用？

答： 预签名 URL 是由服务端用密钥签名、临时授权某个操作的 URL。前端拿到后，无需持有任何密钥就能直接向对象存储发起请求。

原理：服务端用自己的 AccessKey，对「要执行的操作（如 PutObject）+ 目标对象 Key + 有效期」计算签名，拼成带签名参数的 URL 返回给前端。对象存储收到请求后用同样的算法验签，签名有效且未过期才允许操作。

五个关键点：

要点	说明
密钥不出后端	前端只拿到"一次性授权 URL"，永远接触不到 AccessKey——这是它最大的安全价值
Object Key 必须后端生成	不能让前端随意指定 Key，否则可能覆盖他人的文件（如构造 `../` 或他人目录）
`Content-Type` 要纳入签名	前端 PUT 时若 `Content-Type` 与签名时不一致，会返回 403（这是最常见的踩坑）
有效期要短	通常 5~15 分钟，够用即可
权限可精确限定	只签 `PutObject` 就只允许上传，不允许读、删、列目录

主要局限（面试常追问）：

一个 URL 只授权一次 PUT——若要上传多个文件、或走分片上传，就得为每个分片签一个 URL，请求会非常碎；
只能在签名层面限定"目标 Key + 操作"，无法限制文件大小与内容类型——攻击者可以拿一个合法的预签名 URL 上传一个 10GB 的文件（想解决这个要用 Post Policy）。

适用场景：零散的单文件上传（如上传一个头像），或给第三方一个临时下载私有文件的链接。

5. 什么是 STS 临时凭证？与预签名 URL 有什么区别？

答： STS（Security Token Service） 是云厂商提供的临时凭证服务，返回一套带过期时间的临时密钥：

AccessKeyId + AccessKeySecret + SecurityToken

前端拿到后用官方 SDK 直接操作对象存储（上传、自动分片、续期等），权限由后端下发的 Policy 精确限定。

典型 Policy（阿里云示例）：

{
  "Version": "1",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["oss:PutObject"],
    "Resource": ["acs:oss:*:*:my-bucket/uploads/12345/*"]
  }]
}

含义：只允许往 uploads/12345/ 前缀下写，不给读、不给删，有效期 1 小时。

与预签名 URL 的完整对比：

维度	预签名 URL	STS 临时凭证
授权粒度	单个对象 + 单次操作	一个范围（前缀/动作）+ 一段时间
多文件上传	每个文件签一次，非常碎	一套凭证可传多个文件
分片上传	每个分片都要签一次	SDK 内部自动分片，无需反复签名
前端复杂度	极低（一个 PUT 请求）	需引入 SDK，但功能完整
有效期续期	只能重新签发 URL	SDK 支持 `refreshSTSToken` 自动续期
权限灵活度	低（只能限定目标对象）	高（前缀、动作、时长均可限定）
主要风险	泄露只影响单个对象的一次操作	凭证明文下发到浏览器，Policy 必须收窄

选型建议：
零散的单文件上传 → 预签名 URL（最简单）；
多文件 / 大文件分片上传 → STS 临时凭证（主流方案）；
需要在凭证层面就卡住大小和类型 → Post Policy（见下题）。

6. 什么是 Post Policy？它能解决预签名 URL 的什么问题？

答： Post Policy 是一段 JSON 策略，声明本次上传允许的条件；后端签名后连同表单字段一起发给前端，前端用 HTML 表单 POST 方式上传，对象存储收到后按 Policy 校验，不满足直接拒收。

典型策略：

{
  "expiration": "2026-07-01T12:00:00Z",
  "conditions": [
    ["content-length-range", 0, 5242880],        // 限制大小 ≤ 5MB
    ["starts-with", "$key", "uploads/12345/"],   // 限制目录前缀
    ["starts-with", "$Content-Type", "image/"]   // 限制类型
  ]
}

它解决了预签名 URL 的一个硬伤：预签名 PUT 只能在签名时限定"目标 Key + 操作"，无法限制"文件大小"和"内容类型"——而 Post Policy 能在授权层面就卡住大小与类型。

三个必须知道的注意点：

注意点	说明
`file` 字段必须放在表单最后	这是对象存储的硬性约定，其他字段（`key`、`policy`、`signature` 等）必须写在它之前
只校验"声明"，不查真实内容	`Content-Type` 校验的是客户端声明的类型，用户可以把 `.exe` 声明成 `image/png`——真正的类型校验必须在服务端读文件头魔数
本质仍是表单上传	对超大文件不如"STS + SDK 分片"方便

三者一句话总结：预签名 URL = 单对象单次授权；STS = 范围授权 + SDK 全功能；Post Policy = 能在授权层卡大小与类型的表单上传。

7. 前端直传对象存储的完整方案如何设计？

答： 先说为什么要直传：传统链路是「浏览器 → 后端 → 对象存储」，后端要吃掉两份带宽（收一份、再转一份），大文件还会占内存、拖住线程。直传让文件直接进对象存储，后端只负责发凭证 + 收回调。

核心矛盾（先点出来）：直传把"控制点"从"文件流经服务端"挪走了，服务端再也没法在上传时顺手校验类型、大小、内容——所以必须用「凭证策略 + 上传回调」把控制点补回来。这是整道题的主线。

完整方案（推荐 STS + 回调）：

① 前端请求后端：「我要上传文件」（携带文件名、大小、类型）
② 后端做前置校验 + 生成凭证：
   · 校验用户身份，以及文件大小/类型是否符合业务规则
   · 生成【唯一 Object Key】（如 uploads/{userId}/{date}/{uuid}.{ext}）
     —— Key 由后端生成，绝不让前端指定
   · 调用 STS 签发临时凭证，Policy 限定：
       - Action：只给 oss:PutObject
       - Resource：只能写 uploads/{userId}/* 前缀
       - 有效期：如 1 小时
③ 前端用官方 SDK 拿凭证【直传】对象存储（大文件自动走分片上传）
④ 上传完成后，对象存储【回调后端】通知成功（携带 Key、大小、ETag 等）
   · 后端在回调中做【二次校验】：文件大小、真实类型（读文件头魔数）、内容安全审核
   · 校验通过才把文件记录写入业务库（如 t_file 表）
⑤ 前端拿到后端的"确认成功"响应后，才把文件展示给用户

四个关键设计点：

设计点	做法	原因
Key 由后端生成	用 `uuid` + 业务前缀，不要用原始文件名	防路径穿越（`../`）、防覆盖他人文件、防文件名冲突
凭证权限最小化	Policy 只给 `PutObject`，Resource 限定到用户自己的前缀	STS 凭证明文下发到浏览器，一旦泄露，损失被限制在该前缀内
上传回调做二次校验	对象存储回调后端，后端校验通过才落库	补回直传丢失的"控制点"；避免"文件已上传但业务没记录"的脏数据
失败与清理	定时清理"已上传但业务未确认"的孤儿文件	直传可能上传成功但业务侧失败

四条安全红线（面试时主动说）：

绝不能把长期 AccessKey 写进前端代码或接口返回给浏览器；
必须用 Policy 收窄 STS 权限（前缀 + 动作 + 时长）；
必须做服务端真实类型校验——只信文件头魔数，不信 Content-Type 声明；
建议对上传内容做安全审核（涉黄涉暴），并给 Bucket 配置 CORS 来源白名单。

三、大文件与去重

8. 什么是分片上传（Multipart Upload）？如何实现断点续传？

答： 分片上传是把大文件切成多个分片并发上传，最后合并成一个对象。

基本流程：

① 【初始化分片上传】→ 对象存储返回一个全局唯一的 uploadId
② 前端把文件切成 N 片（如每片 5MB），【并发】上传每个分片（带 partNumber）
   → 每个分片上传成功返回 ETag（该分片的校验值）
③ 全部分片完成后，调用【完成分片上传】接口，
   提交所有分片的 partNumber + ETag 列表
④ 对象存储按 partNumber 顺序合并，生成最终对象
⑤ 若中途放弃，调用【取消分片上传】清理已上传的分片

为什么能提升性能：并发上传充分利用带宽；失败只需重传单个分片，不用整体重来。

断点续传的实现：

步骤	做法
① 记录上传进度	前端把 `uploadId` + 已成功的分片号与 ETag 记录到 `localStorage`（或上报后端保存），刷新页面/断网后仍能恢复
② 恢复时列出已传分片	对象存储提供列出已上传分片的接口（`ListParts`）——这比本地记录更可靠，因为以服务端状态为准
③ 只补传缺失分片	对比"总分片数"与"已上传分片"，跳过已完成的，只传缺失的
④ 分片校验	前端对每个分片计算校验值，服务端校验；也可在合并后校验整个对象的 MD5
⑤ 过期清理	未完成的分片上传仍会占用存储，需配置生命周期规则自动清理（如 7 天未完成则删除）

三个易踩的坑：

分片大小有下限：除最后一片外，其他分片通常不得小于 5MB（OSS/S3 约定），否则合并会失败；
分片号必须连续有序：合并时按 partNumber 排序，顺序错会导致文件内容错乱；
ETag 必须全部提交：漏交或交错的 ETag 会导致合并失败。

实践建议：不要自己实现分片逻辑——官方 SDK（ali-oss、aws-sdk）已内置分片、并发与重试。业务只需在上层实现"秒传预检 + 进度保存 + 断点恢复"。

9. 如何实现文件秒传与去重？

答：秒传指"上传前先判断文件是否已存在，若存在直接返回已有地址，无需重复上传"。

核心原理：用文件内容的哈希值作为唯一标识。

① 前端计算文件的【内容哈希】——通常是 MD5 或 SHA-256
   · 大文件要【分片计算】：先算每个分片的 MD5，再对"分片 MD5 拼接串"算一次总 MD5
     （避免一次性把整个文件读进内存）
② 前端把【哈希 + 文件名 + 文件大小】发给后端【预检接口】
③ 后端查库（或查对象存储元数据）：
   · 已存在 → 直接返回已有文件 URL，【上传结束】（秒传成功）
   · 不存在 → 返回上传凭证，进入正常上传流程
④ 上传完成（或回调）时，后端把【内容哈希 → 文件地址】的映射写入业务表

去重的三种粒度与风险（面试重点）：

粒度	做法	风险
全局去重	所有用户共享一份物理文件，只加引用计数	⚠️ 跨用户泄露风险：A 上传的私密文件，B 用相同哈希就能"秒传"拿到——这是越权访问漏洞
用户内去重	哈希只在单个用户范围内唯一	安全，但不同用户间仍会重复存储
业务域去重	同一业务/租户内去重	折中方案，推荐

四个关键注意点：

必须做"哈希 + 文件大小"双重校验——哈希碰撞概率极低但非零，加大小校验更稳；
引用计数与延迟删除：多个业务记录引用同一物理文件时，删除要先减引用计数，归零才真正删文件，否则会误删他人正在使用的文件；
秒传不能替代权限校验：预检接口必须校验当前用户是否有权访问该文件，绝不能"只要哈希匹配就返回地址"——这是最严重的越权下载漏洞；
哈希计算要异步/分片：几十 GB 的文件在主线程算 MD5 会直接卡死页面。

四、安全与分发

10. 对象存储的安全控制手段有哪些？

答：按「访问控制 → 传输安全 → 防滥用 → 内容安全」四个层次：

层次	手段	说明
访问控制	ACL / Bucket Policy	私有（默认）、公共读、公共读写。生产上绝大多数 Bucket 应为私有，通过签名 URL 或 STS 临时授权访问
	RAM / IAM 子账号	给不同应用分配最小权限的子账号，不要用主账号 AccessKey
	STS 临时凭证	前端场景必须用临时凭证（见第 5 题）
	签名 URL	临时授权下载私有文件
传输安全	HTTPS	全链路加密，防止凭证与内容被窃听
	服务端加密（SSE）	OSS 托管密钥（SSE-OSS）/ KMS 密钥（SSE-KMS）/ 客户端加密（SSE-C）
防滥用	防盗链（Referer 白名单）	只允许指定域名引用资源，防止别的站点盗用你的流量。空白 Referer 建议放行，否则用户直接在地址栏输 URL 会 403
	短时效签名 URL	敏感文件不用公共读，改用短时效签名链接
	CORS 白名单	限制哪些来源可跨域直传（前端直传必须配置，且只允许自己的域名）
	流量控制 / 单链接限速	防止恶意刷流量导致高额账单
内容安全	服务端真实类型校验	读文件头"魔数"判断真实类型，不信 `Content-Type` 声明（防 `.exe` 伪装成图片）
	内容审核	接入图片/视频/文本审核，拦截违规内容
	上传回调二次校验	见第 7 题，补回直传丢失的控制点

三个最容易出事故的点（面试加分）：

Bucket 设为"公共读写"——等同于让全世界都能上传和删除你的文件，必须避免（这是对象存储最常见的安全事故）；
把长期 AccessKey 打进前端代码——一旦被扒出来，整个账号的资源都可能被删除或盗刷；
防盗链忘了放行空 Referer——导致用户直接在浏览器地址栏访问图片时 403。

11. 对象存储如何与 CDN 结合？回源策略有哪些？

答：对象存储常作为 CDN 的源站，形成「CDN 边缘节点 → 对象存储源站」的加速链路。

为什么要结合：

收益	说明
降低回源流量成本	对象存储的外网流出流量是主要成本项，CDN 命中后不回源，可大幅省钱
降低访问延迟	用户就近访问边缘节点，而不是每次都到源站 Region
抗突发流量	热点流量由边缘节点承接，源站压力小

回源策略（重点）：

策略	说明
回源 Host	CDN 回源时携带的 Host 头（通常设为 Bucket 的默认域名），必配
私有 Bucket 回源	Bucket 为私有时，CDN 需要回源鉴权（回源带签名，或使用厂商的"私有 Bucket 回源"能力 / 回源内网地址）
缓存规则（TTL）	按类型区分：静态资源（图片/CSS/JS）长缓存；HTML 短缓存或不缓存
缓存刷新（Purge）	文件更新后需主动刷新 CDN 缓存，否则用户仍看到旧文件
忽略参数缓存	选择"忽略 URL 参数"或"保留参数"，直接影响缓存命中率
回源重试 / 超时	源站抖动时的重试策略，提升可用性

两个常见坑：

文件更新后忘记刷新 CDN——用户看到旧文件。更可靠的做法是"文件名带版本号或内容哈希"（如 logo.a1b2c3.png），用"改 URL"代替"刷缓存"；
私有文件走 CDN 的鉴权——CDN 需要支持 URL 鉴权（如 auth_key、时间戳签名），否则私有文件无法通过 CDN 分发。

架构建议："对象存储 + CDN + 短时效签名 URL" 是图片/视频/静态资源分发的标准组合——上传走直传（STS），下载走 CDN，源站只作为持久化存储。

12. 如何在 FastDFS、MinIO 与云 OSS 之间选型？

答：

维度	FastDFS	MinIO	云 OSS / S3
定位	轻量分布式文件系统	私有化对象存储	公有云对象存储
协议 / 接口	私有 Client API（无 HTTP、无 POSIX）	原生 S3 兼容 API + HTTP	S3/OSS RESTful API
数据冗余	组内多副本（同组文件完全相同）	纠删码（磁盘利用率高）	多副本 + 纠删码（跨可用区）
扩展性	加 group 扩容，但无法自动均衡存量	分布式部署可水平扩展	弹性无限
运维成本	中（需配 Nginx + 模块）	低 ~ 中（单机极简，分布式需手动配置）	零运维
成本模型	自购硬件	开源免费（企业版付费）	按量付费（流量费是主要成本项）
生态 / 社区	弱（无官网，版本久未更新）	活跃、K8s 原生友好	完善（SDK、工具、文档齐全）
典型场景	存量项目、内网图片/小文件	私有云、云原生、新项目自建首选	无自建意愿、需弹性与容灾

选型决策（三步）：

能上公有云且无合规限制 → 云 OSS / S3（免运维、弹性、生态好），这也是绝大多数业务的最优解；
必须私有化部署 → MinIO：原生 S3 API、纠删码省磁盘、K8s 友好、社区活跃；
已有 FastDFS 存量系统 → 继续维护，但新业务不要再上 FastDFS。

迁移 FastDFS 到对象存储的思路（面试加分）：

① 双写：新上传的文件同时写 FastDFS 与对象存储（或直接切换到对象存储）
② 存量迁移：写工具遍历 FastDFS，把老文件搬到对象存储；
   同时在业务库里记录"文件 ID → 新 URL"的映射，或做兼容层（读旧 ID 时自动重定向）
③ 灰度切换读流量：先切小部分业务读新地址，观察稳定后全量
④ 下线 FastDFS

回到"选型"的本质：不要问"哪个更先进"，要问"我的约束是什么"——是否必须私有化、是否有合规要求、数据量级与增长预期、团队运维能力、成本预算。把这几个约束讲清楚，选型结论自然就出来了。