先说结论：df 和 du 本来就不是同一个口径，差值本身不是 bug，关键是把差值算出来、拆到具体哪一类上。你已经查过 lsof 没发现已删除文件，那就不要在这一条上反复查，先按下面这套“对账”顺序走一遍，多数情况能直接看到数字对上。一、先把 df 和 du 对到同一个单位和同一个文件系统df -h 和 du -sh 用的单位和四舍五入不一样，差几 GB 很正常。用字节、限定同一个文件系统再比一次，假设满的是根分区：sudo df -B1 /sudo du -x -B1 -d 1 / 2>/tmp/du.err | sort -rn | head -20注意两点：第一，一定要用 sudo，普通用户跑 du 时权限不足的目录会被悄悄跳过，错误又常被 2>/dev/null 丢掉，少统计几十 GB 都可能；第二，du 加 -x，不要跨到别的挂载点去。跑完先看 /tmp/du.err 里有没有大段权限报错，再把 du 各目录之和跟 df 的 Used 对一下，差值就是你要找的“隐形占用”。二、查 du 遍历不到的三类空间1. 被挂载点盖住的旧文件。先往某个目录写了数据，后来又把一块盘挂到这个目录上，旧文件就被盖在下面了，du 走当前视图看不见，df 还照算。用 bind 挂载绕过挂载点直接看：sudo mkdir -p /mnt/rootviewsudo mount --bind / /mnt/rootviewsudo du -x -sh /mnt/rootview/* 2>/dev/null | sort -rh | head用完记得 sudo umount /mnt/rootview。2. 别的命名空间里的进程持有的文件。容器里跑的服务删了日志文件，但宿主机上的 lsof 不一定能看到容器命名空间里的句柄。先看容器日志和 overlay 占用：sudo du -sh /var/lib/docker/containers 2>/dev/nullsudo ls -lhS /var/lib/docker/containers/*/*-json.log 2>/dev/null | headsudo journalctl --disk-usagejournal 日志和没有轮转的容器 json 日志是 ECS 上最常见的“灯下黑”，du 逐层查时很容易被淹没在 /var 里面。3. 稀疏文件和块大小造成的虚高或虚低。ls -lh 显示的是逻辑大小，du 显示的是实际占用的块，稀疏文件两者能差很多倍。定位大文件时用实际占用排序：sudo find / -xdev -type f -size +500M -printf '%k KB %p\n' 2>/dev/null | sort -rn | head -20三、区分 inode 满和数据块满df -i / 看一下 inode 使用率。如果是 inode 耗尽，表现也是“写不进文件”，但 df -h 的 Used 未必满。海量小文件（缓存、会话、队列）是典型来源，定位方法是按目录数文件个数，而不是按大小：sudo find /var -xdev -type f | wc -lfor d in /var/*; do echo -n "$d "; sudo find "$d" -xdev -type f 2>/dev/null | wc -l; done | sort -k2 -rn | head四、安全清理的顺序先定位、后清理，别先 rm。已确认是某个服务仍持有的已删日志文件，优先用 : > /proc/进程号/fd/描述符编号 截断，空间立刻释放且不用停服务；能 reload 的服务优先 systemctl reload，让它自己重新打开日志文件。journal 用 journalctl --vacuum-size=200M --vacuum-time=7d 收缩，容器日志用 truncate -s 0 截断对应 -json.log。实在来不及定位、先保业务不中断，可以在控制台先给云硬盘扩容争取时间，再回头按上面顺序查根因。五、事后防复发给磁盘设 80% 告警，别等到 100% 才处理；日志统一走 logrotate 的 copytruncate 或服务自身的轮转，journal 设 SystemMaxUse 上限，Docker 在 daemon.json 里配 log-opts 的 max-size 和 max-file。下次再出现 df 和 du 对不上，先跑第一步的字节对账，差值出现在哪一类，答案基本就出来了。

先给一个判断标准：FunctionGraph 最适合“事件来了才干活、干完就停、无状态、单次耗时短”的任务。反过来，先问自己三个问题：触发条件是不是一个明确事件或定时？任务是不是间歇出现，而不是 24 小时满负荷？函数里要不要长期保存内存状态或本地文件？如果答案是“事件/定时、间歇、无状态”，用 FunctionGraph 往往比常驻一台 ECS 更省事、更便宜。 我认为最适合的四类场景： 第一，文件和消息触发的异步处理。OBS 桶里新上传一张图片或一个文件，触发函数做缩略图、格式转换、打水印或入库登记；消息队列收到订单消息后，触发函数做解析、校验和通知。这类任务天然是事件驱动的，平时没流量就不花钱，高峰来了平台自动扩容，不用自己管弹性伸缩。 第二，定时运维和小批量批处理。每天凌晨清理过期未支付订单、汇总前一天销量、定时调用接口同步数据、定期检查备份是否生成，都可以用定时触发器做，替代一台只为跑定时任务而常驻的服务器。我的做法是把每个定时任务拆成一个函数，一个函数只干一件事，出问题时日志和重试都好定位。 第三，轻量 API 和 Webhook 后端。配合 API 网关，做小程序表单提交、支付回调接收、第三方 Webhook 处理、企业微信或钉钉机器人都很合适。请求量小、接口逻辑简单时，按量计费的成本远低于包一台服务器；而且不用自己管操作系统补丁和进程守护。 第四，服务之间的“胶水”代码。日志清洗、文件格式转换、跨服务的数据搬运、轻量图片分类前处理，都适合写成小函数。函数本身保持无状态，状态放数据库、对象存储或消息队列里，这样扩容和重试都安全。 不太适合的三类场景也要注意：一是需要长时间连续运行的大批量任务，函数有单次执行时长上限，跑几个小时的作业还是用 ECS 或容器任务；二是需要常驻内存、保持长连接或会话状态的服务，例如 WebSocket 长连接；三是对冷启动延迟特别敏感的核心链路，首次触发或久未调用时会有额外启动时间，关键支付链路建议先压测再决定，异步补偿类任务则影响不大。 落地建议：函数拆小、配置好超时和重试次数，重要任务配死信或告警；密钥和数据库密码放环境变量或凭据管理，不要写进代码；需要访问 VPC 内数据库时配好 VPC 和安全组；先在控制台跑通一个 Hello World，再接一个真实触发器，观察两次日志和账单，确认费用和耗时后再逐步上量。

补充几个上面两楼没展开、但新手最容易真金白银踩到的坑，都是 OBS 和文件系统、和传统磁盘不一样的地方：一、桶名和区域一旦建好就改不了桶名在整个华为云全局唯一，别人占了就只能换名字；建桶时选的区域之后也不能改，选错区域只能新建桶再迁移数据。动手前先定好命名规范（比如项目-环境-用途）和区域：桶和要访问它的 ECS 尽量放同一区域，跨区域访问既慢又产生跨区域流量费。二、OBS 不是文件系统，别按磁盘的习惯用它OBS 里没有真正的目录，所谓“文件夹”只是对象 Key 的前缀；也没有原地重命名和移动，改名其实是复制一份再删除旧对象，大批量操作既慢又按请求次数计费。更不要直接把桶当本地磁盘读写——需要挂载访问的场景要用 obsfs 这类工具，而且它也只是把对象操作翻译成文件操作，不适合数据库、高频小文件写入这类场景。三、同名覆盖没有确认提示，删了也找不回来默认不开版本控制时，上传同名对象会直接覆盖旧版本，删除对象也是直接删除，控制台没有回收站。重要数据建桶第一天就把版本控制打开；需要删数据时，先用生命周期规则过渡到低频/归档再到期删除，而不是直接手动删。四、中断的分段上传和历史版本会悄悄占空间、产生费用大文件上传中断后，未完成的分段不会自动消失，会一直占用空间并计费；开了版本控制后，删除对象只是打了一个删除标记，历史版本还占着空间。定期检查：给桶配生命周期规则，清理超过 7 天未完成的分段上传，并对非当前版本设置过期删除。五、公开桶和流量的账单风险桶一旦设成公共读，任何人都能下载，遇到恶意刷流量会产生高额请求和流量费用。默认保持私有，需要临时给人下载时用带签名的临时 URL，而不是把桶公开；静态网站场景也要配好防盗链和访问日志，定期看账单里的请求量和流量有没有异常突增。六、对象名的小细节对象 Key 区分大小写，中文、空格等特殊字符在 SDK 和浏览器里要做 URL 编码，否则会出现“控制台能看到、程序里 404”的怪现象。建议对象名只用小写字母、数字、短横线和斜杠，规范从第一天就定下来。一句话总结：把 OBS 当成按量计费的对象仓库而不是一块磁盘——建桶先定区域和命名、重要数据开版本控制、分段残留和历史版本用生命周期定期清、桶默认私有只给临时签名链接，就能避开大部分新手坑。

补充一个 Go 后端视角的选型方法，核心是先看“触发、时长、状态”三条，再看冷启动能不能接受。一、适合的三类场景1. 定时任务：每天凌晨清理过期订单、每小时汇总数据、定时巡检资源到期情况。用定时触发器代替一台常年开机的 ECS，任务跑完就停，只花执行那几分钟的钱。2. 文件到了就处理：OBS 有新文件上传，触发函数做转码、生成缩略图、写处理记录，源桶和目标桶分开，避免写回再次触发。3. 低频或波动大的轻接口：内部工具、活动临时接口、第三方回调的签名校验和转存，没流量时不花钱，高峰自动扩容。二、Go 写函数的一个小优势Go 编译成单二进制，冷启动相对较轻，适合对延迟有点要求但又不值得常驻的接口。不过闲置后首次调用仍有冷启动，核心高频接口不要指望函数兜底。三、三个不要放函数里的1. 单次跑几十分钟的批处理，函数有执行时长上限（最长 900 秒），超时会被直接中断。2. 需要常驻监听、长连接、WebSocket 的服务，函数执行完就回收。3. 定时任务失败会重试，处理逻辑必须幂等，否则一次失败重试可能重复扣减、重复发通知；状态放数据库、缓存或 OBS，不要指望本地临时目录。一句话：触发是事件或定时、一次几分钟内能做完、无状态、低频或波动大，就优先 FunctionGraph；要常驻、长连接、长耗时，就选 ECS 或容器。

前面几位已经把权限、存储类别、生命周期、CORS、计费这些大坑讲得很全了，我补充几个同样常见、但新手往往是上线后才发现的点，尽量不重复：一、桶名是全局唯一的，建桶前先想好名字和区域桶名在所有华为云用户之间全局唯一，建桶时提示已存在，大多是撞了别人的名字，换个带业务前缀的名字即可。桶名和区域创建后都不能改：想换区域只能新建桶再迁移数据，所以建桶前先确认业务部署在哪个区域，尽量让桶和 ECS、函数等服务在同一区域，避免跨区域流量费。单个账号默认最多建 100 个桶，超了需要提工单扩容。二、对象不支持原地修改和追加OBS 是对象存储，不是文件系统：对象一旦写入就不能在原地改其中几个字节，也没有追加写。想改一个文件的内容，只能整体重新上传一个同名对象覆盖；日志类需要持续追加的场景，要按时间分片生成新对象，或者先写到 ECS 本地再定期归档到 OBS。三、单次上传有大小上限，大文件要用分段上传单次 PUT 上传一个对象最大 5GB，超过就必须用分段上传；单个对象通过分段上传最大可到 48.8TB。超过 100MB 的文件建议直接走分段上传或 SDK 的断点续传，网络抖动时只需重传失败的分段，不用从头再来。分段上传中途取消或失败后，残留的分段会一直占空间计费，记得在生命周期规则里加上清理未完成分段上传。四、对象元数据要在上传时定好，改了也不影响已发出的链接上传图片、PDF 时如果不指定 Content-Type，对象会按 application/octet-stream 存储，浏览器打开会直接下载而不是预览；下载文件名、缓存策略分别由 Content-Disposition、Cache-Control 控制。元数据事后可以在控制台修改，但已经发出去的签名 URL 和 CDN 缓存不会因此自动刷新，更新静态资源时要主动刷新 CDN 缓存，或者给文件名加版本号。五、服务端加密要区分两种方式放身份证、合同这类敏感文件时，建议开启服务端加密：SSE-KMS 由密钥管理服务保管密钥，可以禁用和轮换，适合合规要求高的场景；SSE-OBS 由 OBS 自行管理密钥，操作更简单。加密后的对象不能直接跨账号读取，跨账号分享前先确认对方的密钥权限。一句话总结：桶名和区域建前想清楚，对象只写不改，大文件走分段上传，元数据和加密在上传时就定好，先在测试桶把上传、下载、授权、生命周期、删除完整跑一遍，再往生产桶放真实数据。

先说结论：VPC 的主网段和子网网段创建后都不能直接改，只能扩、不能缩、不能换；所以规划时要按“够用再留一倍余量”的思路来。1. VPC 选多大建议起步选 /16，例如 10.10.0.0/16，一共 65536 个地址，足够分出多个子网还有余量。不要一开始就选 /24 这种小网段，后面业务一多就得分新 VPC，互通成本很高。选网段前先把公司内网、办公网、VPN、专线对端以及其他云的网段全部列出来，逐一错开，千万别和已经在用的网段重叠，否则后面打通专线或 VPN 时路由会冲突。2. 子网怎么切子网网段必须是 VPC 网段的子集，例如在 10.10.0.0/16 里切 10.10.1.0/24 给 Web 层、10.10.2.0/24 给应用层、10.10.3.0/24 给数据层。按用途分层，再按可用区分布：同一层在两个可用区各放一个子网，单个可用区故障时另一边还能接管。每个子网不要卡着实际数量切，系统会占用少量地址做网关等用途，实际可用地址比网段总数少，所以每个子网至少要留出 20% 以上的余量，弹性伸缩扩容时才不会没地址可用。3. 选错了怎么办如果只是地址不够用，可以把 VPC 网段向更大的范围扩展，前提是扩展后的范围不和已有子网及其他已用网段冲突；如果已经和公司内网冲突，扩展解决不了问题，只能新建一个不冲突的 VPC，建好对等连接或云连接打通新旧 VPC，然后把 ECS、RDS 等资源逐批迁移过去，改好安全组和路由，最后下线旧 VPC。这个过程要按业务分批做，迁移一台验证一台，不要一次性全切。一句话总结：网段规划是“一次定型、事后难改”的事，动手前先把所有要互通的网段列成一张表，确认无冲突再创建 VPC。

补充一个前面回答较少提到的起点：先确认“Too many connections”到底是谁报的，再按连接状态分流。报错文字一样，根因可能完全不同。第零步：先确认报错的来源同样是新建连接失败，有三种可能，不要一上来就默认是数据库打满：1. MySQL 本身报 ERROR 1040 (08004)：这才是数据库连接数到了 max_connections 上限。2. 应用连接池报获取连接超时：池子满了，但数据库可能还有空位，问题在应用侧池子太小或连接借出后没还。3. 中间代理或网关限流：请求根本没到数据库，报错信息里通常会带代理或网关的标识。区分办法很简单：用一个已有的管理连接或控制台会话执行 SHOW GLOBAL STATUS LIKE 'Threads_connected'，同时看 Connection_errors_max_connections 这个计数器。如果它大于 0 且还在增长，说明确实有连接因为打满被数据库拒绝过；如果它一直是 0，问题大概率不在数据库上限，而在应用池或代理。第一步：用两个数定方向Threads_connected 是当前连接总数，Threads_running 是正在执行 SQL 的连接数，两者一对比就能定方向：- 连接总数接近上限、正在执行的很少：连接都被占着但多数空闲。方向是连接泄漏、连接池配得过大，或者空闲回收没生效。- 正在执行的也接近上限：连接都在干活。方向是慢 SQL 或锁等待把连接拖住，并发一上来就把池子耗尽。- 两者都不高但新连接仍失败：先看是不是某个账号或某台主机的连接被单独限制了，再看代理层的连接上限。第二步：按来源分组，只看总数会误导用 information_schema.processlist 按 USER、HOST、COMMAND 分组统计，看三个特征：某台应用主机的连接数是否远高于其他主机；大量连接是否长时间处于 Sleep 且 TIME 不断增长；大量连接是否处于 Query 且 TIME 很大。第一种指向某台机器的连接池配置或某个服务在泄漏；第二种指向用完没归还、事务未提交或空闲回收没生效；第三种指向慢 SQL 或锁等待，要结合慢日志定位具体语句。第三步：临时止血的顺序先把 processlist 完整导出一份留存，杀完就查不到现场了。确实需要腾连接时，只处理来源已确认、长时间 Sleep 且无业务影响的会话，分批逐个 KILL，一边杀一边看业务影响，不要批量杀正在执行的业务连接，也不要直接重启实例——重启会清掉现场，如果是泄漏，几小时后必然复发。临时调大 max_connections 只是争取排查时间的手段，RDS 上建议通过控制台参数组调整并记录下来，不要当作长期方案。第四步：长期治理看三处一是连接池总账：所有服务的实例数乘以各自连接池上限，再加上定时任务和监控采集占用的连接，总和要留出两到三成余量给运维和突发。二是连接池与数据库的超时要对齐：池子的空闲回收时间应小于数据库的 wait_timeout，否则池里会留着已被服务端断开的死连接，触发重连风暴。三是按账号隔离：不同服务用不同数据库账号，必要时给次要服务限制最大并发连接，这样报表任务出问题时不会把核心交易的连接名额挤光。只读流量分到只读实例、应用与数据库之间加连接代理，也是把“应用连接数”和“数据库连接数”解耦的办法。最后补一个事前预警：给连接数使用率配 80% 左右的告警并要求连续多个周期触发，同时把 Max_used_connections 和 Connection_errors_max_connections 纳入日常巡检，前者接近上限说明已经没有余量，后者大于 0 说明确实有用户被拒过。

选型先看负载，再定规格，核心是“够用且留有余地”，而不是一步到位买大规格。 1. 先量化业务需求：看应用是 CPU 密集（计算、编码）、内存密集（缓存、数据库），还是均衡型；再看并发量、峰值 QPS、单机能扛多少请求。没有压测数据就凭感觉选，最容易买大或买小。 2. 按负载特征选系列：通用型适合大多数 Web 应用；计算密集选计算型；Redis、MySQL 这类内存占用高的选内存型；突发流量、不持续满载的业务可以考虑突发性能型。 3. 从小规格起步，用监控校准：先按预估的 60%~70% 资源占用选规格，上线后用云监控看 CPU、内存、磁盘 IO 和网络的实际使用率，连续一周峰值低于 40% 说明买大了，可以降配；峰值经常超过 80% 再升配。 4. 计费方式跟着业务周期走：长期稳定运行的业务用包年包月，比按量便宜；短期测试、弹性伸缩的业务用按量计费；能容忍中断的离线任务可以考虑竞价实例。 5. 横向扩展优先于一味升配：单机规格有上限，业务增长后靠增加实例数加负载均衡，比不断买更大的单机更划算，也更可靠。 6. 别忘了配套成本：系统盘、数据盘、带宽和快照都会产生费用，选型时把这部分也算进去，避免只看实例价格。 一句话：先测负载、按需选系列、小规格起步、靠监控调优，成本和性能的平衡是持续调出来的，不是一次买定的。

补充一个按时间线走的十分钟处置法，重点是先定性再动手，避免把不同根因混在一起处理。 第一分钟：先判断是不是真的被连接数挡住。看 Threads_connected、max_connections，再看 Connection_errors_max_connections 是否大于 0、Max_used_connections 是否贴近上限。只有前者大于 0，才说明确实有请求因为连接满了被拒；否则报错可能只是应用侧连接池等连接超时，别急着动数据库参数。 第二到三分钟：用两个数定方向。Threads_running 很小、Threads_connected 很高，说明连接大多空闲，方向是泄漏或池子开太大；Threads_running 也很高，说明连接都在干活，方向是慢查询或锁等待；连接数在短时间内直线爬升，同时 Aborted_connects 也在涨，说明有服务在反复建连失败重试，先去应用侧断流比在数据库侧杀连接更有效。 第四到六分钟：按来源分组，只处理能确认的。按账号、来源主机、状态分组，找出占比最大的那一组，再看这一组里 Sleep 占比和最长空闲时间。只杀同时满足三个条件的会话：来源已确认、长时间 Sleep、不是核心业务；杀之前先把 processlist 导出一份，杀完就查不到现场了。正在执行的业务连接不要批量杀，源头慢查询没定位之前，杀连接只是把排队换个地方。 第七到十分钟：应用侧查三处。第一，各服务实例数乘以单实例连接池上限，总和是否超过 max_connections；第二，连接池的空闲回收时间是否小于数据库 wait_timeout，否则池里会攒下已被服务端断开的死连接；第三，事务里是否套了外部调用或长循环，异常分支有没有漏关连接。Go 的 database/sql 可以用 db.Stats() 看在用、空闲和等待连接数，等待数持续大于 0 就是池子太小的直接证据。 长期治理：调大 max_connections 之前先算内存和实例规格，超过承载只会把连接报错变成慢查询报错；把只读流量分出去、给非核心账号设连接上限、把连接数使用率告警设在 80% 左右，复盘时把当时的分组统计和慢 SQL 样本留下来。

新手用 OBS 最容易踩的几个坑，按我自己实践中遇到的频率排一下： 1. 权限默认是私有的，上传完不能直接用链接打开。桶默认私有，对象直接访问会报 403。公开的图片、静态资源要把桶策略或对象 ACL 设成公共读，或者用临时签名 URL；生产环境千万别把整个桶设成公共写。 2. 区域和 Endpoint 别选错。桶建在哪个区域，SDK 和控制台就要用对应的 Endpoint，跨区访问会报 403 或者很慢；另外桶名是全局唯一的，创建失败很多时候是重名。 3. 费用不只看存储单价。请求次数、流出流量、跨区复制都单独计费。开启多版本后，历史版本也占空间、照样收费，删对象时要连旧版本一起清理。 4. 删除和覆盖不是立刻“消失”。开启版本控制后，删除只是打一个删除标记；同名覆盖上传也不会自动删旧版本。建议用生命周期规则定期把旧数据转低频或归档、过期删除。 5. 浏览器直传要先配 CORS，否则会报跨域错误；大文件用分段上传、支持断点续传，不要一次传几 GB。 6. 别在代码里写死 AK/SK。本地测试用环境变量或配置文件，生产走 IAM 委托或临时凭证；AK 一旦泄露，要立即在控制台删除并重新创建。 先把“私有还是公开、区域、版本、生命周期、CORS”这五项在控制台核对一遍，多数新手问题就解决了。