新手用 OBS 最容易踩的坑集中在权限、访问方式和成本三块，建议按下面顺序自查。桶权限别直接设成公共读写。需要外链访问的对象，只给「公共读」，写入一律用 IAM 子账号的 AK/SK 或临时访问凭证，并在桶策略里限定到具体前缀。区域和终端节点要对上。桶在华北-北京四，SDK 或 obsutil 的 endpoint 就得用 obs.cn-north-4.myhuaweicloud.com，否则会报 301 或 403。可用 obsutil config 后执行 obsutil ls 验证连通。大文件用分段上传。单次 PUT 上限 5GB，几百 MB 以上建议用 obsutil cp -p 5 -j 5 并开启断点续传，避免网络抖动重传全部。跨域问题：前端直传报 CORS 错误，需要在桶的「CORS 规则」里添加允许的来源、方法 PUT/GET/POST 以及 ETag 暴露头。成本陷阱：未合并的分段碎片会持续计费，请在「生命周期规则」里配置「删除未合并段」，并把 30 天后很少访问的数据转为低频或归档存储。误删防护：开启多版本控制，重要桶再开启服务端加密。验证方法：用子账号 AK/SK 执行 obsutil ls obs://桶名 -limit 10，再用无凭证的 curl -I 访问私有对象，应返回 403，说明权限没有放过头。

新手用 OBS 最容易踩的坑集中在权限、访问方式和成本三块，建议按下面顺序自查。桶权限别直接设成公共读写。需要外链访问的对象，只给「公共读」，写入一律用 IAM 子账号的 AK/SK 或临时访问凭证，并在桶策略里限定到具体前缀。区域和终端节点要对上。桶在华北-北京四，SDK 或 obsutil 的 endpoint 就得用 obs.cn-north-4.myhuaweicloud.com，否则会报 301 或 403。可用 obsutil config 后执行 obsutil ls 验证连通。大文件用分段上传。单次 PUT 上限 5GB，几百 MB 以上建议用 obsutil cp -p 5 -j 5 并开启断点续传，避免网络抖动重传全部。跨域问题：前端直传报 CORS 错误，需要在桶的「CORS 规则」里添加允许的来源、方法 PUT/GET/POST 以及 ETag 暴露头。成本陷阱：未合并的分段碎片会持续计费，请在「生命周期规则」里配置「删除未合并段」，并把 30 天后很少访问的数据转为低频或归档存储。误删防护：开启多版本控制，重要桶再开启服务端加密。验证方法：用子账号 AK/SK 执行 obsutil ls obs://桶名 -limit 10，再用无凭证的 curl -I 访问私有对象，应返回 403，说明权限没有放过头。

可以从“业务特征、弹性空间、单位成本”三个维度来平衡，下面是我常用的步骤。列出业务指标：峰值 QPS、单请求耗时、数据量、是否有状态。用公式粗估所需核数：核数 ≈ 峰值QPS × 单请求CPU耗时(秒) ÷ 目标CPU利用率(如0.6)。内存按进程常驻内存累加，再加 20% 给系统和缓存；Java 应用注意 JVM 堆设置，避免盲目加内存。优先横向扩展而不是单机堆大：用 2 台中等规格加负载均衡，比 1 台超大规格更便宜，也更容易容灾。无状态服务可配合弹性伸缩，按 CPU 使用率 70% 触发扩容、30% 缩容。先选按需实例做两三天实测，拿到真实曲线后，把基线容量转为包年包月，把波动部分留给按需或弹性伸缩，这样成本通常明显低于全部包月。网络带宽别忘了：按流量计费还是固定带宽，取决于流量是否平稳，可用 iftop 或云监控的出网流量判断。验证方法：用 sar -u 1 60、free -m 抽样，并在云监控里看 7 天最大值；如果最大值也低于 40%，下一次续费时就可以降一档规格。

选型的核心是先量化负载，再用最小规格试跑，最后按监控数据调整，而不是一开始就凭感觉买大。先确定瓶颈类型：Web/接口服务多偏 CPU 和网络，数据库、缓存偏内存和磁盘 IOPS，批处理看 CPU 与吞吐。按场景选规格族：通用计算型（vCPU:内存 1:4）适合大多数业务；内存密集型（1:8）适合缓存和数据库；计算密集型（1:2）适合编码、压测。先买低一档规格压测。用 wrk 或 ab 模拟峰值并发，同时在服务器执行 top、vmstat 1、iostat -x 1 观察 CPU、内存、磁盘等待。峰值 CPU 稳定在 60%~70% 左右、内存留出 20% 以上余量，就是比较合适的规格；长期低于 20% 说明配置过高。成本优化：长期稳定业务用包年包月；波动或临时测试用按需；可容忍中断的任务可评估竞价实例；配合云监控设置告警，规格不够时在控制台做“变更规格”（需关机）。磁盘单独评估：系统盘通用型 SSD 即可，数据库数据盘再选高 IO 或超高 IO。验证方法：变更后连续观察一周监控曲线，对比高峰期 CPU、内存、带宽使用率，再决定升配或降配。

选型的核心是先量化负载，再用最小规格试跑，最后按监控数据调整，而不是一开始就凭感觉买大。先确定瓶颈类型：Web/接口服务多偏 CPU 和网络，数据库、缓存偏内存和磁盘 IOPS，批处理看 CPU 与吞吐。按场景选规格族：通用计算型（vCPU:内存 1:4）适合大多数业务；内存密集型（1:8）适合缓存和数据库；计算密集型（1:2）适合编码、压测。先买低一档规格压测。用 wrk 或 ab 模拟峰值并发，同时在服务器执行 top、vmstat 1、iostat -x 1 观察 CPU、内存、磁盘等待。峰值 CPU 稳定在 60%~70% 左右、内存留出 20% 以上余量，就是比较合适的规格；长期低于 20% 说明配置过高。成本优化：长期稳定业务用包年包月；波动或临时测试用按需；可容忍中断的任务可评估竞价实例；配合云监控设置告警，规格不够时在控制台做“变更规格”（需关机）。磁盘单独评估：系统盘通用型 SSD 即可，数据库数据盘再选高 IO 或超高 IO。验证方法：变更后连续观察一周监控曲线，对比高峰期 CPU、内存、带宽使用率，再决定升配或降配。

平衡成本与性能可以按“先分类、再测量、后优化”三步走。按场景分类：在线业务看延迟，选稳定的通用型；离线任务看吞吐，可用更便宜的竞价实例或夜间按需开机；有状态服务别用竞价。测量真实需求：在 ECS 里装好监控插件，运行 7 天，导出 CPU、内存、网络和磁盘 IO 的 P95 值；规格应能覆盖 P95 并留 30% 余量，而不是覆盖偶发峰值。弹性应对峰值：用弹性伸缩 AS 设置“CPU 平均超过 60% 加一台，低于 25% 减一台”，再配合 ELB 做负载均衡，平时只付最小规模的钱。计费组合：基线容量包年包月，弹性部分按需，这样总成本通常比全按需低很多。定期复盘：每月看费用中心的成本分析，找出长期低利用率的实例，降配或释放；闲置的弹性公网 IP、未挂载的云硬盘也会持续计费，要及时清理。验证：调整后在监控看 CPU 利用率维持在 40%–60% 区间、应用响应时间无明显变化，就说明规格合适。

OBS 新手最常踩的坑，按我的经验整理如下，建议逐条自查：桶权限：默认私有，误设为“公共读写”会泄露数据或被刷流量。生产桶保持私有，需要外链时用带有效期的临时授权 URL。区域与终端节点：桶创建在哪个 Region，SDK/obsutil 就要用对应 endpoint，否则报 403 或找不到桶。同区域内的 ECS 走内网访问不收公网流量费。密钥安全：AK/SK 不要写进代码或上传到仓库，用 IAM 子账号、最小权限策略，定期轮换。存储类别：标准、低频、归档单价和取回费用不同，冷数据放归档前确认取回时间与费用；用生命周期规则自动转换或过期删除。跨域与静态网站：浏览器访问报 CORS 错误，需要在桶的 CORS 规则里配置允许的来源、方法和头。大文件上传：超过 100MB 用分段上传，失败可续传；obsutil cp 本地路径 obs://桶名/ -r 可批量上传。费用：流量、请求次数、存储量都计费，开启访问日志与费用中心预算告警。验证：obsutil ls obs://桶名 能列出对象，并在控制台“概览”查看流量与存储用量。

选型思路：先看负载特征，再定规格族，最后用监控数据微调，不要一开始就买最大的。摸底负载：Web/中间件偏 CPU，选通用计算型（S 系列）；数据库、缓存偏内存，选内存优化型；批处理、编译选计算型 C 系列。开发测试可用共享型/通用入门型，成本最低。起步配置：2vCPU4GB 或 4vCPU8GB 跑起来，压测或灰度一周，记录 CPU、内存、磁盘 IO、带宽的峰值与均值（云监控 CES 可直接查看）。调整原则：CPU 长期低于 20% 就降一档；峰值超过 70% 持续出现就升一档或做弹性伸缩（AS）。内存不足先看 free -m，别只盯 CPU。计费方式：长期稳定业务用包年/包月（折扣明显），波动业务用按需+弹性伸缩，短期测试用按需或竞价实例。存储与带宽：系统盘通用 SSD 即可，数据库盘再考虑超高 IO；带宽按峰值与流量二选一，按流量计费往往更省。验证：压测后在 CES 看曲线，top、vmstat 1 5 看瓶颈在哪，再决定升降配；控制台“变更规格”需要关机，业务窗口内操作。

两个 OBS 常见问题可以先查这几项，基本能覆盖新手遇到的大部分状况：访问 403：先看桶策略、ACL 和 IAM 授权三处是否冲突，显式的 Deny 优先级最高；再检查系统时间是否偏差过大，签名依赖时间，偏差超过 15 分钟会校验失败。跨域访问失败：在桶的“CORS 规则”里配置允许的来源、方法和头部，浏览器直传时还要暴露 ETag 头。存储费用超预期：在费用中心看是流量、请求次数还是容量；用生命周期规则清理过期数据，删除未完成的分段上传碎片，多版本桶要设置旧版本过期。下载慢：同区域 ECS 用内网域名访问；公网下载可以绑定自定义域名并配合 CDN 加速。对象名与目录：OBS 是扁平结构，目录只是以斜杠结尾的对象，列举大量对象时要用前缀和分页，不要一次全量列举。数据安全：重要桶开启版本控制或跨区域复制，并启用服务端加密。验证：用 obsutil 执行 obsutil stat obs://桶名 查看桶状态，并用 obsutil cp 本地文件 obs://桶名/ 测试上传，确认权限和网络正常。

成本与性能的平衡，核心是先量化负载，再选规格，最后靠监控持续调整，建议按下面步骤做：先摸清业务特征：CPU 密集（编码、计算）选计算型，内存密集（缓存、数据库、JVM 大堆）选内存型，一般 Web 和中小应用先用通用型。不要一开始就上大规格。用压测给出基线：用 wrk 或 JMeter 在测试机上压测，记录目标 QPS 下的 CPU、内存、磁盘 IO 和网络带宽，确定最小可用规格，再留 30% 左右余量。CPU 与内存比例要匹配：Java 服务一般 1:2 到 1:4，缓存类 1:8 更合适；内存经常吃紧时，加内存比加核数更划算。计费方式要组合：长期稳定的负载买包年包月，波动明显的用按需，短期测试用竞价实例，并保证有容错能力。磁盘别浪费：通用型 SSD 能满足大多数场景，只有 IOPS 确实成为瓶颈才上超高 IO，数据盘可后续在线扩容。上线后看云监控：CPU 长期低于 20% 就考虑降配，持续高于 70% 就升配或做弹性伸缩，每月复盘一次。验证：用 top、free -m、iostat -x 1 在高峰期采样，与云监控曲线对照，确认没有隐藏的 IO 或带宽瓶颈。