4楼和8楼已经把权限、存储类别、分段上传、版本控制这些大头讲得很全了，我再补充几个楼上没细说、但新手同样容易踩的点：一、AK/SK 千万别写进前端代码或公开仓库。浏览器里直接调 OBS 的代码一旦带上长期 AK/SK，任何人打开开发者工具都能看到，等于把桶的钥匙公开了。正确做法是：前端只拿服务端下发的临时安全凭证或预签名 URL 做上传下载；长期 AK/SK 只放服务端。万一泄露，立刻在控制台停用并轮换，同时检查桶的访问日志有没有异常下载。二、服务端加密要主动开。OBS 支持 SSE-KMS、SSE-OBS 服务端加密，但默认不开启。放身份证照片、合同、备份数据这类敏感内容时，建议在桶设置里打开默认加密，或在上传时指定加密方式；只靠“桶是私有的”挡不住合规要求。三、别按项目建一堆桶。一个账号下桶的数量有上限（默认 100 个），桶名全局唯一、建好不能改名、区域也不能改。项目、环境的区分优先用对象名前缀（如 prod/images/、test/logs/）而不是新建桶；确实需要隔离再用多桶，并用桶策略做最小授权。四、ECS 访问 OBS 尽量走内网域名。同一区域的 ECS 访问 OBS 时，用内网访问域名不走公网，既省公网流出费用又更稳定；跨区域访问会有额外延迟和流量费。SDK 里配 endpoint 时，务必用桶所在区域的域名，配错区域会报 301 重定向甚至直接报错。五、对象不能“改一点”，也不能当磁盘挂着用。OBS 是对象存储，没有随机写和追加写；改一个字节也要整个对象重写。日志追加、数据库文件这类场景不要直接放 OBS；批量传小文件时，优先用 obsutil 的断点续传和批量同步，比自己写循环调 API 稳得多。六、提前开桶的访问日志。403、404 这类错误 OBS 默认不主动推送原因；提前把访问日志投递到另一个桶，出问题时按请求 ID 和时间段检索，比凭记忆猜配置快得多。

前面几位已经把经典原因讲得很全了，补充三个楼上没展开、但在 ECS 上很容易踩到的盲区，楼主说 lsof 没找到明显目标时值得优先查：一、进程如果跑在容器里，宿主机上的 lsof 是看不到的容器有自己独立的 mount namespace，容器里被 rm 掉、进程还拿着的文件，在宿主机上执行 lsof +L1 是看不到的。两种查法：进容器里查，docker exec -it 容器名> sh，然后在容器内执行 lsof +L1（容器里没有 lsof 时，用 ls -l /proc/*/fd | grep deleted 代替）；或者直接看容器的可写层，du -sh /var/lib/docker/overlay2/*/diff 2>/dev/null | sort -rh | head。容器日志本身也要看一眼：ls -lhS /var/lib/docker/containers/*/*-json.log。二、用交互式工具代替一层层 dudu --max-depth 逐层钻很慢，还容易漏掉隐藏目录。建议装 ncdu：sudo apt install ncdu（CentOS 用 yum install ncdu，需 EPEL 源），然后 sudo ncdu -x /，按 n 按大小排序，每级目录的占用一目了然，隐藏目录、挂载点都不会漏。没有 ncdu 时也可以直接找大文件：find / -xdev -type f -size +500M -exec ls -lh {} \;三、还有两个灯下黑的位置一是回收站：图形界面删掉的文件进了 ~/.local/share/Trash，空间并不会释放；二是确认满的到底是哪个挂载点，如果是 tmpfs（比如 /dev/shm），它占的是内存不是磁盘，du / 是看不到的，先用 df -hT 确认文件系统类型再查。建议的排查顺序：df -hT 确认挂载点 → ncdu -x 看目录分布 → 容器内 lsof +L1 或扫 /proc/*/fd → journal 与回收站。把这几项的数字和 df 的 Used 加总，基本就能对上，剩下的差额再考虑挂载遮挡与 ext4 预留块。

先说关键：df 和 du 口径不同，差值一定藏在 du 看不到的地方。楼主说 lsof 没查到明显占用，最可能的原因是排查命令本身漏了范围，建议按下面顺序再查一遍，不要直接删文件。1、先把 du 和 lsof 都用 root 跑一遍普通用户跑 lsof 只能看到自己的进程，系统服务、root 进程持有的已删除文件是看不到的；du 同理，权限不足的目录会被静默跳过。建议：sudo lsof +L1，按 SIZE 从大到小看前几行；再用 sudo du -x --max-depth=1 满的挂载点，-x 限定在同一文件系统，错误输出不要丢掉（2>/dev/null 会把“权限不足”也藏起来）。2、查挂载点“盖住”的旧数据先往 /data 写了几十 GB，后来又把一块盘挂到 /data 上，旧文件仍占父文件系统的空间，但 du 走的是挂载后的目录树，看不见。验证：findmnt -R / 看完整挂载树；或 sudo mount --bind / /mnt/rootview，再 du -sh /mnt/rootview/data 对比。3、查容易灯下黑的两处一是 systemd journal：journalctl --disk-usage 看一眼，/var/log/journal 经常攒到几 GB，应急可用 journalctl --vacuum-size=200M 清理。二是容器日志：如果跑了 Docker，sudo du -sh /var/lib/docker/containers/* 看单个容器的 -json.log，没做轮转时一个文件就能涨到几十 GB。4、区分 inode 耗尽执行 df -i：如果是 inode 用满，海量小文件会让 df 显示满，但 du 找不到大文件，这时要按目录统计文件数而不是文件大小。处理原则：定位到具体文件/进程再动手；已删除仍被占用的文件，优先用 : > /proc/PID/fd/FD 截断或重启对应服务释放，不要直接 kill 不明进程；清理前先确认文件是否还有业务用处。

补充两个前面回答里没展开的点：怎么核对还在扣费的是哪项资源，以及“关机不收费”之后再开机的一个坑。1. 先分清三笔钱实例规格（vCPU/内存）、云硬盘（系统盘/数据盘）、弹性公网 IP（EIP）是分开计费的。普通关机不停费；关机时选“关机不收费”（部分规格和区域支持，控制台关机弹窗里有这个选项）才能停掉实例规格的费用，但磁盘和 EIP 只要还在就继续计费。2. 想彻底停费，收尾顺序是先备份（整机镜像或云硬盘快照）→ 删除实例（系统盘一般随实例删除，数据盘默认保留，要手动确认）→ 解绑并释放不再用的 EIP → 再到费用中心核对账单。3. 怎么确认哪项还在扣费费用中心 → 账单 → 按产品/按资源查看，实例、云硬盘、EIP 会分行出账，看到底是哪一项还在产生费用，比猜要准。数据盘随实例删除的勾选状态、快照和备份的费用也要顺手看一眼。4. 用“关机不收费”省钱时注意一个坑关机期间实例仍然占用配额，且再次开机时如果该规格在该可用区库存不足，开机可能失败；另外非固定公网 IP 的场景下，关机再开机后 IP 可能变化，依赖 IP 访问的业务要先确认。一句话：关机是暂停使用，释放才是停止计费；短期停用就用“关机不收费”，彻底不用就备份后删除实例并释放 EIP 和多余磁盘，最后去费用中心核对账单。

先说结论：df 和 du 的统计口径本来就不一样。df 读文件系统的超级块统计（已分配块），du 是遍历目录树逐个累加。两者对不上，说明空间藏在 du 遍历不到的地方。你已经用 lsof 排除了最常见的“已删除但句柄未释放”，建议按下面顺序再查一遍，重点在第 1 和第 3 项。1. 先确认 du 没有漏统计用 root 跑、限定在同一文件系统、不要丢掉报错信息：sudo du -x -h --max-depth=1 /挂载点 2>/tmp/du.err再用 find /挂载点 -xdev -type f -size +1G 找大文件。注意两点：不要用 /目录/* 这种写法，它会漏掉隐藏目录；权限不足被跳过的目录会让 du 的总数偏小，先看 /tmp/du.err 里有没有 Permission denied。2. 检查挂载点遮挡先往目录写了数据、后来又把盘挂到同一目录上，旧数据会被盖住。排查：findmnt -R /挂载点或者 mount --bind / /mnt/rootview，然后 du -sh /mnt/rootview/原目录 对比。3. 已删除文件换个姿势再查一次lsof 输出多时很容易看走眼，只列链接数为 0 的：sudo lsof +L1或者直接扫 /proc：sudo find /proc/[0-9]*/fd -lname '* (deleted)'还有一个容易漏的点：如果机器跑了容器，宿主机上的 lsof 可能看不到容器命名空间里的已删文件，要进容器里查，或者用 nsenter 进对应命名空间查。确认后用 : > /proc//fd/ 截断即可释放，不用重启服务。4. 查容易被忽略的大户systemd journal：journalctl --disk-usage，紧急释放用 journalctl --vacuum-size=200M。Docker 容器日志：du -sh /var/lib/docker/containers/*，单个 -json.log 没有轮转时能涨到几十 GB。另外看一眼 /tmp、/var/tmp、/var/crash 和 coredump。5. 最后顺手排除两项df -i 看 inode 是否耗尽；tune2fs -l 看 ext4 预留块。这两项解释的是“还有容量却不能写”和 root 可用空间差异，一般不是 du 对不上的主因。按 1 到 4 的顺序查，绝大多数情况都能定位。定位到之后再清理，清理前先确认文件归属和业务用途，不要直接删生产日志。

FunctionGraph 是事件驱动、无服务器的函数计算服务，核心判断标准就三条：任务是不是事件触发、单次执行是不是短时无状态、流量波动是不是大。符合这三条的场景用它最划算，反过来则不建议硬上。 一、特别适合的四类场景 1. 事件驱动的轻量处理：OBS 对象上传后自动生成缩略图、转码、打水印；消息队列收到消息后做数据清洗、格式转换、写库；定时触发的巡检、报表生成、清理过期文件。这类任务平时没有流量，来了就跑，跑完就停，用函数按次计费比常驻一台 ECS 便宜得多。2. Web API 的轻量后端：配合 APIG 做鉴权、路由后，函数直接处理请求，适合小程序后端、活动页接口、Webhook 回调、第三方服务对接。流量低谷时缩容到零，不用为闲置资源付费；流量突发时自动扩容，不用提前压测扩容。3. 自动化运维与胶水代码：定时检查 ECS 状态并告警、自动打快照、批量处理工单、把多个云服务的操作串成一个工作流。代码量小、改动频繁，用函数发布比部署一个完整服务快很多。4. 数据流转与集成：把来自不同系统的数据做校验、脱敏、聚合再写入数据库或数据仓库；做 API 聚合层，把多个后端接口拼成一个前端需要的接口。 二、不太适合的场景 1. 长时间运行的任务：单次执行时间有限制，视频大文件长时间转码、超大批量离线计算、大模型训练这类长任务不适合，应拆成多个小任务或用 ECS、容器、批量计算服务。2. 需要常驻状态的服务：函数实例是临时的，内存、本地磁盘里的状态随时会被回收。需要长连接、常驻内存缓存、本地文件长期保存的场景，不要直接放在函数里，状态要放到数据库、缓存或对象存储里。3. 对冷启动非常敏感的低延迟接口：如果函数长时间没被调用，下一次调用需要重新初始化运行环境，会多出几百毫秒到几秒延迟。对延迟要求在几十毫秒内的核心交易接口，建议用常驻服务，或者给函数配置预留实例。4. 强依赖特定运行环境的复杂应用：需要自定义内核模块、特殊系统库、常驻后台进程的传统单体应用，改造成本很高，不如直接用 ECS 或容器。 三、上手前先确认的三件事 1. 触发器选对：HTTP 触发适合对外接口，OBS 触发适合文件处理，定时触发适合巡检和报表，消息触发适合异步解耦。2. 权限给最小：函数访问其他云服务要配委托和最小权限，不要图省事给过大权限。3. 超时和内存先压测：按真实数据的最大耗时设置超时和内存，留出余量，避免大请求一来就超时或内存溢出。 总结：事件触发、短时无状态、流量波动大，就优先考虑 FunctionGraph；长任务、有状态、极低延迟，就选 ECS 或容器。先从一个定时巡检或文件处理的小任务试起，跑通触发、日志和告警后再扩大范围。

平衡成本与性能，关键是先按负载选型、再按实测调规格，而不是一开始就买大规格。 第一步，先定负载画像。看业 CPU 密集还是内存密集：Web 应用、API 服务通常先看 CPU 与并发，缓存、数据库类应用先看内存；再看峰值并发、单请求耗时和磁盘 I/O 特征。通用型适合大多数 Web 与轻量应用，计算型适合高并发计算，内存型适合数据库与缓存，选错类型比选小一档规格更浪费。 第二步，从够用偏小的规格起步，用按量付费验证。先选一个能覆盖日常负载、峰 20% 到 30% 余量的规格，上线后观察 CPU 利用率、内存占用、磁盘 I/O 与响应时间；长期 CPU 超过 70% 或内存经常接近上限，再升一档；长期低于 20% 则降一档。实测一两周的数据，比凭经验估算可靠得多。 第三步，用弹性能力代替常驻大规格。业务有明显波峰波谷时，不要为峰值长期买大规格，可以用弹性伸缩加负载均衡扩容应对峰值，低谷自动缩容；基线负载稳定后，再把按量计费转为包年包月，成本通常会明显下降。 最后别忽略配套资源：系统盘按实际数据量选类型与大小，带宽按峰值流量选，避免为了保险把磁盘与带宽都配到顶。定期复盘一次监控与账单，规格跟着业务走，才是成本与性能的平衡点

3楼把负载画像、稳态和突发、从小起步这三点讲得很全了，我补充一个这个帖子里还没展开、但实际选型时最容易被忽略的角度：CPU 和内存只占账单的一部分，磁盘、带宽和弹性 IP 这些配套很容易悄悄拉高成本，选型时要一起算账。 第一，磁盘类型要按 IOPS 需求选，别默认最高档。系统盘只装系统和应用，普通云硬盘就够；数据库、消息队列这种对磁盘延迟敏感的才需要高性能盘。很多人一上来就给所有盘选最高性能类型，每月多花不少钱，实际用不上。 第二，带宽计费方式要匹配流量特征。对外流量波动大、峰值和谷值差很多的业务，用按流量计费比按固定带宽划算；流量稳定且持续的，用固定带宽更便宜。还要记住：带宽费用是出方向流量，入方向一般不计费，静态资源走对象存储加内容分发分流，往往比直接扩带宽便宜。 第三，别只看单台规格，算总账。同样预算下，两台中等规格加负载均衡，往往比一台大规格更划算：单台故障不影响业务、升级可以滚动进行、峰值时还能再加机器。单台大规格适合数据库这类不好水平扩展的场景，应用层优先选可水平扩展的方案。 第四，留一个明确的升降配触发条件。建议把指标写下来：CPU 持续一周超过 70% 就升配，长期低于 20% 就降配；内存同理。按月复核一次规格和账单，把闲置的弹性 IP、没挂载的磁盘、过期的快照一起清理掉。 一句话：选型时把 CPU、内存、磁盘、带宽、计费方式放在一张表里按真实用量算，配套费用和单台规格一样重要，先小规格加监控验证，再按指标升降配，成本和性能才能同时顾住。

先给一个可以直接落地的思路：先定业务画像，再选系列，最后用监控和压测验证，小步升级。1. 先看瓶颈在哪类资源上。Web、API、游戏服通常先吃 CPU；缓存、数据库、Java 应用通常先吃内存；视频转码、AI 推理要看 GPU 和带宽。不知道瓶颈时，先上云监控看一周的 CPU、内存、磁盘 I/O 峰值曲线，再决定补哪一项。2. 按场景给个起点（可上下调整）：个人博客、测试环境，1核2G够用；日活几千的小型 Web 应用加同机数据库，2核4G是常见起点；并发上来或跑 Java、数据库，优先加内存到 4核8G；数据库建议单独部署，别和应用抢内存，生产环境优先用云数据库而不是自建。3. 选系列比只看核数重要。同样的 4核8G，通用型、计算型、内存型的单核性能和价格差别明显：计算密集选计算型，内存密集选内存型，一般业务选通用型。突发、定时任务这类不持续跑满的场景，可以用突发性能型或按需计费，别长期包年包月买大规格闲置。4. 先小后大，留出弹性。云服务器支持变配，宁可先买小规格压测验证，确认瓶颈后再升级；系统盘选高 I/O，数据库配独立数据盘；带宽按峰值估，波动大的业务用按流量计费。长期稳定跑满的业务再考虑包年包月降成本。

2 楼和 3 楼把权限、区域、计费这些大坑讲得很全了，我补充三个新手上线前最容易漏掉、但事后处理成本很高的点。一、没传完的分段上传会一直占着存储计费大文件用分段上传时，如果中途失败、取消或程序异常退出，没传完的分段不会自动消失，仍按存储计费，时间久了会积出不少费用。建议在桶上配一条生命周期规则，定期清理未完成的分段上传；同时在代码里给分段上传加超时和重试，失败的分段只重传那一段，不要整个文件重传。二、对象名和元数据要在上传时一次写对对象名里有中文、空格或特殊字符时，下载链接要按 URL 编码处理，否则会出现签名校验失败或 404；上传时还要顺手写对 Content-Type，比如图片写 image/jpeg、网页写 text/html，否则浏览器可能直接下载而不是打开。对象一旦上传，元数据改起来比较麻烦，最好在上传接口里统一处理。三、凭证不要长期嵌在前端或代码里前端直传、移动端上传不要把长期 AK/SK 写进代码或配置文件，一旦泄露整个账号的桶都有风险。正确做法是后端签发带过期时间的临时凭证或预签名 URL，前端只拿临时凭证上传；长期任务用 IAM 委托，只给对应桶的读写权限。密钥要定期轮换，废弃的 AK 及时在控制台删除。建议新手建桶后按这个顺序自测一遍：上传、预签名下载、跨区域访问、中断一次大文件上传再检查未完成分段、删对象并确认计费变化，确认无误再放生产数据。