ECS 规格选型别只看当前，要按"业务阶段 + 弹性能力"来定很多团队选型时只盯着"现在够用吗"，结果业务一增长就要迁移、扩容，成本反而更高。更合理的思路是：先看业务处于什么阶段，再决定选"一步到位"还是"弹性伸缩"。下面按业务阶段讲选型策略。阶段一：初创/验证期——够用就好，优先弹性业务量不确定、随时可能调整，此时不必追求高配。选通用型入门规格（如 2C4G/4C8G），配合按需计费，验证业务模型。关键是把架构做成可水平扩展：无状态服务 + 负载均衡，后期加机器即可，而不是靠单机堆配置。数据层单独规划，数据库不要和应用抢同一台机器，避免后期拆不动。阶段二：成长期——按瓶颈定规格，配合弹性伸缩此时流量开始有波动，先通过监控找出瓶颈维度（CPU/内存/IO/网络），针对性提升对应规格，而不是盲目全面加配。开启弹性伸缩（AS）：设定基于 CPU 或 QPS 的伸缩策略，平时保持基线实例，高峰期自动扩容，低谷自动缩容。这比"按峰值常备"省钱得多。把无状态服务做成可快速启动的镜像，伸缩才能秒级生效。阶段三：稳定期——分层计费，压降单位成本负载稳定后，把长期运行的核心实例改为包年包月，单价显著低于按需。把可中断的任务（离线计算、CI 构建、批处理）迁到竞价实例，进一步降低成本。定期做规格重评估：用 P95 利用率判断是否配置过剩，逐步降配或合并低负载实例。选型时的三个关键判断瓶颈在哪：CPU 密集选计算型、内存密集选内存型、IO 密集选高 IOPS 存储型，通用场景选通用型。先定位瓶颈，再选族。能否水平扩展：能水平扩展的服务，单机规格不必很大，靠数量取胜；不能水平扩展的（如单主数据库），才需要在单机规格上留足余量。计费方式匹配负载：稳态用包年包月、波动用按需 + 弹性伸缩、可中断用竞价，三者组合而不是单一方式。常见误区按"最大并发"选型：应按 P95 峰值 + 弹性能力估算，为理论最大值常备资源是巨大浪费。只看 vCPU 数量不看实例族：同 vCPU 不同族的性能和价格差异很大。不做压测：选型后必须用真实流量模型压测验证，参数表不等于实际表现。忽略网络和 PPS：小包高频服务可能先撞 PPS 上限，而不是带宽。一句话：选型要跟着业务阶段走——验证期够用优先弹性，成长期按瓶颈 + 弹性伸缩，稳定期分层计费压成本；核心是让架构可水平扩展，而不是靠单机堆配置。

OBS 新手避坑指南：这次从"安全、误删、版本控制"三个最容易出事的角度讲OBS 的坑分几类，前面讲过权限和计费，这次讲最容易造成"数据事故"的三类：误删、覆盖、越权访问。这三类坑的共同点是：平时不显山露水，一旦踩中往往是不可逆的数据损失，比性能和账单问题严重得多。坑一：没有开版本控制，误删/覆盖无法恢复默认情况下，OBS 删除对象就是真删，覆盖上传就是直接替换旧内容。如果业务误删或被恶意覆盖，没有版本控制就无法找回。建议：对重要桶开启版本控制，每次覆盖都会保留历史版本；再配合生命周期规则清理过期历史版本，避免版本堆积撑爆存储成本。更进一步可以开对象锁定（WORM），防止对象在保留期内被删除或篡改，适合合同、审计日志等合规场景。坑二：桶策略配成公共读写新手为了"方便测试"，把桶策略设成 PublicRead 甚至 PublicReadWrite，结果数据被爬、被篡改，甚至被人用来托管非法内容。正确做法：默认私有，需要公开访问的资源用临时签名 URL 或 CDN + 回源鉴权，而不是把整个桶设为公共。定期用"桶策略检查"或安全基线扫描，排查是否有意外的公共权限。坑三：AK/SK 硬编码或权限过大把永久 AK/SK 写进前端代码、配置文件、Git 仓库，是泄露的高发场景。一旦泄露，攻击者可以用你的账号删库、刷流量。正确做法：服务端用临时凭证（STS），按最小权限授予；前端绝不持有永久密钥；密钥定期轮换。给不同业务分配不同的 IAM 子用户和策略，避免一个密钥拥有全部权限。坑四：忽略跨区域复制与备份单区域存储遇到区域级故障时，数据可能不可用。重要数据建议开启跨区域复制，把数据同步到另一个区域。注意跨区域复制会产生流量费用，要按数据重要性权衡，不是所有桶都需要。坑五：路径设计混乱，后期难以治理对象 key 随意命名（如 1.jpg、test），后期无法按业务、时间、类型做生命周期管理和批量操作。建议用有语义的前缀分层：业务/年/月/日/文件名，便于按前缀配置生命周期、批量删除和权限隔离。安全检查清单重要桶是否开启版本控制？过期版本是否配置生命周期清理？是否有桶被误设为公共读写？AK/SK 是否硬编码？是否使用 STS 临时凭证？权限是否最小化？重要数据是否配置跨区域复制或备份？对象 key 是否按业务维度分层，便于治理？一句话：OBS 的数据安全事故几乎都源于"默认私有被改公共""没开版本控制""密钥硬编码"这三件事。上线前把版本控制、最小权限、STS 这三项做对，能避免绝大多数不可逆损失。

选 FunctionGraph 还是 ECS/容器？用"流量形态"和"运维成本"两个维度做决策问 FunctionGraph 适合什么场景，本质上是在问"什么时候该用它、什么时候不该用它"。最实用的判断方法不是背场景清单，而是看两件事：流量的时间分布和你愿意承担的运维成本。看流量形态：稀疏突发是函数的主场稀疏型（一天只跑几次、每次几秒到几分钟）：定时报表、定时清理、事件触发的图片处理、消息队列消费。用函数按调用计费，闲置成本几乎为零，这是它最划算的区间。突发型（平时很低、活动时瞬时高）：抢购、营销活动、批量导入。函数能快速横向扩展，活动结束自动缩容，不需要为峰值常备机器。稳态高并发（持续高 QPS）：函数单价乘以调用量后往往比包年包月的 ECS/容器贵，而且冷启动会带来延迟抖动。这类应该用容器或 ECS。看运维成本：想"零运维"就选函数函数不需要你管操作系统补丁、扩缩容、高可用部署，平台托管了这些。对于小团队、内部工具、非核心链路，这能省掉大量运维投入。但代价是"可控性变弱"：不能自定义内核、不能常驻进程、本地磁盘不持久、单次执行有时长上限（通常 15 分钟）。需要深度定制的场景反而更麻烦。典型正面案例OBS 上传触发图片压缩/水印：事件驱动、短时、无状态，完美契合。每天凌晨跑一次数据对账并生成报表：定时触发，闲置零成本。接收第三方 Webhook 并转发到内部系统：低频、轻量、无需常驻。日志文件到达后做 ETL 清洗入库：事件驱动、可并行拆分。典型反例（别硬用）WebSocket 长连接服务：函数实例随时回收，连接会断。需要本地缓存大量状态的服务：函数实例不保证复用，状态必须外置。持续数小时的计算任务：超出执行时长上限，且成本不划算。对 P99 延迟极敏感的实时接口：冷启动抖动难以彻底消除。决策清单流量是否"来一下就走"？是 → 倾向函数。是否能接受冷启动？不能 → 容器/ECS。是否要求无状态、状态可外置？是 → 函数可行。是否长期稳态高负载？是 → 包年包月 ECS 更省。团队是否希望零运维？是 → 函数省心。一句话：FunctionGraph 适合"稀疏、突发、短时、无状态"的负载；稳态高并发、长连接、长任务、强状态场景应选容器或 ECS。先看流量形态，再算成本，最后评估运维取舍。

df 满了但 du 找不到大文件，通常是"文件被删除但进程还持有句柄"这是运维里非常经典的现象：df -h 显示磁盘使用率 100%，但 du -sh /* 加起来远小于实际占用。原因是有文件被删除了，但仍有进程打开着它——文件在目录树里消失了（du 统计不到），但磁盘块还没释放（df 仍算占用）。第一步：确认是"句柄未释放"还是"隐藏挂载点"用 lsof +L1 列出所有已删除但仍被打开的文件，按大小排序，这就是被"吃掉"的空间。或者 lsof | grep deleted。如果没有 lsof，可以用 find /proc/*/fd -ls 2>/dev/null | grep deleted 找。另一种常见原因：有目录被挂载覆盖（mount 在已有目录上），du 统计的是挂载点内容，而原目录的数据被"藏"起来了。用 df -h 和 du -sh 对比每块盘的差异，再 findmnt 看挂载关系。第二步：处理"已删除但被占用"的文件不要直接 kill 进程（可能影响业务）。正确做法是重启对应服务，让它释放句柄；或者用 truncate -s 0 /proc/PID/fd/FD 清空该文件（对日志类文件最安全）。典型场景：日志文件被 rm 删除，但写日志的进程还开着 fd，日志继续写入"已删除文件"，空间不释放。以后清理日志要用 truncate 或 logrotate，不要直接 rm 正在写的日志。第三步：排除其他隐蔽占用inode 用尽：df -i 看 inode 使用率，inode 满了也会报"空间不足"，但 du 看不出。保留块：ext4 默认给 root 保留 5%，tune2fs -m 可调整，普通用户会提前感知"满"。稀疏文件/预分配：某些数据库或下载工具会预分配大文件，du 显示的是实际块，df 按分配算。排查清单lsof +L1 找已删除但被占用的文件。有则重启服务或 truncate 对应 fd，释放空间。没有则检查挂载覆盖（mount 在已用目录上）。df -i 看 inode。检查保留块和预分配文件。一句话：df 和 du 对不上，先怀疑"删除未释放的句柄"，用 lsof +L1 一查便知；日常清理日志要用 truncate 而不是 rm。

ECS 密钥登录 Permission denied，按"密钥对—权限—服务配置"三层排查这个报错说明 SSH 已经连上了服务器（网络和端口没问题），但在认证阶段被拒绝。问题一定在密钥、文件权限或 sshd 配置上。按下面顺序查，能覆盖 95% 的情况。第一层：密钥对是否匹配本地私钥和服务器 ~/.ssh/authorized_keys 里的公钥是否成对？用 ssh-keygen -y -f 私钥文件 生成公钥，和 authorized_keys 里的内容比对。在控制台绑定密钥对时，如果选择了"创建新密钥对"，会覆盖原有公钥；如果选"使用已有密钥对"，要确认选的是正确的那个。私钥文件权限过宽也会被拒绝：chmod 600 ~/.ssh/id_rsa，并且 ~/.ssh 目录是 700。第二层：服务器端权限和属主~/.ssh 目录权限必须是 700，authorized_keys 必须是 600，且属主是登录用户。如果属主是 root 但用普通用户登录，sshd 会因 StrictModes 拒绝。用 chown -R 用户:用户 ~/.ssh 修正。用户 home 目录权限也不能是 777（组或其他用户可写），否则 StrictModes 会拒绝。第三层：sshd 配置和登录用户确认 /etc/ssh/sshd_config 中 PubkeyAuthentication yes、AuthorizedKeysFile .ssh/authorized_keys 没被注释或改错。确认登录的用户允许 SSH（AllowUsers / DenyUsers）。修改配置后要 systemctl restart sshd（注意别把自己锁在外面，先保留一个会话）。用 ssh -vvv user@ip 看详细日志，重点看 "Offering public key" 后服务端是否接受，以及 /var/log/secure（或 auth.log）里的拒绝原因。密码登录也被拒绝检查 PasswordAuthentication no 是否被设置（很多镜像默认关闭密码登录）。检查是否被 fail2ban 等工具封禁了 IP。检查用户是否被锁定（passwd -S 用户）或 shell 是否为 /sbin/nologin。排查清单本地私钥权限 600，~/.ssh 700。本地公钥与 authorized_keys 匹配。服务器 ~/.ssh 700、authorized_keys 600、属主正确、home 不可写。sshd_config 开启 PubkeyAuthentication。用 ssh -vvv 和服务端日志定位具体拒绝原因。一句话：Permission denied 99% 是权限或密钥不匹配，先用 ssh -vvv 看服务端在哪一步拒绝，再对症修正属主和权限。

Too many connections 的排查顺序：先看是谁占满了，再决定是扩容还是治本这个报错的直接含义是：当前连接数达到了 max_connections 上限，新的连接被拒绝。但"加 max_connections"往往只是拖延，必须按下面顺序先定位谁在占用。第一步：确认当前连接数和上限SHOW VARIABLES LIKE 'max_connections'; 看上限。SHOW STATUS LIKE 'Threads_connected'; 看当前连接数。SHOW STATUS LIKE 'Max_used_connections'; 看历史峰值，判断是突然打满还是长期逼近。SHOW STATUS LIKE 'Aborted_connects'; 看被拒绝的连接数。第二步：按来源分类，找出"谁"占满了用 SELECT user, host, COUNT(*) FROM information_schema.processlist GROUP BY user, host ORDER BY 3 DESC; 看是哪个用户/来源占最多。用 SELECT command, state, COUNT(*) FROM information_schema.processlist GROUP BY command, state; 看是 Sleep（空闲连接堆积）还是 Query（慢查询堆积）。如果是 Sleep 大量堆积：应用没正确关闭连接，或者连接池配置过大。查应用连接池的 maxPoolSize、idleTimeout、maxLifetime。如果是 Query 堆积：慢查询或锁等待。用 SHOW FULL PROCESSLIST 找长时间运行的 SQL，再看 SHOW ENGINE INNODB STATUS 的锁等待。第三步：区分"连接泄漏"和"连接池配置不当"连接泄漏：应用借了连接没还（异常分支没 close）。表现为连接数只增不减，重启应用后短暂恢复。连接池过大：每个应用实例配了很大的池，实例一多就超限。计算方式：总连接数 = 实例数 × 每实例池大小，要留出管理连接和运维连接的余量。排查泄漏可以用 SHOW PROCESSLIST 看 Sleep 连接的 Time 是否持续增长，结合应用日志定位未关闭的代码路径。第四步：应急与治本应急：临时提高 max_connections（注意内存，每个连接有开销），或 kill 掉明显的空闲/异常连接（KILL ）。治本：修复连接泄漏、合理设置连接池（池大小、空闲回收、最大生命周期）、加慢查询治理、必要时引入连接池代理（如 ProxySQL）做连接复用。排查清单看 Threads_connected / max_connections / Max_used_connections。按 user/host/command 分组看谁占最多。区分 Sleep 堆积 vs Query 堆积。Sleep 堆积查连接池和泄漏；Query 堆积查慢 SQL 和锁。应急提上限或 kill 连接，治本修泄漏和池配置。一句话：Too many connections 不是"上限太小"，而是"有人在浪费连接"，先找到浪费的源头再决定扩容。

换个角度说 OBS：这次从"性能与计费"侧列几个新手最容易踩、且踩了要花钱的坑上一类回答多讲权限和访问，这次讲性能和账单，因为这两类坑的共同特点是：功能能跑、代码没报错，但上线后要么慢得离谱，要么账单超预期，而且很多是配置层面的默认值导致的，改一行配置就能解决。坑一：不理解"外网下行流量"和"请求次数"是分开计费的OBS 的计费至少包含：存储容量、请求次数（按 API 调用量，PUT/GET/LIST 等）、流量（外网下行流量、跨区复制流量、CDN 回源流量等）。新手常只盯着存储费，结果请求次数和外网流量费用反超。高频小文件读写（比如每秒大量 GET 探测）会先把请求次数费用打上去；对外提供下载会先撞外网下行流量费。要省这块，接入 CDN 回源，或者把高频小文件合并、加缓存。内网访问（同区域 ECS 访问 OBS）通常不产生外网下行流量费，跨区域或公网访问才会。架构上尽量让计算和存储同区域部署，流量费能省一大块。坑二：海量小文件直接怼，元数据操作拖垮性能OBS 对"大量小文件"场景优化有限：每个对象都有元数据开销，LIST 操作也按对象数量计费和限流。几十万级小文件时，LIST、批量删除、同步都会明显变慢。优化手段：按业务维度做目录前缀分层（如 year=2026/month=11/day=06/），避免全桶 LIST；批量处理用异步任务；能合并的日志类数据先压缩再上传；用生命周期规则定期归档或删除过期对象，控制对象总量。如果业务确实需要海量小文件高并发访问，考虑用并行文件系统或本地缓存 + 定期同步到 OBS 的架构，而不是让业务直接依赖 OBS 做高频随机小文件访问。坑三：分片上传的分片大小没算对单个对象分段上传最多 10000 片。大文件用固定小分片会超限，分片过大又影响断点续传的粒度。分片大小应按"对象大小 / 10000 向上取整"来定，再结合失败重传成本选档位（常见 8/16/32/100MB）。并发上传建议控制在 4~8 路，别为了快无限并发，OBS 有请求限流，过量并发反而会触发 429/503，重试放大会拖慢整体。坑四：生命周期规则配了但没生效生命周期规则是按天粒度扫描的，配置后不会立即生效，且规则有优先级：多条规则命中同一对象时，较早到期或更具体的规则优先。新手常配了"30天转归档"，结果发现文件还在标准存储，是因为规则前缀写错或者对象有保护策略。建议：配置后用控制台或 API 检查规则状态，明确规则 ID、前缀、转换/过期动作和时间，避免"看起来配了其实没命中"。排查建议：先用 OBS 的用量统计和账单分析，找出成本大头（容量/请求/流量），再针对最大项优化；性能问题先用 OBS 的访问日志定位是 GET 慢、LIST 慢还是上传慢，再对症下药。一句话：OBS 的坑一半在权限，一半在"默认配置"——计费方式、分片策略、生命周期规则这些默认值不适合所有业务，上线前按业务画像调一遍，能省下大量排查和账单费用。

规格选型的核心不是"选多大的"，而是先把业务的资源画像画出来云服务器选型最常见的错误是"先看价格再选机型"，结果要么性能不够背锅，要么配置过剩浪费。正确顺序是：先量化业务画像（CPU 密集？内存密集？IO 密集？网络密集？），再按画像匹配实例族，最后用计费方式优化成本。下面按这个顺序讲。第一步：给业务画资源画像CPU 型：编译、渲染、高并发计算，CPU 持续占用高，内存需求一般。这类选计算优化型（c 系列）。内存型：缓存（Redis/内存数据库）、大数据聚合、JVM 大堆应用。选内存优化型（m 系列），内存/CPU 比通常 1:8 起。通用型：Web 服务、中小数据库、中间件。通用型（s 系列）或通用计算增强型都能覆盖。IO 型：高 IOPS 数据库、日志密集写入。看的是磁盘 IOPS 和吞吐能力，选配高性能云盘或本地盘机型。先跑一段时间的监控（CPU、内存、磁盘 IOPS、网络带宽），拿到 P95 峰值，再放大 30%~50% 余量，而不是按平均值拍脑袋。第二步：按"关键瓶颈"定规格，而不是按综合分大多数业务只有一个真正的瓶颈：Web 服务通常卡在 CPU 或网络，数据库卡在 IOPS 和内存，缓存卡在内存。先解决瓶颈维度，其他维度够用即可。比如一个 Java Web 应用，CPU 峰值 70%、内存只用了 40%，就该加 CPU 而不是加内存；反过来，如果 GC 频繁、内存吃紧但 CPU 有余，就选内存型。别忽视网络带宽和 PPS：小包高频服务（如网关、消息推送）容易先撞 PPS 上限，而不是带宽上限。第三步：用计费方式优化成本包年包月：适合长期稳定运行的生产环境，单价最低，但灵活性差。按需：适合开发测试、临时扩容，随用随付。竞价实例/spot：价格大幅低于按需，但可能被回收，只适合可中断的任务（离线计算、CI 构建）。成本优化不等于一味选低价：频繁出故障导致的业务损失远高于省下的钱。建议生产用包年包月、测试用按需、批处理用竞价，分层组合。常见误区只看单价不看规格族差异：不同实例族同 vCPU 价格差异可能很大，因为它们面向的负载不同。按最大并发估算：应该按 P95 峰值 + 弹性伸缩能力估算，而不是按理论最大值。忽略系统盘和数据盘：系统盘用高效云盘即可，数据盘按 IOPS 需求选，别都用最贵的。不做压测就上线：选型后至少做一次压测验证，用真实流量模型，而不是只看规格参数表。一句话：先用监控数据画出瓶颈画像，再按瓶颈选实例族，最后用计费组合降成本，这套顺序走下来，既不会性能不够，也不会过度配置。

先分清"谁拦了你"：IAM 策略、桶策略、ACL、CORS 四层，排查要逐层过OBS 的访问控制有四层：IAM 策略（账号级）、桶策略（桶级）、ACL（对象/桶级）、CORS（浏览器跨域）。这四层是"与"的关系，任何一层不通过都会报 403，但错误信息往往很模糊，新手容易只盯着其中一层调。按下面顺序排查效率最高。坑一：以为桶策略能覆盖 IAM 策略IAM 策略是账号维度的"总闸"，桶策略是在总闸之下的"分闸"。如果 IAM 策略里根本没有授予该用户 OBS 的访问权限，桶策略写得再宽也用不了。排查：先用主账号在 IAM 控制台确认该子用户/委托账号有 OBS 相关权限（如 OBS OperateAccess），再调桶策略。委托场景（跨账号、委托其他云服务）最容易漏：委托需要显式在桶策略里授权委托账号的 domainId，而不是只授权用户。坑二：ACL 与桶策略互相"打架"OBS 同时支持 ACL 和桶策略。如果桶策略是"拒绝所有人"，ACL 授权的用户也会被拒；反之 ACL 没配好，桶策略允许也可能在对象级别被 ACL 限制。建议：要么统一用桶策略 + IAM，要么统一用 ACL，不要混用。混用后排查成本极高，因为控制台展示的"当前权限"不一定反映实际生效的最终结果。用 obsutil 或 OBS 的"权限诊断"功能，输入具体用户和操作（GetObject/ListBucket），让平台直接算给你最终判定，比人肉推理快得多。对象级 ACL 默认是 private，如果对象是别人上传或者由某服务写入，可能需要重新设置对象 ACL 或依赖桶策略授权。坑三：CORS 配了但没配全浏览器直传/下载时，如果遇到 403 或 CORS error，检查 CORS 规则的 AllowedOrigin 是否包含实际来源（含端口）、AllowedMethod 是否包含实际方法（PUT/POST/HEAD）、AllowedHeader 是否包含前端实际发送的 header（比如 Content-Type、x-amz-meta-*）。常见错误：只配了 GET 没配 PUT；只配了域名没配子域名；漏了 AllowedHeader 的通配。建议先用 * 快速验证，确认链路通了再收紧到具体域名和方法。坑四：临时凭证（STS）过期或权限范围写错用 STS 临时凭证访问时，临时凭证的有效期（通常 15 分钟到 12 小时）过期后会直接 403，且报错不明显。前端要处理 AccessDenied 并重新申请。STS 策略是对申请者权限的"子集"，如果申请的 policy 里 action/resource 写错了，即使源账号有权限也会被拒。排查流程建议确认访问方式：永久 AK/SK、STS、临时 URL（签名 URL）还是匿名。不同方式适用不同的权限链。用 OBS 控制台或 obsutil 的权限诊断，先确认"这个用户对这个桶/对象的 GetObject 到底允许不允许"，避免只看某一个配置页。如果是浏览器场景，再看 CORS 规则。逐层收紧：先验证通，再收窄范围，不要一上来就按最小权限配，容易调不通。一句话：OBS 的 403 不要猜，用平台的权限诊断工具算出最终结果，再按 IAM、桶策略、ACL、CORS 的顺序定位，比在四个配置页之间反复改快一个数量级。

一句话结论：新手踩 OBS 的坑，根因几乎都是"把对象存储当成本地文件系统"。下面按区域与端点、权限、对象键、上传、浏览器直传、计费、错误码七类给出高频坑和对应做法。一、区域与 Endpoint：先搞对"从哪访问"桶创建后区域不能改。选错区域只能重建桶并迁移数据，规划时先定区域。桶名全局唯一，被占用就换名；命名只能用字母、数字、中划线，长度 3~63。Endpoint 选错会产生流量费：同区域 ECS 访问用内网 Endpoint（obs..myhuaweicloud.com），走内网免流量费；用公网 Endpoint 则按流量计费。本地开发用公网 Endpoint 正常，但要意识到费用。二、权限：403 的排查顺序OBS 的权限是桶策略、IAM 权限、对象 ACL、防盗链、签名多层叠加，403 要逐层看，只看一处会漏：桶默认私有。为了"链接能打开"把桶设成公共读，是最危险的坑——一旦桶里有日志、备份、用户上传件，等于全量泄露。对外分享单个文件用带过期时间的临时签名 URL。AK/SK 绝不能写进前端代码或公开仓库；给应用长期访问用 IAM 最小权限账号或委托，并定期轮换。排查 403 的顺序：签名是否过期/时钟是否同步 → 桶策略是否显式 Deny → IAM 策略是否授权 → 对象 ACL → 防盗链 Referer 白名单。三、对象键与"伪目录"OBS 是扁平的键值存储，没有真正的目录，"文件夹"只是对象键的前缀（如 logs/2026/11/a.log）。按前缀批量删除时务必确认前缀范围，logs/ 这种宽前缀很容易误删整批；生产环境建议先 list 预览再删。对象键含中文、空格、特殊字符时，签名和 URL 编码要一致，否则容易出现签名不匹配。四、上传：大文件必须分段单次上传几 GB 的大文件容易超时/中断，要用分段上传（Multipart Upload）：分片建议 8MB 起，总片数不超过 10000；50GB 用 5MB 分片会到 10240 片，Complete 阶段直接失败。上传前/后校验 MD5 / ETag，避免"传上去了但内容不完整"。并发覆盖同一对象时以最后一次写入为准（原子覆盖），不会合并；需要版本保护就开启多版本。五、浏览器直传：CORS 没配会"无响应"前端直传时，浏览器会先发 OPTIONS 预检。桶的 CORS 规则必须配齐：AllowedOrigin（不要图省事写 *）、AllowedMethod（PUT/POST/GET/HEAD）、AllowedHeader（至少 * 或实际用到的头）、ExposeHeader（前端要读 ETag 就必须暴露它）。没配好时表现为"上传无响应/失败"，而不是服务端报错，很难查。六、计费：三个容易漏的点存储类别：标准、低频、归档的最短存储时长和取回费用不同；归档文件当热数据频繁读，取回费用可能比存储费还高。多版本删除标记：开了多版本后，普通删除只产生删除标记，历史版本仍占空间、仍计费；要单独配版本生命周期清理。请求次数与流量：高频 list、跨区域复制、公网下行都单独计费；临时文件、日志务必配生命周期规则自动转冷或删除。七、常见错误码对照403 AccessDenied：权限/桶策略/ACL 不允许。403 SignatureDoesNotMatch：AK/SK 错、签名算法或编码不一致。403 RequestTimeTooSkewed：客户端时钟偏差过大，校时即可。404 NoSuchBucket / NoSuchKey：桶名或对象键写错、区域选错（跨区域会返回 301）。301 PermanentRedirect：Endpoint 区域与桶所在区域不一致。400 InvalidBucketName：桶名不符合命名规则。建议：上线前先在测试桶把权限、Endpoint、CORS、生命周期、分段上传跑通，再切生产；排查时用 obsutil 或 curl -v 看完整请求和响应头，比凭感觉猜快得多。