前面几楼把负载画像、CPU:内存比、计费方式和云监控调优讲得很清楚，我补一个能直接算、又最容易选错的角度：先测「可并行度」，再决定加核还是加单核性能。很多业务升到 8 核 16G 后吞吐几乎没涨，钱却翻倍，根因是串行段卡住了，加核帮不上忙。 一、用 Amdahl 定律给加核收益封顶。若程序中不可并行的比例是 s，则 n 核相对单核的理论加速上限为 1/(s + (1-s)/n)。举例：s=0.3 时，4 核上限约 2.1 倍、8 核约 2.6 倍、16 核约 2.9 倍——从 8 核升 16 核只多 11%，但月费接近翻倍。反过来 s=0.05 时 8 核能到 5.9 倍，加核就很划算。所以「4 核够不够」不该靠感觉，而该先估出 s。 二、s 怎么测：固定输入，只改 worker 数，跑同一段真实业务（不是空转 benchmark），记录吞吐 Q(n) 与 P95 延迟。用两组数据就能反推：取 n=1 与 n=4，由 Q(4)/Q(1) = 1/(s+(1-s)/4) 解出 s；再用 n=8 的实测值验证预测，若明显低于预测，说明还叠加了锁竞争、共享连接、磁盘或网卡瓶颈，不是纯并行度问题。这一步用 sysbench / wrk / 自己的压测脚本都能做，成本很低，但能避免一上来就买大规格。 三、瓶颈不在 CPU 时的三个高频信号，用命令就能定位：① CPU 利用率不高但吞吐上不去，且 iowait 明显 → 先看云盘 IOPS/吞吐是否已到该盘规格上限（fio 测 randread，对照盘型标称值），加核无用，要升盘型或改批量写；② 单核跑满、其余核空闲，top 里 1 核 100% → 典型串行段或单线程程序，要么拆任务，要么选主频更高的新一代系列，别买更多核；③ PPS/带宽到顶（sar -n DEV 看 pps、云监控看出网带宽），小包场景常先撞网卡 PPS 限制而非 CPU，这时该看规格族的网络基线而不是核数。 四、把结论写成一个可复算的表，别只写「选 4 核 8G」：列上目标 QPS、P95 上限、实测 Q(1)/Q(4)/Q(8)、反推 s、当前盘 IOPS、峰值出网带宽、月费、以及单位有效吞吐成本 = 月费 / 实测 QPS。这样规格变更前后能直接对比「每千 QPS 花了多少钱」，也比只看 CPU 利用率判断要不要降档可靠——CPU 低不代表没浪费，可能是被 I/O 卡住的空转。 五、两个容易忽略的成本项：同规格不同代际的单核性能差异可能超过 20%，选较新系列往往比选更多核便宜；另外变更规格通常伴随停机或重启，压测要在同可用区、同盘型下做，否则数据不可比。上线后保留一周的 P50/P95/P99 分位数和资源曲线，用尾延迟而不是平均利用率作为升档触发条件，能避免「平均看着很闲、用户却觉得慢」。 一句话总结：先花半小时测出可并行度 s 和真实瓶颈，再决定加核、升单核性能还是升 I/O；把「每千 QPS 成本」当成唯一分母，选型就不会在「核数越大越安心」上多花冤枉钱。

前面几楼把权限、存储类别、对象名不是目录、碎片与旧版本这些讲得很全了，我补一个很少被提到、但新手上传稍大文件必踩的角度：SDK 的超时/重试参数与分段上传的完整性校验。很多人以为「上传失败=网络断了」，其实是参数没配导致客户端自己放弃了。 一、先分清三个超时，别只改一个。以 Python SDK 为例，常见可配的是连接超时 connect_timeout、读超时 timeout（单次请求）、以及整次上传的总时限。大文件走分段上传时，总耗时可能是单段耗时的几十倍，如果只把单次 timeout 调大而没调 SDK 的重试次数，遇到瞬时 5xx 仍会在第 3 次重试后整体失败。建议按「单段大小 × 并发数 ÷ 实测带宽」估总时间，再把总时限留 2~3 倍余量，重试上限设 3~5 次并启用指数退避（例如 1s/2s/4s 加抖动），避免弱网下所有分段一起重试形成请求风暴。 二、分段上传一定要留两样东西：分段清单和校验值。SDK 一般会在本地（或你指定的 checkpoint 文件）记录 uploadId 与已完成的 part 编号/ETag。断点续传依赖这个文件，删了就只能重新传；更麻烦的是「传完了但没调 complete」，服务端会留下一堆未完成分段继续计费。所以代码里要显式做三件事：① 上传前校验源文件大小与最后修改时间，变了就丢弃旧 checkpoint 重新起 uploadId；② 每个 part 记录服务端返回的 ETag，complete 时按编号顺序提交；③ finally 里捕获异常，失败且确定不再续传时主动 abort 清理分段。可以用 obsutil 的 ls /api 或 SDK 的 listParts 定期扫一次超过 24 小时的 uploadId 做兜底清理，再配一条生命周期规则自动删除未完成分段（比如 1 天），双保险。 三、内容完整性别只靠「没报错」。分段上传的 ETag 通常不是整个文件的 MD5（多段拼接后的 ETag 带段数后缀），直接拿它跟本地 md5 比会误判。可靠的做法是：每个 part 上传时算 CRC64 或 MD5 并随请求带上让服务端校验，合并完成后再用 Content-MD5 或下载回来抽样比对；对关键数据，把「大小 + 最后修改时间 + 每个 part 的 ETag」写进自己的清单文件，作为后续对账依据。 四、并发数不是越大越好。新手常把并发线程调到 32、64，结果在小带宽下每个分段都超时重试，总耗时反而变长、请求次数翻几倍（请求次数也是计费项）。经验起点是并发 4~8、分段 8~16 MB，然后按实测吞吐调整：单段耗时控制在 5~15 秒比较稳，太短说明分段太小、请求开销占比高，太长说明单段失败代价大。 一个最小可运行的结构（示意，具体 API 名以所用 SDK 版本为准）：   cfg = ObsClient(connect_timeout=10, timeout=60, max_retry=3)  parts = []  for i, chunk in enumerate(split_by_size(path, 8*1024*1024), 1):      r = upload_part(bucket, key, upload_id, i, chunk,                      content_md5=md5_b64(chunk))      parts.append({'partNumber': i, 'etag': r.etag})  complete_multipart_upload(bucket, key, upload_id, parts)  # 异常分支：abort_multipart_upload(...) + 记录到待清理清单 五、快速自查顺序：失败时先看是 4xx 还是 5xx/超时——4xx 基本是权限、区域 endpoint、桶名或凭证过期，改参数没用；5xx 与超时才进入重试与分段逻辑排查。把请求 ID（服务端返回的那串）记下来，配合操作时间点找支持方定位会快很多。 一句话总结：OBS 上传的坑一半在「对象模型」，另一半在「客户端怎么把一次上传拆成很多次请求并负责到底」。把超时、重试、checkpoint、分段清理、校验这五件事写进代码模板，比每次出问题临时改配置省事得多。

楼上把权限、对象模型、存储类型和分段上传讲得很全，我补一个几乎没人算过、但账单上最常见的一课：低频/归档存储什么时候反而更贵，以及怎么把请求次数和流量费算清楚。 一、先看最小存储时长。低频和归档通常有最短计费时长（例如低频 30 天、归档 90 天），即使对象只存 3 天就删，也按最短时长计费；归档取回还要额外付取回费并等待恢复。所以「临时文件放低频省点钱」是反的。用一个简单判据：设标准存储单价 s、低频单价 l（元/GB·月）、最短时长 D 天、实际留存 d 天，则低频的真实月成本约为 l × D/30（按 GB 归一）。只有 d ≥ D 且取回次数极少时，l 的单价优势才成立。 二、把请求次数单列。对象存储按请求次数计费，海量小文件场景下请求费会超过容量费。例如每天 200 万次 PUT/GET，即便单价很低，一个月累计也是一笔固定支出。做法是：把大量小对象打包成大文件（或按前缀批量列举代替逐条 HEAD），并给客户端加本地缓存，把「每次都去查一次」改成「查一次缓存一段时间」。 三、外网流出流量是最容易失控的一项。只要从公网下载，出方向流量按量计费；如果客户端与桶不在同区域，还可能叠加跨区域复制或内网跨区费用。同区域 ECS 访问应走内网 Endpoint，既免出网流量也降低延迟；需要对外分发时挂 CDN，让回源只发生一次。做容量估算时用这个式子：月流量费 ≈ 单对象平均大小 × 月下载次数 × 单价，先算再上线，别等账单。 四、生命周期规则要同时管三类对象：过期对象、未完成的分段上传、以及多版本产生的历史版本。开了版本控制却没配「非当前版本过期清理」，删除只是加了一个删除标记，旧版本仍在计费，这是「桶里看着没东西、容量却下不去」的高频原因。 五、给一段可直接改的自检脚本，把三项成本摆在一起看：   gb, days, price_std, price_ia, min_days_ia = 100, 5, 0.099, 0.065, 30  puts, gets, price_per_10k, egress_gb, price_egress = 2000000*30, 500000*30, 0.01, 500, 0.5  cost_std = gb*price_std*days/30  cost_ia = gb*price_ia*max(days,min_days_ia)/30  cost_req = (puts+gets)/10000*price_per_10k  print('标准', round(cost_std,2), '低频', round(cost_ia,2), '请求', round(cost_req,2), '流量', round(egress_gb*price_egress,2)) 把 days 换成自己的真实留存就能看出：短期文件用低频更贵；小文件高频访问时请求费可能比容量费还高。 边界条件：各区域单价、最小存储时长与免费额度不同，上面只是计算框架，实际数值要以所在区域的计费说明为准；另外归档取回有恢复时间，不适合在线读取路径。排查清单：① 确认内网 Endpoint ② 列出未完成分段与历史版本 ③ 统计请求次数分布 ④ 估算月出网流量 ⑤ 再决定哪些前缀该转低频/归档。把这几步做成月度检查，比事后对着账单猜要省事得多。

楼上把「业务画像」和计费方式讲清了，我补一个更容易被忽略的环节：规格对照必须做成可复现的 A/B 实验，否则「感觉够用」往往只是压测没打到位。 一、把负载固定成脚本，而不是手动点。用同一个数据集、同一组并发梯度（如 10/25/50/100/200），每档至少跑 10 分钟并重复 3 次，记录 P50/P95/P99 延迟、吞吐、错误率，以及 CPU、内存、磁盘队列深度、%iowait、出网 PPS。只跑 3 分钟的单次结果几乎必然偏乐观：缓存未热、连接池未扩、JIT 未预热都集中在前几分钟。 二、判据要落在尾延迟而不是平均值。定义一个明确的可接受边界，例如「P95 300ms 且错误率 0.1%」，逐档找最大可承受并发 Q*。常见误区是看 CPU 平均利用率到 60% 就认为还有余量，实际上尾延迟可能早已越线；ρ 接近 0.8 后排队时延会非线性上升，这一步必须用实测曲线确认，不能只靠公式。 三、给一个可复算的性价比指标：单位有效请求成本 = 该规格小时价 / (Q* × 3600)。把每档规格的 Q* 代进去，通常会出现一个明显的拐点——再往上加核，Q* 不再线性增长（瓶颈转到锁、I/O 或外部依赖），此时单位成本反而上升。选拐点前那一档，比选「核数最大」或「单价最低」都稳。可以直接用下面几行算：   price = {'2c4g': 0.35, '4c8g': 0.70, '8c16g': 1.40}  qstar = {'2c4g': 120, '4c8g': 230, '8c16g': 260}  for k in price: print(k, round(price[k]/(qstar[k]*3600)*1e6, 3)) 输出的数值越小越划算；8c16g 的 Q* 只比 4c8g 高 13%，成本却翻倍，说明瓶颈已经不在 CPU。 四、压测客户端本身不能成为瓶颈。用另一台机器发起，确认发压端 CPU 70%、端口与连接池没打满；否则测到的是发压机的上限。同时把磁盘预热、连接池大小、日志级别固化进脚本，换规格时只改一个变量。 五、别忘降配的回退线。上线后取连续 7 天 P95 四条资源曲线，若四条都低于当前规格 40%，再降一档；降配前留镜像，并约定「降配后 P95 劣化 > 20% 立即回退」。 边界条件：以上结论只对被测的那类负载成立。IO 密集型、计算密集型、长连接网关的拐点位置差别很大，业务模型变了就要重跑，不能把一次压测的结论永久复用。排查顺序建议是：固化负载脚本 → 分档重复压测 → 按尾延迟定 Q* → 算单位有效请求成本找拐点 → 上线后按 P95 曲线决定是否降配。

「主账号能用、IAM 用户登录后内置模型消失」，且重新登录无效——这个组合更像是授权范围问题，不是认证失效。建议先做一个三步对照，把问题收敛到具体一层再决定要不要提工单。 一、区分认证失效与授权缺失。认证失效通常是整站跳登录、所有功能一起不可用；如果 IAM 用户能正常进 IDE、能打开项目、只是模型下拉列表为空或调用报权限错，那更可能是「内置模型的可用范围没有覆盖这个 IAM 身份」。用同一浏览器无痕窗口分别登录主账号与该 IAM 用户，对比模型列表；若主账号有、IAM 用户没有，基本可排除本地缓存与登录态。 二、核对 IAM 侧的作用域。逐项检查：该 IAM 用户所属用户组是否被授予 CodeArts/模型相关服务的权限策略；是否受企业项目、区域、组织或部门的资源范围限制（换了区域或企业项目后模型不可见是常见现象）；是否有管理员近期调整过模型授权白名单、配额或灰度开关。平台侧「内置模型」往往与账号类型、开通状态、配额绑定，IAM 子账号不一定自动继承主账号的授权，这一点最容易被忽略。 三、看接口返回码定性。打开浏览器开发者工具的 Network，找到拉取模型列表的请求：返回 403/无权限 → 指向授权与作用域；返回 404 或空数组但 200 → 更可能是灰度/配额/资源未对该身份开通；返回 401/跳登录 → 才是认证问题。把这条请求的状态码和响应体（隐去令牌）随工单附上，研发能省掉一轮来回。 四、排除客户端侧因素。清理 IDE 本地缓存/站点数据、确认插件与 IDE 版本、换一个网络环境；但这些只用于排除干扰，不要把它们当成根因——你已验证过重新登录无效，重复登录不会改变授权结果。 快速验证路径：① 让管理员给该 IAM 用户临时授予与主账号同等的模型相关权限（或直接用主账号在同一环境对照）；② 若授权后模型立即出现，即可确认是权限/作用域配置；③ 若授权后仍为空，带上「主账号与 IAM 用户的对照截图 + 模型列表请求的状态码与响应 + 账号所属企业项目/区域」提工单，定位到服务端开通状态。 顺带一句：IAM 用户的权限调整通常有短暂生效延迟，改完策略后等几分钟再刷新，期间不要反复重新登录，避免把缓存问题和服务端状态混在一起。

「使用一段时间后才报错」这个时间特征很关键，它基本排除了安装/配置类问题，优先怀疑与「时长或累积状态」相关的三类原因。提工单前按下面顺序自查一遍，能把定位效率提高很多。 一、临时凭证或会话过期。CLI 长跑时若使用平台下发的临时 AK/SK + securityToken，过期后往往不是立刻干净地退出，而是在下一次请求时抛鉴权/令牌类错误，看起来就像「跑一阵必现」。记下报错发生的相对时间（例如稳定在第 45 分钟、第 3 小时），若与常见凭证有效期吻合，基本可锁定。验证办法：报错瞬间不要重跑整段任务，只执行一条轻量只读命令看是否同样失败；若重新获取凭证后立刻恢复，即可确认。 二、会话上下文/本地状态膨胀。长会话会把历史对话、工具输出不断累积，超过上下文或本地缓存上限后开始报错；日志目录、临时文件、打开的文件句柄随时间增长也属于这一类。检查点：CLI 的日志与缓存目录体积、进程 fd 数量（macOS/Linux 可用 lsof 看）、是否在跑大型仓库索引。用「新开一个干净会话、只跑同一条命令」做 A/B，如果干净会话不复现，问题就在累积状态而非版本缺陷。 三、长连接被中间设备切断。代理、网关、企业网络常有空闲连接超时；稳定在某段时间后报错且错误含超时/连接重置字样时，抓一下出网链路与代理设置，看看是否走了系统代理、是否有 TLS 中间证书。 提工单时建议附一份最小复现包，研发能一次定位：① 完整版本号与安装方式；② 触发报错的完整命令行（隐去密钥）；③ 完整错误堆栈原文，不要截图裁剪；④ 从启动到报错的准确时长、是否可稳定复现；⑤ CLI 日志文件路径与报错前后各 50 行；⑥ 干净会话/新凭证下是否复现的 A/B 结论；⑦ 操作系统、网络环境（是否代理）。 临时绕过：给长任务加「凭证到期前主动刷新」与「分段提交 + 定期新开会话」，并在脚本里对鉴权类错误做一次刷新后重试，不要盲目无限重试。另外建议把单次任务拆到凭证有效期以内，先让流程能稳定跑完，再等版本修复。

补一个大家很少提、但线上最容易花钱又最难查的角度：大文件分段上传的幂等与完整性，而不是权限配置那一类。 一、残留的分段上传任务会持续计费且不可见。分段上传要先初始化拿到 uploadId，中途网络断了、进程被杀了，若没有显式中止或配置生命周期规则去清理，已上传的分片会一直占存储。表现是「桶里看不到几个对象，账单却一直涨」。做法：列出桶内所有未完成的 multipart upload，按初始化时间设一个阈值（如超过 24 小时）批量中止，并在桶上配一条「清理未完成分段上传」的生命周期规则兜底。 二、ETag 不等于文件 MD5。单对象直传时 ETag 常是内容 MD5，但分段上传的 ETag 是「各分段 MD5 拼接后再算 MD5」并带分段数后缀，直接拿它跟本地 md5sum 比对会永远不相等，误判成「上传损坏」。做完整性校验要用 SDK 提供的 CRC64/校验和字段，或在上传时自己记录每个分段的校验值并逐段核对，别用单个 ETag 跨模式比较。 三、断点续传必须复用同一个 uploadId 和分段编号。重跑时若重新初始化，等于另起一份上传，旧分片变成垃圾；若分段编号与大小不一致（除最后一段外，每段应等长），合并会失败。建议把 uploadId、桶名、对象名、已上传分段号列表持久化到本地小状态文件，进程重启后先读它再决定续传还是新开。 四、并发分段数不是越大越好。分片太多会放大请求次数与失败重试成本，分片太大又让单次失败重传代价高；常见做法是 8~16 MiB 一段、并发 4~8，并对每个分段单独做「超时 + 指数退避 + 抖动」重试，而不是整文件重来。 五、把 503 SlowDown 当成正常反馈。高并发下服务端会主动限流，正确响应是退避重试并降低并发，而不是立刻加大重试次数把它打成雪崩。同时给上传任务设置最长生命周期和告警，避免僵死任务长期挂着重试。 最小自检：传一个 200 MiB 文件，中途 kill 一次进程 → 检查未完成分段列表是否有残留 → 续传后逐段校验 CRC64 → 确认账单里没有「看不见的占用」。把这四步跑通，比背十条配置项更能避坑。

把「平衡」换算成一个可比的分母，比按核数拍脑袋稳得多：单位有效工作成本 C_eff = 月费 / (实际利用率 × 有效吞吐)。同样的 4 核，若业务是 IO 等待型，CPU 利用率长期 20%，分子里的钱几乎全花在空转上，这时加核不如先治 I/O 或改并发模型。 一、先定约束，再定规格。把 SLA 写成可测的尾延迟，例如「P95 300 ms、峰值 QPS = Q」。用排队论估最小并发服务台数：在 M/M/c 下，利用率 ρ = λ/(c·μ) 超过 0.7~0.8 后排队时延会非线性上升，所以宁可留 20%~30% 余量，也别把平均利用率当目标。压测时记录 P50/P95/P99 与 %iowait、%steal，而不是只看 CPU 总利用率平均值。 二、警惕「突发性能」规格的积分耗尽。部分入门规格靠 CPU 积分提供短时高性能，连续高负载几十分钟后会回落到基线，表现为「刚开机很快、跑一阵就慢」。若负载是持续的，选性能稳定的规格族；判断方法是压测 30~60 分钟画吞吐曲线，看后段是否出现台阶式下跌，而不是只跑 3 分钟。 三、用盈亏平衡时长选计费方式。设包月价 M、按需单价 p（元/小时），则 t* = M/p：每月稳定运行时长超过 t* 就包月，波动/批处理型低于 t* 用按需或竞价更省。再把升降配的停机成本、快照与数据迁移成本算进去，别只比单价。 四、降配要有统计判据。取连续 7 天的 P95 CPU、内存、磁盘 IOPS、出网 PPS 四条曲线，若四条 P95 都低于当前规格的 40%，且峰值持续时间 5 分钟，才有把握降一档；降配前留一个可回退的镜像/自定义规格快照，并设好回退线（如降配后 P95 尾延迟劣化 > 20% 立即回退）。 五、一个容易漏的点：跨可用区/跨区内网流量与公网出方向带宽常比规格本身更贵，做 TCO 时把这几项单列，别让「规格省了 30%」被流量费吃回去。 排查清单：① 先量 P95 尾延迟与四条资源曲线 → ② 压测 60 分钟排查积分/降频 → ③ 算 t* 定计费 → ④ 按 40% 判据降配并留回退 → ⑤ 复核流量与存储费用。这样得到的规格是可复算、可回退的，不是一次性拍板。

Windows 下证书自动化真正难的不是签发，是「绑定切换不中断」和「别把 ACME 限额打爆」。补两个在生产上最容易翻车的点，附可直接改的 PowerShell 片段。 一、先做幂等，别让定时任务每次都重签。ACME 侧对同一注册域名有签发频率限制（常见是每域名每周 50 张证书、重复证书每周 5 张，具体以 CA 文档为准），如果计划任务失败后无条件重试，很容易触发限制，导致真到续期窗口时签不出来。做法是先比对现有证书指纹与到期日，只有剩余有效期小于阈值（例如 21 天）才进入签发：$thumb = (Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like '*example.com*' } | Sort-Object NotAfter -Descending | Select-Object -First 1).Thumbprint$days = ((Get-ChildItem Cert:\LocalMachine\My | Where-Object Thumbprint -eq $thumb).NotAfter - (Get-Date)).Daysif ($days -gt 21) { Write-Host 'skip, still valid'; exit 0 }同时把上次成功状态写到文件里做去重键，避免同一天内多次触发。 二、绑定切换要可回滚。签发成功后先把新证书导入 LocalMachine\My，再改 IIS 绑定，最后验证 HTTPS 握手；任一步失败都把绑定指回旧指纹：$old = (Get-WebBinding -Name 'Default Web Site' -Protocol https).certificateHashtry {  Import-PfxCertificate -FilePath .\new.pfx -CertStoreLocation Cert:\LocalMachine\My -Password $pwd  $new = (Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotBefore -Descending | Select-Object -First 1).Thumbprint  (Get-WebBinding -Name 'Default Web Site' -Protocol https).AddSslCertificate($new, 'My')  $r = Invoke-WebRequest https://example.com -UseBasicParsing -TimeoutSec 10  if ($r.StatusCode -ne 200) { throw 'handshake check failed' }} catch {  (Get-WebBinding -Name 'Default Web Site' -Protocol https).AddSslCertificate($old, 'My')  throw}注意 AddSslCertificate 需要管理员权限，且计划任务运行账户要能读取新证书的私钥，否则会出现「绑定成功但握手失败」——这是最隐蔽的一类故障。 三、失败退避与告警：重试间隔用指数退避（5min / 30min / 2h），并在连续三次失败后发通知，而不是无限重试打爆限额。 四、边界条件：① 多域名/SNI 站点要逐个绑定处理，不能只改默认站点；② 中间证书链缺失时浏览器能过、部分客户端不行，导入 PFX 时要带完整链；③ 证书导入 Machine 存储后，应用池身份可能读不到私钥，需显式授权；④ 计划任务在 SYSTEM 下运行时，用户级证书存储路径不可用；⑤ 若站点前有网关/CDN 做卸载，IIS 侧换证书不影响外部链路，验证要打到源站。 排查清单：先看剩余有效期 → 比对指纹确认幂等 → 检查 PFX 是否含链与私钥 → 用 AddSslCertificate 原子切换并留旧指纹 → 强制走一次真实 HTTPS 握手 → 失败回滚并退避告警。把「旧指纹」保存下来，是这套流程里最值钱的一行。

新手最常见的隐性成本不在上传，而在存储类型选错和生命周期规则没配：低频/归档看着便宜，取回费和最小存储时长常常把账吃回去。给一个能直接代入的成本模型。 一、四类存储的关键差异（以控制台展示为准，数值随区域变化，重点是结构）：标准（无最小存储时长、无取回费）、低频访问（最小 30 天、按取回量收费）、归档（最小 90 天、需先 restore、分钟~小时级）、深度归档（最小 180 天、小时级）。提前删除或转类型，仍按最小时长计费。 二、成本模型。设 S 为平均存量 GB、t 为存放天数、c_s 为单位存储价（元/GB/月）、R 为取回量 GB、c_r 为取回单价、N 为请求次数、c_n 为千次请求价、E 为外网流出 GB、c_e 为流量单价：C_total = S·c_s·t/30 + R·c_r + N·c_n/1000 + E·c_e低频划算的条件是把「省下的存储费」与「多出的取回费」比：S·(c_std - c_low)·t/30 > R·c_r + ΔN·c_n/1000整理出临界存放天数 t* = 30·(R·c_r + ΔN·c_n/1000) / (S·(c_std - c_low))。只有 t > max(t*, 最小存储时长) 才值得下沉。举例：S=1000GB、c_std-c_low=0.02 元/GB/月、每月取回 R=200GB、c_r=0.02 元/GB → t* = 30·(4)/20 = 6 天，看着很低，但若取回是全量 R=1000GB，t* 就变成 30 天，正好卡在低频的最小存储时长上，几乎不赚。 三、生命周期规则示例（30 天后转低频、90 天后转归档、365 天后删除，前缀限定避免误伤）：{  "Rules": [{    "ID": "logs-tiering", "Prefix": "logs/", "Status": "Enabled",    "Transitions": [{"Days": 30, "StorageClass": "WARM"}, {"Days": 90, "StorageClass": "COLD"}],    "Expiration": {"Days": 365},    "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}  }]}最后那条 AbortIncompleteMultipartUpload 很关键：分片上传中断后残留的段会一直占容量且不可见，新手最容易在这里莫名付费。 四、边界条件：① 小于 64KB 的小对象按 64KB 计费，海量小文件会显著放大账单，先合并或打包；② LIST/HEAD 也算请求次数，遍历桶做对账时 N 会暴涨；③ 归档对象必须先 restore 才能 GET，restore 有有效期，过期要重做；④ 跨区域复制、外网下载流量单独计费，不在这个公式里；⑤ 生命周期规则是异步执行的，配置后不会立刻生效，别用当天账单验证。 排查清单：先按前缀统计对象大小分布与访问频率 → 用上面的公式算 t* → 检查最小存储时长约束 → 配生命周期 + 残留分片清理 → 一个月后对账账单验证。把「取回率」当成一等指标，比单纯挑便宜的存储类型可靠得多。