前面几楼把权限、区域、存储类别、分段上传、Endpoint、AK/SK、版本控制、生命周期、CORS、防盗链、费用讲得很全了，我补充几个同样容易踩、但上面还没提到的点。 一、对象没有真正的“改名”和“移动”。OBS 里改名、换目录本质上是复制一个新对象再删除旧对象，大对象这样操作会多一次复制请求和一段时间的双份存储，批量改名前先算好量；目录也只是对象键里的斜杠，删“空文件夹”并不能删掉对象。 二、临时签名 URL 和 STS 临时凭证会过期。发给别人的带签名下载链接一般只有几分钟到几小时有效，过期后报 403 或签名不匹配，不是权限被改了；长期对外分享要用桶策略放开匿名读，或者由服务端每次现签。前端上传也别用长期 AK/SK，过期和泄露都麻烦。 三、走了 CDN 后改了对象还看到旧内容，多半是 CDN 节点缓存了旧版本。OBS 里的对象已经换了，CDN 要等缓存过期或手动刷新才生效；上线前先想好缓存规则，静态资源文件名带版本号（比如 app.v2.js）比反复清缓存稳妥。 四、权限排障先分清“谁在访问”。同样一个 403，匿名访问、IAM 用户、委托的函数、CDN 回源的身份都不一样：先看桶策略允许的主体，再看 IAM 权限，最后看对象 ACL，逐层缩小；开桶访问日志能直接看到是谁、用什么身份、被哪条规则拒绝。 五、热点对象键会限流。短时间内对同一个对象或同一前缀高频读写，容易触发限流；需要高并发时把对象键前缀打散，比如在前面加日期、哈希前缀，避免所有请求挤在同一个前缀上。 总结：建桶前定好区域和命名规范，上线前配齐生命周期、最小权限桶策略、CORS 和防盗链，再把签名有效期、CDN 缓存、访问日志这三项检查一遍，能避开新手期的大部分坑。

补充一个更省时间的思路：先把密钥和密码两条路分开测，再决定进哪一边查，不用把六个点全查一遍。1. 先分开测两种认证。本地分别跑：ssh -o PreferredAuthentications=publickey -i 私钥 用户名@IPssh -o PreferredAuthentications=password -o PubkeyAuthentication=no 用户名@IP密钥能通、密码不通，就是密码侧的问题；反过来就是密钥侧的问题；两条都不通，再按下面查账号和服务端。2. 先看报错后缀。秒回 Permission denied (publickey,password)，说明 22 端口通、sshd 已应答，问题不在安全组放行上；如果是超时或 Connection refused，才去查安全组、EIP 绑定和实例状态。密钥和密码同时被拒，根因通常在用户名、凭证、sshd 开关这三处。3. 核对用户名和密钥落点。不同公共镜像默认用户不同，Ubuntu 一般是 ubuntu，CentOS 一般是 root；公钥只会写进创建实例时指定的那个用户的 ~/.ssh/authorized_keys，换用户登录要去对应用户的家目录看。用 ssh-keygen -lf 本地私钥 和 VNC 里 ssh-keygen -lf ~/.ssh/authorized_keys 比对指纹，指纹对不上就是绑错了密钥对或重装后密钥变了，控制台换绑后要按提示重启或重置才生效。4. VNC 进去看日志和权限。控制台远程登录不走 sshd，进去后看日志：CentOS 看 /var/log/secure，Ubuntu 看 /var/log/auth.log，或 journalctl -u sshd。日志会直接写明原因。再一次性修权限链：chmod 700 ~/.ssh，chmod 600 ~/.ssh/authorized_keys，chmod go-w ~，属主改回登录用户。如果上面都对仍进不去，用控制台“重置密码”或“更换密钥对”恢复最快，恢复后记得关闭密码登录、收紧安全组 22 端口来源。

补充一个按“先验证、再上生产”落地的角度。前面几楼讲的权限、区域、存储类型都很关键，实际操作时再注意这几点： 一、权限先在测试桶上最小化验证。桶保持私有，给应用只开最小权限，读和写分开授权；需要对外分享单个文件时，用带过期时间的临时签名URL，不要为图方便把整个桶改成公共读，也不要把AK/SK写进前端代码或公开仓库。 二、对象键先定规范。OBS里没有真正的文件夹，斜杠只是对象键前缀；键名含中文、空格或特殊字符时要按规范编码，否则控制台能打开、SDK拼出的链接却打不开；同名上传会直接覆盖旧对象，重要数据先开版本控制。 三、大文件用分段上传，并配好生命周期。分段上传中途失败或取消后，未完成的分段不会自动消失，会一直占空间；给桶配一条定期清理未完成分段和过期对象的规则，并定期检查账单里的请求次数和流量。 四、报错先分层定位。报403先查AK/SK是否过期、IAM策略是否同时覆盖桶和对象；报404先核对区域、桶名和对象键；浏览器报跨域，先查桶的CORS配置。 建议先用测试桶把建桶、上传、授权、生命周期、删除完整走一遍，确认无误后再用到生产桶。

前面几位把权限、存储类型、上传、版本控制讲得很全了，我补充几个同样容易踩、但还没细说的坑：一、别把 OBS 当文件系统用。OBS 里没有真正的目录，所谓“文件夹”只是对象名的前缀；对象不支持追加写和随机写，改名、移动其实是先复制再删除原对象，大对象改名又慢又多花一次请求和流量费。数据库文件、频繁修改的热数据不适合直接放 OBS，适合放冷数据、备份、图片音视频这类一次写入、多次读取的场景。二、访问域名选错，流量费和延迟都吃亏。同区域 ECS 访问走内网域名，不收下行流量费、延迟也低；用公网域名下载要收流量费。对外分发大文件建议接 CDN，用桶做回源，别让用户直接打到桶上。绑定自定义域名要先完成备案，HTTPS 访问还要配好证书。三、公开桶要防盗链。公开读的桶一旦被别人拿到直链做外链，流量费就悄悄跑到自己账上。可以在桶策略里配 Referer 防盗链，只放行自己的域名；更稳妥的是保持私有，用带有效期的签名 URL 分发。四、跨区域迁移要提前规划。桶建好后区域改不了，不同区域的桶之间不能直接复制对象，要用 obsutil 或 OMS 迁移，跨区域会产生流量费；需要多区域容灾的话，建桶时就把跨区域复制规则规划好。先在测试桶上把这几项跑通，再往生产放数据，能少踩一半坑。

补充一个更短的实操版本：先找瓶颈，再定规格族，最后用监控调档。 1、先找瓶颈：CPU长期跑满就加核，内存先满就换内存型，磁盘I/O排队就升级云硬盘。加核解决不了内存或磁盘瓶颈，钱花了性能却没涨。 2、再定规格族：Web和通用业务用通用型，CPU与内存比约1:2；数据库、缓存用内存型，约1:4或1:8；计算密集用计算型。先定族、再定核数，选错族再加核，等于花高价补短板。 3、最后小步试错：先用小规格上线，跑一周云监控（CES）看CPU、内存、磁盘I/O的峰值和均值曲线，峰值长期高于70%就升规格，长期低于20%就降规格。ECS支持变更规格，选小了可以升、选大了可以降，不用一次买到位。 4、计费搭配：长期稳定跑的用包年包月，波动部分用按需加弹性伸缩，开发测试环境用完关机。 一句话：瓶颈定族、监控定档、计费兜底，先小后大，基本不会花冤枉钱。

3楼、4楼、7楼已经把权限、存储类别、生命周期、分段上传这些大坑讲得很全了，我补充几个同样常见、但新手往往是出问题后才发现的点：一、AK/SK 绝不要写进前端代码或提交到代码仓库浏览器直传要走后端签发的临时凭证（临时 AK/SK + SecurityToken，或表单签名），有效期设短一点。把长期 AK/SK 硬编码在 JS 里，等于把桶的钥匙公开了，泄露后别人能用你的账单刷流量。AK/SK 也不要出现在日志和报错堆栈里。二、上传时没设 Content-Type，文件就只能下载、不能在线看用 SDK 上传图片、PDF 时如果不指定 Content-Type，对象会按 application/octet-stream 存储，浏览器打开对象地址会直接下载而不是预览。上传时按文件类型设置好 Content-Type，图片、视频、PDF 才能直接在线打开。三、短时间大量请求可能触发限流批量上传或压测时，如果键名都以同一前缀开头（比如同一日期目录下几万个文件），请求容易集中触发 503 SlowDown。缓解办法是把键名打散（比如在前缀里加随机散列或按业务分桶），并给上传加退避重试。四、删了对象，CDN 上可能还看得到对象配了 CDN 加速后，删除或更新对象不会自动清 CDN 缓存，旧内容还会在边缘节点保留一段时间。更新静态资源时要主动刷新 CDN 缓存，或给文件名加版本号。五、桶策略里的 Principal 别随手写“*”桶策略里 Principal 写“*”且 Effect 为 Allow，等于对所有人放行，配之前先确认授权范围；需要临时分享单个文件时，用带过期时间的签名 URL，而不是把整个桶改成公共读。一句话总结：桶保持私有、凭证走后端签发、上传时定好 Content-Type，先在测试桶把上传、下载、授权、生命周期、删除完整跑一遍，再往生产桶放真实数据。

补充一个你已经排除了已删文件之后的角度：楼上几位把经典原因讲得很全了，但有两个细节值得纠正和补充。 先纠正一个常见误解：inode 耗尽和 ext4 预留块解释不了“df 已用远大于 du 合计”。inode 耗尽时 df -h 并不满，只是建不了新文件；预留块只有 5%，解释不了几十 GB 的缺口。真正对得上的还是“du 遍历不到的地方”。 1. du 本身可能漏统计。du 要用 root 跑：sudo du -x -B1 --max-depth=1 /目标挂载点。-x 限定在同一文件系统；不要把 2>/dev/null 丢掉，权限不足被跳过的目录会悄悄漏掉；不要用 /data/*，它会跳过隐藏目录。 2. 容器 / 命名空间的盲区。如果这台机器跑 Docker，宿主机上的 lsof 看不到容器命名空间里持有已删文件的进程。用 sudo find /proc/[0-9]*/fd -lname '* (deleted)' 直接扫 /proc，或进容器里再查一次 lsof。容器日志也是重灾区：sudo du -sh /var/lib/docker/containers/* 查 -json.log，确认后用 truncate -s 0 截断，不用重启容器。 3. 稀疏文件和块占用别混着比。ls -lh 显示逻辑大小，du 显示实际占用块；反过来，一个逻辑上很大的稀疏文件 du 并不大。如果怀疑是它，用 du --apparent-size 对比。 建议先贴出 df -B1、df -i 和 sudo du -x -B1 --max-depth=1 的三组数字，再按“容器/命名空间 → 挂载遮挡 → 已删文件”这个顺序查，缺口基本能对上。清理前先确认文件归属和业务用途，别直接删。

补充一个可直接照着算的选型方法：把规格选择变成一张算账表，而不是凭感觉买。先定三个数：日常并发、峰值并发、单请求资源消耗。用云监控取一周数据，重点看P95而不是瞬时峰值：比如日常CPU 30%、峰值65%，那按峰值再留20%余量反推，2C4G大概率够用；如果峰值CPU长期超过80%，再考虑升配或加机器。再按场景对号入座：Web应用和轻量后端用通用型，2C4G或4C8G起步；转码、渲染、建模等CPU密集型用计算型；Redis、MySQL这类内存密集型用内存优化型，内存配比至少1:4；磁盘I/O敏感的数据库再配高性能云硬盘。族选错了，单纯加核数是花冤枉钱。计费分三层：基线负载包年包月；波动负载按量计费加弹性伸缩，峰值自动扩、闲时自动缩；定时批处理、离线任务用竞价实例。三层叠加后，同样的业务量，账单通常明显低于全量按峰值常备的方案——前提是弹性伸缩的触发阈值要设对，建议按CPU 70%扩容、30%缩容，并留一台冗余应对突发。最后每月复核一次：CPU长期低于20%就降配，高于70%就升配；顺带清理未挂载磁盘、闲置弹性IP和过期快照。选型没有一劳永逸，定期复核才是省钱的关键。

新手用 OBS，建议按“建桶前、上传前、上线前”三步走一遍，能避开大部分坑。建桶前先定三件事。一是区域：桶建在哪个区域，SDK、控制台、回源就用对应区域的域名，跨区域访问慢，还可能报找不到桶；二是桶名：全球唯一，建好后不能改名，命名先定好规范，比如业务名加环境加用途；三是权限：默认私有，别图省事改成公共读。公开内容用桶策略只放行需要的对象前缀，需要临时分享时用带签名的临时 URL，设好过期时间。上传前注意对象特性。OBS 没有真正的目录，所谓文件夹只是以斜杠结尾的对象名，改名、移动大对象等于重新上传，规划路径时一次想好。小于 5GB 用普通上传，大文件、弱网用分段上传，断点续传要保存好 UploadId；浏览器直传必须配 CORS，不然前端会报跨域。写代码时 AK/SK 别写死在前端，浏览器直传用服务端签发的 POST 策略更稳妥。上线前把计费和清理配好。存储、请求次数、流量都会产生费用，测试桶用完记得开生命周期规则，定期转低频、归档或过期删除；开了版本控制要留意，删除只会加删除标记，旧版本仍在计费，清理时要连版本一起删。建议先在测试桶走通上传、下载、删除、权限验证这一整套，再上生产；遇到上传报 403，先查 IAM 权限、桶策略和临时凭证是否过期这三处。

前面几楼把场景分类说得很全了，我补充一个可以直接照着做的判断和验证方法。一、先问自己三个问题，三个都是“是”，再优先选函数：1. 触发方式是事件吗？比如文件上传、定时、消息、HTTP 回调，而不是一直有人在等响应。2. 单次执行能在几秒到一两分钟内结束吗？超过函数时长上限的任务要先拆分，不要硬塞进一个函数。3. 流量是稀疏或波峰波谷明显吗？7×24 稳定高并发时，先算一笔账再决定。二、上生产前做一次最小验证，半天就能跑完：先用一个真实触发器接一个真实下游跑通，例如 OBS 上传一张图触发压缩函数并写回另一个桶，观察三件事：冷启动耗时是否在业务可接受范围、并发上来后下游数据库或第三方接口是否扛得住、失败重试时会不会重复写数据。写操作要用业务唯一键做幂等，不要假设函数“只会执行一次”。同时确认三项配置：函数超时时间、内存规格、并发上限，并把日志接到云日志服务，方便按请求 ID 排查。三、一个容易被忽略的点：函数本身不保存状态，临时文件、计数器、会话都不要放在函数实例里，统一落到 OBS、RDS 或 Redis，否则实例回收后数据就丢了。结论：事件触发、单次短、无状态、流量不均匀，是函数最划算的四类场景；反之优先考虑 ECS 或 CCE，函数只做周边的定时、回调和自动化胶水。