针对「云服务器规格选型时，如何平衡成本与性能？」，前面几楼把画像、压测、系列选择讲得很全了，我补一个更靠前的步骤：先把「可并行度」量出来，再决定加核还是升单核性能，否则很容易花双倍钱换来几乎不变的吞吐。一、用 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 倍，加核才划算。所以该先估 s，而不是先看「几核才安心」。二、s 怎么测，成本很低。固定输入，只改并发 worker 数，跑真实业务而不是空转 benchmark，记录吞吐 Q(n) 与 P95。取 n=1 与 n=4 两组数据就能反推 s：由 Q(4)/Q(1)=1/(s+(1-s)/4) 解出 s，再用 n=8 的实测值验证预测。若实际明显低于预测，说明还叠了锁竞争、共享连接、磁盘或网卡瓶颈，不是纯并行度问题。三、瓶颈不在 CPU 时，三个高频信号能直接定位。① CPU 利用率不高但吞吐上不去、iowait 明显 → 先查云盘 IOPS/吞吐是否已到该盘型规格上限，加核无用，要升盘型或改批量写；② 单核跑满其余核空闲（top 里 1 核 100%）→ 典型串行段或单线程程序，要么拆任务，要么选主频更高的新代系列，别买更多核；③ PPS/带宽到顶（sar -n DEV 看 pps、云监控看出网带宽），小包场景常先撞的是网卡 PPS 基线而不是 CPU。四、把结论写成可复算的表。列上目标 QPS、P95 上限、实测 Q(1)/Q(4)/Q(8)、反推的 s、当前盘 IOPS、峰值出网带宽、月费，以及「单位有效吞吐成本 = 月费 / 实测 QPS」。这样规格变更前后能直接对比每千 QPS 花了多少钱，比只看 CPU 利用率决定升降档可靠得多——CPU 低不代表没浪费，可能是被 I/O 卡住的空转。五、两个容易忽略的成本项。同规格不同代际的单核性能差异可能超过 20%，选较新系列常常比选更多核便宜；变更规格通常伴随重启，压测要在同可用区、同盘型下做，否则数据不可比。上线后保留一周的 P50/P95/P99 与资源曲线，用尾延迟而不是平均利用率作为升档触发条件，能避免「平均看着很闲、用户却觉得慢」。一句话：先花半小时测出可并行度 s 与真实瓶颈，再决定加核、升单核性能还是升 I/O；把「每千 QPS 成本」当唯一分母，选型就不会在「核数越大越安心」上多花钱。

结论：选型不是“选多大”，而是先把瓶颈量化成四项数字（CPU、内存、IOPS、带宽），再拿数字去匹配规格系列；只按核数挑，十有八九买错——要么浪费一半，要么一压测就顶满。一、先量，再选打开云监控 CES，把 CPU 使用率、内存使用率、磁盘读写速率、公网出带宽这条时间线拉够 7~30 天，取 P95 而不是平均值，也不要只盯瞬时峰值。Linux 上补三条命令交叉验证：vmstat 1 看上下文切换和 CPU 队列、iostat -x 1 看 %util 与 await、sar -n DEV 1 看带宽是否打满。二、四项需求各自的估算口径CPU：峰值 QPS × 单请求 CPU 秒数 ÷ 目标利用率。Web 取 60%，计算密集取 70%，留出的是突发余量。内存：常驻 RSS + 缓存 + 30% 余量。数据库场景先把 innodb_buffer_pool_size 这类缓存算进去，别按进程 RSS 拍脑袋。IOPS：看 iostat 的 r/s + w/s 与 await。如果 %util 长期接近 100 而 CPU 只有 30%，瓶颈在云硬盘，升 CPU 纯粹浪费。带宽：峰值字节/秒 × 8 ÷ 1,000,000 × 1.3。视频、下载类业务这一项经常先顶满。三、规格系列跟着“先顶满的那一项”走通用型适合 Web 与轻后端，计算型适合转码和批处理，内存型适合数据库与缓存。突发性能型只适合平均负载低、能接受积分耗尽后限速的场景，把它当主力跑在线服务，高峰期会以故障的形式把省下的钱还回去。具体可选代际和规格上限以控制台规格页为准，不要照着旧文章选。四、验证与降档按估算向下取一档开按需实例，用真实流量或压测打到峰值的 1.2 倍，看 P95 延迟、CPU 是否长期高于 70%、内存是否高于 80%。不达标升一档；连续 4 周 P95 CPU 低于 20% 且延迟达标，就降一档。改配通常需要关机，先确认停机窗口再做。五、成本侧的三个常用手法稳定基线用包年包月锁定价格，峰谷明显的部分交给弹性伸缩，临时环境用按需并在夜间关机。架构上先把数据库从应用机里拆出去，很多“性能不够”其实是单机什么都跑，拆完规格自然不用买大。一句话：先量化瓶颈、再按瓶颈选系列、最后用小一档加 1.2 倍压测验证，成本与性能就不用在下单那一刻一次赌对。

前面几楼把建桶、上传、分享、删除四段讲得比较全了。我补一个从运维视角出发的清单：OBS 的坑绝大多数不在“不会用”，而在“配错了却当场不报错”，等到出账单或出事才暴露。下面按“配错也不报错”的顺序排。一、权限：最容易“配通了但不安全”1. 桶策略和 IAM 策略是两套东西，取并集生效。只删 IAM 策略、桶策略里还留着公共读，桶依旧是公开的。核查顺序：先看桶的“访问权限”是不是私有，再看桶策略有没有 Principal 为 * 的 GetObject。2. 给临时授权别改桶策略，用预签名 URL。签名里的有效期从几分钟到几天，别签一年；一旦签出去就无法撤销，只能等过期。3. AK/SK 不要写进前端、不要提交进 Git 仓库。最小权限做法是给应用单独建 IAM 用户，只授 obs:object:GetObject / PutObject 这类动作，并限定 Resource 到具体桶路径。二、上传：几个静默失败点1. 对象键里的中文、空格、特殊字符要 URL 编码，否则 SDK 报签名不匹配（SignatureDoesNotMatch），而控制台里上传同样的名字却是成功的——这两种路径签名算法不同，很容易误判成“SDK 有问题”。2. 大文件走分段上传时，中断后残留的分段会上传占用存储并计费，桶里还看不到对象。用 obsutil 的断点续传，并配生命周期规则“删除未完成的分段上传”，天数设成 7 天即可。3. 同名覆盖是默认行为，且不可恢复。要防误覆盖就开版本控制；开了版本控制后“删除”只是加删除标记，空间还在，清理要显式删历史版本。三、访问与域名1. 静态网站托管的桶必须把访问权限设为公共读，否则访问域名一律 403。这里的顺序是：先开静态托管，再放公共读，最后绑域名。2. 自定义域名要 CNAME 到桶的访问域名，且域名需已备案；证书要传到 CDN 或桶上，直接 http 访问会被浏览器拦。3. 浏览器直传（前端上传）必须配 CORS，且 AllowedOrigin 不要写 *；预检请求 OPTIONS 失败时控制台只会看到 net::ERR_FAILED，实际原因在 CORS 规则没放行 HEAD/POST。四、计费：账单涨了但存储没涨，通常是这三项1. 请求次数费。小文件高频读写（如每次请求都去读一个配置 JSON）很容易把请求费刷上去，这类配置应该本地缓存或放 Redis。2. 流量费。同区域内 ECS 访问 OBS 走内网 endpoint（obs..myhuaweicloud.com）不计流量费，走公网 endpoint 才计费。这条写错一次，账单可能翻几倍。3. 跨区域复制与 CDN 回源单独计费，不包含在存储费里。五、上线前的最小验收清单①用未登录的浏览器访问对象 URL，应该是 403；②用预签名 URL 访问，应该是 200 且到期后变 403；③用 obsutil 传一个 200MB 文件并中断一次，续传后 md5 一致；④跑一遍“删桶→报错（非空）→清空→再删”，确认自己知道怎么清历史版本；⑤在费用中心把存储、请求、流量三项都指认出来。五条都过，再放生产数据。

补几个「不报错但结果不对」的坑，这几个比权限和计费更容易到上线才炸。 一、浏览器直传报 CORS，不是权限问题。后端 SDK 上传正常、前端 PUT 报「No Access-Control-Allow-Origin」，几乎都是桶未配 CORS 规则，或规则里 AllowedMethod/AllowedHeader 没列全。排查顺序：先看 Network 面板里那条预检 OPTIONS 的响应头，有没有 Access-Control-Allow-Origin；有就再看请求带的自定义头是否在 AllowedHeader 里。别先动桶策略。 二、签名 URL 403 的四个固定原因。①本机时间偏差超过 15 分钟；②签名方法版本与 SDK 不一致（V2/V4 混用）；③bucket 与 region 和 endpoint 不匹配（跨区访问会签名失败而不是 404）；④URL 里的中文、空格、加号没做编码。按这四条顺序核，比重新生成密钥快。 三、分片上传中断会留下「看不见的费用」。大文件走分片上传后客户端崩溃或取消，未合并的分片既不出现在对象列表，也一直计费。定期枚举未完成的分片上传任务并配生命周期规则清理：tasks = client.listMultipartUploads(bucket)for t in tasks: if time.time() - t.initiated > 3*86400: client.abortMultipartUpload(bucket, t.key, t.uploadId)同时给每次上传设幂等键，重试走续传而不是重新起一个 uploadId。 四、「删了对象容量没降」多半是多版本。开启多版本控制后，删除只是插入一个删除标记，历史版本继续占空间；再叠加跨区域复制，过期时间按各自规则独立计算。定位时先列版本再列删除标记，不要只看对象列表。 五、权限问题先画三层关系再改。桶策略 / IAM 策略 / ACL 三层是叠加的，且拒绝优先于允许。同一个「AccessDenied」在三层里都可能产生，逐层验证比直接改成公共读安全得多——公共读一旦被搜索引擎或爬虫发现，下行流量费用会立刻反映在账单上。 最后一条经验：把「桶策略、计费项、CORS」三件事写进上线检查单。OBS 的问题很少是功能不可用，绝大多数是「能用但用错了」。

先说结论：这类平台大多不是“抓不到”，而是你拿到的是「没执行的页面外壳」或者「被反爬策略挡在了几个特定环节」，两者排查方向完全不同。一、先分清是哪种失败1. 返回 200 但 HTML 里没有数据：内容由 XHR/fetch 异步加载，甚至是流式渲染。requests 只拿到首屏骨架，要另找那个 JSON 接口。2. 返回 403 / 429 / 空 body：这是被识别成爬虫。TikTok 和 Facebook 都校验请求指纹，不只看 UA。3. 返回的是验证页 / 登录墙：典型如 cookie 缺失、地域限制，或者账号未登录。4. 能拿到但字段不全：懒加载或分页未触发。二、几个具体原因1. 请求指纹比 UA 复杂得多。TLS 指纹（JA3/JA4）、HTTP/2 帧顺序、header 顺序都会被比对。requests 的 TLS 特征与真实 Chrome 明显不同，因此单改 User-Agent 没用，换成能指定 TLS 指纹的客户端才有意义。2. 动态签名参数。TikTok 网页端有基于 JS 的签名（如 X-Bogus 一类的参数），签名算法随版本变化，且很多依赖浏览器环境变量，脱离浏览器很难稳定复现。这也是为什么纯 requests 即使带了正确 cookie 仍会被拒。3. 内容确实不在首屏。Facebook 的帖子流、TikTok 的列表都是前端拼接，HTML 源里没有正文，必须等 JS 执行或直接找它调用的 GraphQL/API 端点。4. 账号与地域。两家都有强登录态和地域策略，同一份请求在登录态、所在网络环境下结果不同。三、相对稳的做法（按合规优先级）1. 优先用官方途径：平台开放的 API、官方数据导出、授权服务商。能拿到结构化数据，也不会天天因为改版重写。2. 必须走页面时，用真实浏览器渲染：headless 浏览器执行 JS 后再取 DOM，能解决“异步加载”这一类。但要接受它解决不了强指纹+动态签名+登录墙的组合。3. 用登录态与真人会话：带上已登录的 cookie，并控制访问频率，避免高峰时段批量请求。4. 把失败当正常情况设计：重试 + 退避、失败告警、字段缺失标记，而不是让脚本静默产出空表。四、要注意的边界采集前先看平台服务条款与 robots 约定，避免采集个人信息、避开需要授权的数据。高频请求不仅容易被封，也可能违反条款。工程上更划算的方向是“少而准”：只取必要的字段，降低频率，用增量更新代替全量重拉。一句话总结：Facebook / TikTok 抓不下来，多半是 TLS 指纹、动态签名、登录墙三者叠加，纯 HTTP 客户端很难绕过；能长期跑通的方案基本都在“官方接口 > 授权数据 > 浏览器渲染 + 登录态 + 低频”这条线上。

先把这个问题定性清楚：报错里出现「网关策略」「1M 权限」这类字样，说明请求根本没到业务服务，是被平台侧的网关在鉴权阶段拒掉了。所以排查方向不是改代码、不是重装插件，而是确认「谁在拦、拦的是哪个权限项」。一、先分清是哪一类 1M「1M」在内部权限体系里通常是权限项编码，而不是「1MB」这种容量单位。同一段文案一般对应三种完全不同的东西：服务级权限：某个内部服务（这里是 CodeArts 代码智能体）的访问白名单，需要按服务粒度申请；数据级权限：能看到哪些代码仓/项目，属于租户与项目角色的组合；网络级策略：只允许特定网段或特定出口访问，表现为「不在白名单 IP 就一律拒绝」。三者的申请入口和审批人都不一样。判断方法是看报错的 HTTP 状态码：401/403 且响应体里有权限码 → 服务级；403 且提示网段或来源 → 网络级；能进页面但列表为空 → 数据级。二、按这个顺序取证，别一上来就反复重试用浏览器开发者工具看这条请求的完整 URL、状态码、响应头里的 trace id，把 trace id 记下来——找支持时这一段比截图有用得多；换一个已获批的同事账号在同一台机器、同一网络下试一次。他能通你报错 → 账号权限问题；他也报错 → 网关或环境问题，这时申请权限是白申请；同一个账号换一台机器/另一个网络再试。换了机器能通 → 网络级策略（出口 IP 没在白名单）；仍然报错 → 服务级权限；确认客户端拿到的 token 里到底带了哪些 scope。很多「已申请但仍报错」的根因是权限批了、但客户端还是用旧 token，scope 没刷新。三、申请时一次把材料给全建议按这个清单提交，能少来回好几轮：报错原文与截图、trace id、操作入口的完整 URL、账号（工号/域账号）、触发时间（精确到分钟）、用途说明一句话、期望的有效期。审批人最常打回的就是「用途不明」和「没有时间点」，这两项一次写清基本一遍过。四、获批后仍不通，重点查这三处权限生效延迟：多数内部系统是准实时，但缓存 TTL 常见 5–30 分钟，期间重试无意义；token 未刷新：退出重登或重新获取一次凭据，确保 scope 里出现新批的权限项；客户端还是旧配置：有些工具会把权限项写在本地配置或环境变量里，重新批了要同步改。最后一句提醒：这类网关拦截是设计如此，不要用改 hosts、绕代理、换非合规网络的方式去「绕过去」，即使暂时能通，后续审计也会被判定为异常访问，代价远大于等一次审批。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。

前几位都建议「等补货」，判断是对的。我从另一个角度补一下：这类兑换区的问题，核心不在于有没有货，而在于平台没有把「什么时候补、补多少」这个信息给出来，导致用户只能靠反复刷新来试探。三个可以直接落地的改进：把「已售罄」和「已下架」分开。现在两者共用一个词和同一种置灰，用户无法判断「等」有没有意义。前者显示「本轮已兑完」，后者置灰或移出列表。给补货节奏一个粗粒度承诺，比如「每月 1 日补货」。哪怕不精确，也能把「每天刷」变成「定期看」。加一个到货提醒。补货时发一次站内信，实现成本很低，但能消掉绝大部分无效刷新。用户侧目前比较实际的策略：别为了等大额券把积分攥死，小面额有货就先换；把「看库存」和每日签到绑在一起顺手做，不要专门守着；积分如果有有效期，优先换确定能拿到的。一句话：「没库存」不是 bug，但「只告诉用户没库存、不告诉用户然后呢」是体验缺陷。