结论：先按业务定规格族、按实测负载定大小，再用计费方式控成本；规格可以在线升降配，不用一次买满。一、先看业务类型，再看核数1. 轻量 Web、企业官网、小程序后端：通用型 s 系列，2vCPU 4GB 起步，够大多数中小业务用。2. CPU 密集（批量计算、转码）：计算型 c 系列，看主频和核数。3. 内存数据库、缓存、实时分析：内存型 m 系列，vCPU 与内存约 1:8。4. 自建数据库、日志：磁盘增强型，重点看云盘 IOPS，而不是只加核数。5. 开发测试、间歇任务：突发性能型 t 系列便宜，但持续高负载会被限速，别当生产主力。6. 只有模型推理、视频处理这类负载才需要 GPU 型，纯 Web 和数据库买 GPU 是浪费。二、再用监控定大小，不要拍脑袋1. 已有业务：云监控看 7 天 CPU、内存、磁盘 IOPS、带宽的峰值和均值，峰值留约 20% 余量。2. 新业务：小规格起步，真实流量跑 3 到 7 天再调。3. 升降标准：CPU 峰值持续高于 70% 或内存经常打满就升一档；长期低于 20% 就降一档；内存峰值超 85% 先查泄漏和缓存配置，再考虑升配。三、最后用计费方式和价格计算器核对1. 长期 7×24 稳定运行：包年包月通常最划算。2. 短期测试、活动：按量计费，用完释放；注意按量机器只关机不停费，长期不用要释放。3. 可中断的离线批处理：可看竞价实例。4. 下单前在控制台价格计算器里把规格、云盘、带宽、时长输进去，对比包年包月和按量两种总价再决定。5. 上线后每周看一次监控曲线复核，规格、云盘、带宽都能单独调整，不用为一个短板整体升一档。

结论先行：不要一上来就调大 max_connections，也不要直接重启数据库。先用已有的连接或 RDS 控制台的会话管理进去看现场，按“确认是连接数挡住 → 按来源和状态分组定性 → 查连接池与事务 → 定位慢 SQL → 先止血、再长期治理”的顺序走。调大上限只在确认是真实容量不足、且实例内存能承受时才考虑。 第一步：先确认真的是连接数挡住了1. 看报错本身是不是 ERROR 1040 (08004): Too many connections，而不是密码错误、网络不通或实例不可用，报错不同，排查方向完全不同。2. 用已建立的连接或 RDS 控制台 / DAS 会话管理进去，不要用新连接反复重试，以免把最后的名额也占满。3. 看三个数：SHOW VARIABLES LIKE 'max_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected'; SHOW GLOBAL STATUS LIKE 'Threads_running'; 再看 SHOW GLOBAL STATUS LIKE 'Connection_errors_max_connections';，后者大于 0 说明确实有人因为连接数满被拒绝过，Max_used_connections 接近上限说明余量已经没有了。 第二步：用两个数分出方向- Threads_connected 接近上限、Threads_running 很小：连接都被占着但多数空闲，方向是连接泄漏、连接池配得过大，或短连接反复新建。- Threads_running 也接近上限：连接都在干活，方向是慢 SQL 或锁等待堆积。- 再结合云监控里连接数的趋势：是高峰突然爬升，还是缓慢递增不回落。前者像突发流量或重试风暴，后者像泄漏。 第三步：按来源和状态分组，定位到具体服务SELECT USER, HOST, COMMAND, COUNT(*) AS cnt, MAX(TIME) AS max_time FROM information_schema.processlist GROUP BY USER, HOST, COMMAND ORDER BY cnt DESC LIMIT 20;再按 TIME 从大到小看正在执行的会话：SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.processlist ORDER BY TIME DESC LIMIT 20;看三个特征：某台应用主机或某个账号的连接数远高于其他，说明那台机器或那个服务在泄漏；大量 Command=Sleep 且 TIME 达到几百上千秒，说明连接池空闲回收没生效，或用完没归还；大量 Command=Query 且 TIME 很大，说明是慢 SQL 拖住了连接。 第四步：应用侧先算连接池总账，再查事务1. 把所有连这个库的服务加起来算总账：实例数 × 单实例连接池上限，是否已经超过 max_connections。这是打满最常见的原因，扩容应用副本前要先算这一笔。2. 查连接池的空闲回收和超时回收是否生效，连接池的空闲回收时间应小于数据库的 wait_timeout，否则池里会留着已被服务端断开的死连接。3. 查长事务：事务里套 RPC、循环里逐条写、异常分支漏了提交或关闭，都会让连接一直挂着。结合 information_schema.innodb_trx 看事务开始时间和状态。4. 顺便确认应用是不是在用短连接：每次请求都新建连接、用完就丢，连接数会随并发直线上升，这种情况要改成连接池复用，而不是调大数据库上限。 第五步：慢查询要定位到具体 SQL按 TIME 从大到小看正在执行的语句，再结合慢日志确认是同一类 SQL 反复出现，还是个别大查询；同时看 STATE 是否在锁等待，不要只看 CPU。先优化或限流拖住连接的那类 SQL，再谈扩容。 第六步：临时止血和长期治理分开做临时止血：先把 processlist 完整导出一份留现场，杀完就查不到了；只逐个 KILL 长时间 Sleep、来源明确为非核心或已下线服务的连接，不要批量杀正在执行主业务的连接；扛不住时从入口限流，或临时摘掉有问题的服务节点，让核心业务先活着。长期治理：确认内存能承受再动上限，每个连接都会占用线程和缓冲，盲目调大可能把连接数满变成内存不足；只读流量分到只读实例，必要时用 RDS 数据库代理收敛连接，把应用连接数和数据库连接数解耦；给连接数使用率配告警，阈值设在 80% 左右，不要等到应用报错才发现。 容易踩的三个坑：直接重启实例会清掉现场，如果是泄漏，几小时后必然复发；直接调大上限只对真实容量不足有效，对泄漏和慢 SQL 是掩盖问题；批量 KILL 正在执行的业务连接，可能把本来能跑完的请求也打断。 一句话总结：先确认报错和三个数，再按来源分组定性，然后查连接池总账和长事务、定位慢 SQL，最后才动上限；每一步先确认影响面再动手。

结论：df 读的是文件系统已分配块的总数，du 是沿目录树逐个文件累加；两者对不上，说明空间藏在 du 遍历不到的地方。按下面顺序查，多数情况不用扩容、不用重装就能定位。第一步：先把统计口径对齐df -hT / ；df -i /sudo du -x -h --max-depth=1 / 2>/dev/null | sort -rh要点：du 加 -x 限定同一文件系统、加 sudo（普通用户权限不足会漏统计）；df -i 单独看 inode，小文件太多时容量没满也写不进文件，那是另一个问题。第二步：已删除但仍被进程占用的文件（最常见，楼主说 lsof 没找到明显，建议换个查法）sudo lsof +L1或 sudo lsof | grep deleted，按大小排序只看前几行；输出多时不排序很容易看漏。也可以直接扫 /proc：sudo find /proc/[0-9]*/fd -lname '* (deleted)' 2>/dev/null确认后不一定要杀进程：以 root 身份用 : > /proc//fd/ 截断，空间立即释放；能安排维护窗口时重启对应服务更彻底。以后不要直接 rm 正在写的日志文件，用 logrotate 的 copytruncate 或重启服务轮转。第三步：挂载点遮住的旧文件先往目录写了数据、后来又把云硬盘挂到同一目录，旧文件就被盖住了。findmnt -R /sudo mkdir -p /mnt/rootview && sudo mount --bind / /mnt/rootviewsudo du -sh /mnt/rootview/原目录>确认后把遮住的数据移走或删除，再卸载临时挂载。第四步：ECS 上最容易灯下黑的两处systemd journal：journalctl --disk-usage；应急用 sudo journalctl --vacuum-size=200M --vacuum-time=7d，长期在 journald.conf 设 SystemMaxUse 上限。Docker（如果跑容器）：docker system df 看不到容器日志大小，要直接看 sudo du -sh /var/lib/docker/containers/* | sort -rh；单个 *-json.log 无轮转会涨到几十 GB，应急用 sudo truncate -s 0 日志路径>，长期在 daemon.json 配 log-opts 的 max-size / max-file。另外顺手看一眼 /tmp、/var/tmp、/var/crash 和 coredump：sudo du -sh /tmp /var/tmp /var/crash。第五步：核对剩余差额ext4 默认给 root 预留 5%：tune2fs -l /dev/xxx | grep -i reserved，数据盘可酌情调低，系统盘不要随意改。稀疏文件、btrfs 快照/子卷也会让两者对不上，确认文件系统类型后再按类型查（btrfs 用 btrfs filesystem usage）。清理前提醒：先定位归属和业务用途再删，不要先扩容掩盖问题；磁盘快满时先备份重要数据再清理；同时给这块盘配云监控磁盘使用率告警，下次到 85% 就收到通知，不用等到 100% 才发现。

先给结论：成本与性能的平衡点不在“一次买多大”，而在“钱花在瓶颈上”——先用监控找出 CPU、内存、磁盘 IO、带宽这四项里哪一项先到瓶颈，只给瓶颈加配置，非瓶颈配够用就行；再用“包年包月打底 + 按量弹性扛峰值”控成本，买错了还能变更规格。一、先找瓶颈，再谈规格1. 看监控定瓶颈：云监控（CES）里看 CPU 使用率、内存使用率、磁盘 IOPS/吞吐、带宽四条曲线，峰值时哪一项先到 80% 以上，它就是瓶颈；没到瓶颈的资源配再高也是闲置。2. 瓶颈决定系列：CPU 先满选计算型，内存先满选内存型，四项比较均衡选通用型；只有平时很闲、偶尔短暂突发的轻量业务才考虑突发性能型。3. 别只盯核数：内存不够会先 OOM，磁盘 IO 打满会让数据库先垮，带宽太小会让高配 CPU 空转——瓶颈往往不在核数上。二、大小用实测定，不凭感觉1. 先小后大：按当前峰值选够用的起步档，留 20%~30% 余量即可，余量过大等于长期闲置。2. 压测定档：按峰值流量的 1.2 倍压测，看响应时间和错误率，压测通过的最小规格就是合适的档位。3. 买错能改：ECS 支持变更规格（关机后升配或降配），所以起步不必一次到位，买小了能升、买大了能降。三、成本靠计费组合来控1. 7×24 小时长期跑的基线负载用包年包月；波动大、临时性的任务用按量，用完释放。2. 流量波动大的业务用弹性伸缩组自动加减实例，峰值时自动加、闲时自动减，比长期买一台大规格更省。3. 附加资源也要算：云硬盘、弹性公网 IP、带宽都是成本，磁盘按实际数据量加增长预留，带宽按峰值估算，别只盯着实例价格。一句话总结：先用监控找瓶颈、按瓶颈选系列，再用实测定大小、靠“包年包月 + 按量弹性”控成本，买错了还能变更规格，先小后大、边跑边调最划算。

结论先行：新手用 OBS 最容易踩的坑集中在三处——权限（默认私有，公开访问要单独开）、区域与域名（桶建在哪个区域、访问就从哪里走）、费用与清理（分段上传碎片和历史版本会持续计费）。先按下面七步自查一遍，基本能避开九成问题。一、权限：默认私有，别轻易把桶设成公共读1. 新建桶默认是私有，只有桶拥有者能访问；不要为了图省事把整个桶改成公共读。2. 临时给别人下载，用预签名 URL（带有效期，过期自动失效）；只有长期公开的静态网站场景，才考虑公共读，且只对必要的对象授权。3. AK/SK 是账号的钥匙，不要写进前端代码或公开仓库，泄露后立即在控制台删除并重新创建。二、区域：桶建在哪里，访问就从哪里走1. 桶一旦创建，区域不能改；同区域的 ECS 走内网域名访问，跨区域访问要走公网。2. 建桶前先定好业务跑在哪个区域，桶就建在同一个区域。三、对象没有真正的文件夹，只有带斜杠的对象名1. OBS 是对象存储，没有真正的文件夹，控制台里看到的“文件夹”只是以 / 结尾的对象名或前缀。2. 删除“文件夹”前要确认该前缀下的所有对象都已删干净；按前缀批量操作时先小范围验证。四、浏览器直传先配 CORS，跨域报错不是网络问题1. 网页前端直接往 OBS 传文件时，要在桶上配置跨域规则（允许的来源、方法、请求头），否则浏览器会报跨域错误。2. 改完规则后清掉浏览器缓存再试，旧的预检结果可能被缓存。五、删除、覆盖与版本：先开版本控制，再谈误删恢复1. 默认不开启版本控制，覆盖和删除后旧对象找不回来；重要数据先开版本控制再传。2. 分段上传失败或取消后会留下碎片，历史版本和碎片都会继续占用存储并计费，定期用生命周期规则清理碎片和过期版本。六、费用：存储不是唯一账单项1. OBS 计费除了存储容量，还有请求次数和公网流出流量；频繁的小文件读写、大量 List 请求都会产生费用。2. 公网下载量大时，考虑用 CDN 加速分流；不用的桶和对象及时清理，别让测试数据长期占用存储。七、自定义域名与备案1. 绑定自己的域名访问桶之前，域名要先完成备案，并按控制台提示做好解析验证。2. 先用默认桶域名确认桶本身能正常访问，再排查域名解析和备案环节。一句话总结：桶保持私有、临时访问用预签名 URL；桶与业务建在同一区域；重要数据开版本控制；碎片与过期版本用生命周期清理；大流量走 CDN。

结论：平衡成本与性能不是买最大规格，而是先定负载画像、从小规格起步、按周期选计费、上线后用监控调优。系列选错比规格选小更浪费钱。第一步：给业务画像。先分清业务类型：CPU 密集（计算、转码）、内存密集（缓存、数据库）、I/O 密集（数据库、日志）、网络密集（网关、代理）。再用一段时间的云监控数据说话，看 CPU 平均与峰值利用率、内存占用、磁盘读写和带宽峰值，据此定下 CPU、内存、磁盘、带宽四个数，而不是凭感觉买。第二步：按画像选系列。通用型适合 Web 和轻量应用；计算型适合 CPU 密集型任务；内存优化型适合缓存和内存数据库；磁盘增强型适合高 I/O 场景；GPU 型只给 AI 推理和训练用。系列选错，规格再大也跑不出效果。第三步：从小规格起步，留出弹性。个人博客、小型网站从 2 核 4GB 这类小规格起步完全够用，业务量上来再纵向变更规格或横向增加实例，配合弹性伸缩按负载自动增减，比一开始就买高配更省钱。ECS 支持规格变更，变更前先做好快照或备份，并确认是否需要重启。第四步：计费方式按使用周期搭配。长期稳定运行的业务选包年包月；短期测试、临时任务用按需计费，用完释放；能容忍中断的离线任务可关注竞价实例。云硬盘选通用型 SSD 够用就别上更高规格，带宽按实际峰值选，别只盯着 CPU 和内存。第五步：上线后持续调优。定期看云监控的 CPU、内存、磁盘和网络曲线：CPU 长期低于 20% 说明买大了，可以降配；CPU 长期跑满、内存长期超过 80% 或频繁出现 OOM，就该升配或先排查程序问题。选型不是一次性的，定期复盘账单，把闲置、超配的实例降配或释放。

结论先说：本机 curl 127.0.0.1:8080 通，只说明应用本身在跑；外网 telnet 超时，说明请求在到达应用之前被某一层丢弃了。不要反复改安全组，按“内网先通、外网后通”的顺序分段测，一轮就能定位。第一步，先确认监听地址。服务器上执行 ss -tlnp | grep 8080。如果显示 127.0.0.1:8080，应用只监听了回环地址，外网永远进不来，改成绑定 0.0.0.0 后重启服务；显示 0.0.0.0:8080 或 *:8080 才算正常。如果应用在 Docker 里，还要确认启动时做了 -p 8080:8080 端口发布。第二步，用内网分段。找同 VPC 的另一台机器 curl 内网 IP:8080。如果内网也不通，问题在主机内部，重点查第三步；如果内网通、外网不通，问题在云侧入口，重点查第四步。这一步能把排查范围缩小一半。第三步，查主机防火墙。Linux 上 firewalld 执行 firewall-cmd --list-ports，看 8080 是否在列，不在就放行后 reload；用 iptables 或 nftables 的对应查 INPUT 链。Windows 检查高级安全防火墙的入站规则。定位时可以临时放行验证，确认后改为精确放行，不要长期关闭防火墙。第四步，复核云侧入口。确认这条 TCP 8080、源 0.0.0.0/0 的规则加在当前这台 ECS 绑定的安全组的入方向上，而不是另一台机器或出方向；多安全组按并集生效。确认 EIP 绑定的是这台 ECS，带宽不是 0，账号没有欠费停服。如果子网关联了网络 ACL，入方向要显式放行 8080，出方向也要放行回包。第五步，抓包定界。还拿不准时，在 ECS 上执行 tcpdump -ni any tcp port 8080，同时从外网访问：完全看不到 SYN，说明包没到主机，回头查第四步；能看到 SYN 但没有 SYN-ACK，说明包到了主机但没响应，回头查第一步和第三步。另外两个容易踩的坑：一是 ping 通不代表端口通，ping 走 ICMP，测端口一律用 telnet、curl 或 nc 测 TCP；二是本地公司网络可能封高位端口，换手机热点测一次，热点通、公司网不通就是本地出口的问题，与云上配置无关。按上面顺序走完，把 ss 和防火墙的输出贴出来，一般都能定位。

结论：新手用 OBS 最容易踩的坑，不是某一个功能，而是把桶当成普通文件夹、把对象链接当成永久公开链接、把权限和计费混在一起。先按下面三步自查：确认区域与域名、确认权限与访问方式、确认存储类型与生命周期，多数问题在配置阶段就能避开。 一、先按报错定位，别一上来就改桶策1. 报 403 或 AccessDenied：先查访问身份和权限。控制台能上传、程序或链接却报 403 时，常见原因是 AK/SK 用错、IAM 权限不足，或访问域名里的区域与桶所在区域不一致。先核对这三项，再看桶策略。2. 报 404 或找不到桶、找不到对象：先核对桶名、区域和对象 key，注意对象 key 区分大小写，复制链接时不要多带或少带字符。3. 浏览器打不开对象链接：先确认桶是私有还是公开。私有桶的对象链接直接打开会报权限错误，需要用临时签名 URL；签名有时效，过期后链接失效是正常现象，重新生成即可。 略  二、访问方式：默认私有，需要公开再单独放1. 桶默认私有是最安全的状态，不要为了图方便把整个桶设成公共读写。2. 只想让个别人临时下载，用临时签名 URL；只想让网站上的图片能被访问，优先走 CDN 回源鉴权，而不是把桶公开。3. AK/SK 不要写进前端代码或提交到代码仓库；给程序用的账号只给实际需要的最小权限，密钥定期轮换。 行 三、上传与计费：大文件分片、别只看存储费1. 大文件不要单次上传，网络波动容易失败重传，用分片上传支持断点续传；失败后要清理残留的分片，否则碎片也会占用存储。2. 存储类型要和访问频率匹配：经常访问的放标准存储，很少访问的冷数据再考虑低频或归档存储，取回冷数据需要等待且可能产生取回费用。3. 账单不只有存储费，还有请求次数费和下行流量费。程序不要高频轮询、反复列出全桶对象；对外提供下载的图片、文件建议走 CDN。4. 重要数据先开版本控制，防止误删或覆盖后无法恢复；再用生命周期规则清理过期版本和残留分片，避免版本堆积推高成本。 四、上线前检查清单1. 区域、桶名、访问域名是否一致？2. 桶是不是私有？需要公开的是否只放行了必要的对象或路径？3. AK/SK 是否只在服务端使用、权限是否最小？4. 存储类型、生命周期、版本控制是否已按数据冷热配好？5. 用一个真实对象从头到尾验证一次上传、下载和临时签名链接是否可用？一句话：先确认区域和访问方式，再确认权限和存储类型，最后用一次真实上传下载验证，OBS 新手阶段的大多数坑都能避开。

结论先行：这不是驱动坏了，而是 ReadWriteOncePod（RWOP）按设计生效的排他结果。RWOP 要求整个集群同一时间只能有一个 Pod 使用这块 EVS，旧 Pod 还在 Terminating、卷还没 detach，新 Pod 必然 attach 失败。单副本 RWOP 卷做不到不停机滚动更新，只能接受短暂停机窗口，或者换架构。 一、排他在两层，但同节点被挡是 RWOP 本身的定义1. 控制面层：VolumeAttachment 记录卷被哪个 Pod、哪个节点占用，external-attacher 据此决定是否调用 CSI 的 ControllerPublishVolume。2. 驱动层：CSI 驱动真正执行 attach/detach，并在挂载前校验。两者配合，所以事件里会看到 FailedAttachVolume。3. RWO 只保证“一个节点”，RWOP 保证“一个 Pod”，所以即使新旧 Pod 在同一节点，也会被挡住，这是 RWOP 比 RWO 更严的地方，不是同节点例外。 二、推荐的更新方式1. 先确认实际 workload 类型。你写的是 StatefulSet OrderedReady、副本 1，理论上滚动更新是先删旧 Pod（同序号）再建新 Pod，不会同时出现两个同序号 Pod；如果你确实看到新旧并存，先确认是不是 Deployment、Parallel 策略或手动操作造成的，否则只改策略治标不治本。2. Deployment：把 strategy.type 改为 Recreate，先停旧 Pod、等卷 detach，再建新 Pod。3. StatefulSet：保持 OrderedReady，更新时不要手动并行建 Pod；低峰期操作，先给 EVS 做快照/备份，再触发更新。4. 缩短等待：可以把 terminationGracePeriodSeconds 从 60 收小（例如 15 秒），但前提是应用能在该时间内完成停写、刷盘；不要直接设成 0 或过小，否则未落盘的数据可能丢失。配合 preStop 先停写、刷盘，再退出。5. 验证：更新时用 kubectl get pod -w 和 kubectl get volumeattachment 观察旧 Pod 是否已完全消失、卷是否已 detach，确认 detach 后新 Pod 才能正常 attach。 三、几乎不停机做不到，K8s 没有这个钩子1. 没有“旧 Pod 先 umount、再让新 Pod attach”的钩子。preStop 只在 Pod 终止流程内执行，kubelet 只有在 Pod 完全终止后才会卸载卷，preStop 不能提前把卷让出来。2. 想不停机，必须换架构：业务改多副本无状态 + 数据放数据库/对象存储，或用主从复制、共享存储方案；单块 RWOP EVS 本身就是单写者设计。 四、多副本共享不要用 EVS，换 SFS 后一致性也不靠文件系统1. 需要多 Pod 同时读写，应换 SFS（RWX）或对象存储，而不是 EVS。2. SFS 只提供多 Pod 同时挂载，不保证多个写者同时写同一文件的一致性；并发写一致性要靠应用层：单写者、文件锁、分片、数据库事务或对象存储的版本控制，不要依赖共享文件系统本身。 五、CSI 版本不要猜，先验证1. 你这套已经出现“独占生效 + FailedAttachVolume”，本身就说明当前 CSI 已在执行 RWOP 排他；如果驱动完全不支持 RWOP，不会出现这种明确的独占拦截。2. 验证方法：kubectl get csidriver 查看对应驱动，检查集群的特性门/驱动配置是否开启 ReadWriteOncePod；不确定时先在测试集群验证升级，不要直接在生产集群换驱动版本。3. 若升级驱动，先确认新驱动与当前 CCE 版本的兼容说明，再在低峰期操作。 一句话：RWOP 单副本 EVS 先接受“先停后起”的停机窗口；要不停机或多写者，就换架构，不要在 RWOP 上硬凑。

结论先行：新手用 OBS 最容易踩的坑不在上传本身，而在把它当成云硬盘或本地文件夹用。OBS 是对象存储：对象一旦写入只能整体替换，没有“改一个文件里的一行”这种操作；权限默认私有、计费按量、Key 就是完整路径。先按下面六点自查一遍，能避开绝大多数问题。 1. 权限不要图方便开公共读桶默认私有是对的。不要为让别人下载就把整个桶设成公共读；给指定的人临时下载，用后端签发的预签名 URL，设置较短的有效期，AK/SK 不要发给对方、不要写进前端代码。桶策略、IAM 权限和对象 ACL 是叠加生效的，改了一处没生效，先看另外两处有没有放行。 2. 计费：删了文件不等于不花钱存储费用按实际占用的量算。开启多版本后，删除只是在新版本上打删除标记，旧版本还在计费；分段上传没完成、上传失败留下的碎片也会继续占空间，要在生命周期规则里清理未完成的分段上传和过期版本。存储类别也要先定好：经常访问用标准存储，不常访问用低频访问存储，归档存储取回需要时间且有取回费用，不要把热数据直接放归档。 3. Key 就是路径，没有真正的文件夹控制台里看到的“文件夹”只是 Key 里用 / 分隔的前缀。改名、移动对象实际是复制一个新 Key 再删除旧对象，大对象会花时间和流量；Key 尽量用字母、数字、短横线和下划线，少用空格和特殊字符，程序里拼接访问地址时要做 URL 编码。 4. 不要把 OBS 当云硬盘挂载用OBS 不支持像云硬盘那样随机读写、原地修改。日常用控制台或 OBS Browser+ 上传下载，大文件、批量上传用 SDK 或工具做分段上传和断点续传；如果业务必须按文件系统方式访问，先确认应用能不能接受对象存储的语义差异，再决定是否用挂载工具，不要直接把数据库文件、频繁改写的日志放到 OBS 上。 5. 访问入口和区域要对上桶建在哪个区域就用哪个区域的访问域名，跨区域访问会多走公网、变慢还可能多花流量。给桶绑自定义域名要先做域名备案和 CNAME 解析，证书也要配好；直接用桶自带域名做线上下载地址，遇到防盗链、跨域问题时先检查桶的 CORS 和防盗链配置，而不是反复改代码。 6. 上传后先核对再当作完成重要文件上传完先核对对象大小，下载一次打开确认内容无误；程序上传时用返回的 ETag 或对象元数据做校验，失败重试不要只看“上传接口没报错”。删除、覆盖重要对象前先确认有没有多版本或备份，误删后第一时间看能不能从多版本历史里恢复，不要马上清空。 一句话：权限保持最小、计费看清多版本和碎片、Key 当路径来管、按对象存储的用法用 OBS，遇到问题先看控制台里的桶策略、生命周期和对象详情，再排查自己的代码。