4楼、8楼、9楼、10楼已经把权限、存储类别、分段上传、版本控制这些大头讲得很全了，我补充几个楼上没细说、但新手同样容易踩的点： 一、同名覆盖后看到的还是旧内容。更新同名对象后，CDN 节点和浏览器缓存里可能还是旧文件，刷新页面也没用。解决办法：上传时按需设置 Cache-Control；或者改名加版本号（如 logo-v2.png）；也可以在 CDN 控制台对该 URL 做刷新。 二、公开图片要防盗链。图片、安装包一旦公开，别人可以直接引用你的链接，流量费算你的。可以在桶的防盗链设置里配 Referer 白名单，只允许自己的域名引用；临时分享仍用前面楼层提到的预签名 URL。 三、静态网站托管别忘了 HTTPS 和错误页。只开公共读、配了索引文档还不够：绑定自定义域名后要在 CDN 或 OBS 侧配好证书，否则浏览器会报不安全；错误文档也要配，不然 404 时用户看到的是默认报错页。 四、重要数据可以开对象锁定。开启合规保留后，保留期内的对象谁都删不掉、改不了，能防误删，也能防勒索软件加密后覆盖原文件。注意：开启前要想清楚保留时长，保留期内自己也删不掉。 五、跨区域复制不是免费的。把桶里的数据复制到另一个区域做容灾时，会产生跨区域流量费和请求费，复制也有延迟；只对真正需要容灾的核心数据开，别给整个桶无差别开。 六、上传后自动处理用事件通知。图片上传后要生成缩略图、视频要转码、文件要审核，别写定时任务去轮询。OBS 支持事件通知，配好后对象上传完成会自动触发函数工作流 FunctionGraph 处理，省事又实时。 七、删桶失败先查版本和碎片。开了版本控制的桶，控制台删对象只会加删除标记，历史版本还在；删桶前要先清理历史版本、删除标记和未完成的分段，否则会提示桶不为空删不掉。

前面几位已经把“先保通道、再分组、再查池”的排查顺序讲得很全了，我不重复，补充一个很多团队真正卡住的环节：连接泄漏在代码里长什么样、以及怎么从数据库侧反推到具体哪段代码。连接数打满的根因，十次有七八次是应用侧在漏连接，而不是数据库太小。 一、先区分两种“漏” 1. 连接借了没还：getConnection 之后异常分支没 close，或者事务没提交、连接一直被持有。2. 池子越用越大：连接池配置本身在涨，比如 maximumPoolSize 配了 200、minimumIdle 也配了 200，或者每次请求都 new 一个连接池实例而不是复用单例。区分方法：看 processlist 里 Sleep 连接的 USER 和 HOST 分布。集中在某一台应用主机、且 TIME 持续增长，大概率是那台机器的代码在漏；各台机器均匀上涨，大概率是池配置问题。 二、四种语言里最常见的漏法（附修复写法） 1. Java：try 块里拿连接，异常分支没关。错误写法是 Connection conn = dataSource.getConnection() 之后在 try 里执行，catch 里直接 return，没在 finally 关。正确写法是 try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ... }，try-with-resources 会保证 close。另外注意：用 Spring 的 @Transactional 时，事务没提交就调远程接口，连接会被整个调用链占着；把远程调用移到事务外面。2. Go：sql.DB 拿了行没关。rows, err := db.Query(...) 之后忘了 rows.Close()，连接会一直挂在结果集上。正确写法是 defer rows.Close() 紧跟在 Query 后面，哪怕后面要 return 也要先 defer。池参数：db.SetMaxOpenConns(50)、db.SetMaxIdleConns(10)、db.SetConnMaxLifetime(5 * time.Minute)，三项都要设，只设第一项不管用。3. Python：SQLAlchemy 的 session 用完没关。with Session() as session: 写法会自动关；手写 session = Session() 之后忘了 session.close()，连接会留在池里不释放。配合 pool_recycle=3600，避免服务端先断开后池里留死连接。4. Node.js：mysql2 的连接池不要每次请求都 createPool。createPool 应当在模块顶层做一次、全局复用；写在请求处理函数里等于每次请求新建一个池，连接数随请求量线性增长。用完连接要 connection.release()，不是 destroy()。 三、从数据库侧反推到代码 光看连接数不够，要把连接和代码对应起来：第一，processlist 里按 HOST 分组，先锁定是哪台应用主机；第二，同一主机的连接如果 DB 相同、TIME 都很大，先看这台机器上最近上线的服务和定时任务；第三，应用侧开泄漏检测：HikariCP 的 leakDetectionThreshold 设 60000 毫秒，日志会直接打印哪段代码借了连接没还；Druid 开 removeAbandoned；Go 用 pprof 看 goroutine 堆积；Python 用 SQLAlchemy 的 pool 日志。第四，压测验证：用一个简单的脚本在测试环境模拟 200 并发、持续 5 分钟，观察 Threads_connected 是不是随时间单调上涨、压测结束后能不能回落。能回落是池配置问题，回不落是泄漏。 四、三个止血时容易踩的坑 第一，不要批量 KILL 正在 Query 的连接，先杀 Sleep 超过 10 分钟、来源已确认的非核心连接；第二，不要重启数据库，重启清现场，泄漏几小时后复发；第三，调大 max_connections 之前先算内存账，每个连接除了线程栈，还会按需分配 sort_buffer_size、join_buffer_size 等缓冲，从几百调到几千，极端并发下内存可能成倍上涨。 最后补一个检查清单，排查完可以逐项打勾：连接池是不是单例、连接有没有在 finally 或 defer 里归还、事务里有没有套远程调用、idleTimeout 是不是小于 wait_timeout、泄漏检测开没开、压测后连接数能不能回落。六项都过了，连接数打满基本不会再来。

先给一个能直接照着做的结论：没有业务数据就不要凭感觉选规格，先用“最小可用规格起步、压测验证、监控复核”走一圈。多数中小型Web业务从2核4GB通用型起步就够了，选大了是长期浪费，选小了靠升配和横向扩容都能补，怕的是不测量就一次定终身。 一、第一步：把业务翻译成四个数1. 峰值并发和QPS：看访问日志或压测，取业务高峰时段的数值，不要用平均值。2. 单请求CPU耗时：接口平均耗时50毫秒和500毫秒，同样QPS需要的核数差一个数量级。3. 内存占用：应用进程常驻内存加上缓存、连接数占用的内存，Java类应用要另外留出堆外内存。4. 磁盘与带宽：数据库看随机读写IOPS，文件、图片类业务看出网带宽峰值。这四个数里哪一项先到瓶颈，就优先保证哪一项，这就是选型的主线。 二、第二步：按场景对号入座个人博客、演示站、轻量Web：2核2GB左右的轻量规格即可，重点是够用和便宜。企业官网、API服务、小程序后端：建议2核4GB通用型，系统盘用高效云盘，带宽按实际峰值选，留出余量。MySQL、Redis等有状态服务：优先内存型，4核16GB起步，内存不足时数据库会频繁刷盘，比CPU不足更难受。转码、计算、批量任务：选计算型，核数给足，内存可以相对小一些。 三、第三步：在控制台按这个流程验证1. 购买ECS时先选满足当前需求偏小一档的规格，不要一次拉满。2. 开启云监控，重点看CPU利用率、内存利用率、磁盘IOPS和出网带宽四条曲线，并设置CPU持续高于70%时告警。3. 用ab或wrk对核心接口做60分钟压测，观察P95延迟是否稳定，有没有中途变慢（变慢要排查是否遇到突发性能回落或磁盘限速）。4. 压测通过后再上线，连续观察7天，P95长期低于40%就降一档，经常跑满就升一档或横向加机器。 四、省钱但不踩坑的四条经验1. 长期稳定运行的业务用包年包月，短期活动、测试、波动大的业务用按需，两种方式的账要按月算，不要只看单价。2. 突发性能规格只适合间歇性轻负载，持续高负载会回落到基线，生产核心业务不要用它扛峰值。3. 系统盘和数据盘分开，数据库的数据盘用IOPS更高的盘型，日志盘可以低一档。4. 带宽和流量费要单独算，公网出方向带宽和跨区流量有时比规格本身还贵，做总成本时不要漏掉。 按这个顺序走一遍，得到的规格是有数据支撑的，后面无论是降配省钱还是升配扛峰值，都有据可依。

楼上几位把预签名 URL 的原理、粒度和止损讲得很全了，我补充一个能直接照着跑的验证流程和一张 403 排错表，重点是“签完怎么证明能用、不能用时先查哪”。 一、先跑通最小闭环（obsutil，5 分钟）obsutil config -i=你的AK -k=你的SK -e=https://obs.cn-north-4.myhuaweicloud.comobsutil sign obs://你的桶名/partner/report.pdf -e 1800上面输出的就是带 AccessKeyId、Expires、Signature 的下载链接，30 分钟内有效。接着验证：curl -I "上面输出的链接"看到 HTTP/1.1 200 OK 说明链接可用；再用下面这条真正下一遍：curl -o report.pdf "上面输出的链接"注意：链接里的 &、= 不要手动拆开改，复制时用引号包起来；对象名含中文或空格时，先确认控制台显示的对象名与签名时用的完全一致，编码不一致是常见 403 原因。 二、生产上不要在前端签：Python SDK 后端签发from obs import ObsClientobs = ObsClient(access_key_id="你的AK", secret_access_key="你的SK", server="https://obs.cn-north-4.myhuaweicloud.com")resp = obs.createSignedUrl("GET", "你的桶名", "partner/report.pdf", expires=1800, headers={"response-content-disposition": "attachment; filename=report.pdf"})print(resp["signedUrl"])后端接口流程：合作方先登录或审批，后端按需签发，只把链接返回给对方；AK/SK 不出后端，链接有效期按“刚好够下载”给，临时分享 15 到 30 分钟通常足够。 三、签了链接还是 403，按这个顺序查1. 先看时间：本机时间与服务端时间相差超过 900 秒会签名失败，先用 date -u 对时（chrony 或 ntp），再重新签。2. 再看桶策略有没有显式 Deny：Deny 优先于一切，预签名也绕不过；同时检查是不是误把桶设成了公共读，公共读的对象签不签都能匿名打开，签名就没意义了。3. 再看 Referer 防盗链：开了白名单后，curl、Postman、对方直接粘贴到浏览器（不带 Referer）都可能被拦，表现就是“自己浏览器能开、对方打不开”。4. 再看签发账号权限：签发用的 IAM 用户至少要有 obs:object:GetObject，且限定到该桶或前缀；权限不够时签名本身能生成，下载时才报 403。5. 最后看 CDN：走了 CDN 加速域名时，确认 CDN 会透传签名参数，否则回源时签名丢了也会 403；排错时先用 OBS 原域名直测，排除 CDN 再回头查。 四、什么情况下别再发链接固定合作方长期下载：别反复发链接，用桶策略或 IAM 给对方账号授 obs:object:GetObject，限定到 partner/* 前缀，权限可收回、可审计。敏感内部资料、需要按人按次审计：走后端下载代理，合作方用业务账号登录，后端校验身份后从 OBS 取对象流式转发，链接不再直接发给对方。泄露止损分级：等过期（最轻，短有效期本身就是止损）；对象改名或换前缀让旧链接立刻 404（最快）；轮换签发 AK/SK（最重，该密钥签发的所有链接同时失效）。 一句话总结：桶保持私有、后端签发短有效期预签名 URL 是临时分享的标准做法；先用 obsutil 加 curl 把“签、验、下载”跑通，403 时按时间、Deny、Referer、权限、CDN 的顺序查；固定合作方和敏感资料再换精确授权或后端代理。

补充一个能直接照着跑的版本：楼上几位把权限、存储类别、生命周期、对象名、CORS、计费讲得很全了，我把这些坑收成一张“新手第一天检查清单 + 排错表”，按顺序做一遍，基本能避开 90% 的问题。 一、先定三条铁律，别等出事再改1. 桶保持私有，不开公共读。需要分享单个文件时，用带过期时间的临时签名 URL，而不是改桶权限。2. AK/SK 只放服务端和环境变量，绝不写进前端 JS、绝不提交到代码仓库；浏览器直传走后端签发的临时凭证。3. 先在测试桶跑通“上传—下载—授权—生命周期—删除”全流程，再往生产桶放真实数据。 二、创建桶时就要选对的三件事1. 区域：桶建在哪个区域，就用哪个区域的 Endpoint，SDK 里写错区域常表现为 301 或签名校验失败；桶一旦创建不能改区域。2. 存储类别：天天读的热数据放标准存储；几个月才读一次的再考虑低频/归档沉降。归档取回要等几分钟到几小时，还收数据取回费和提前删除费。3. 版本控制和加密：放重要文件时再开版本控制，并按需开服务端加密；开了版本控制后，控制台“删除”只是打删除标记，旧版本仍占空间。 三、上传下载：用命令先验证，再写代码先用 obsutil 做一次最小验证（把 AK、SK、Endpoint、桶名、对象名换成自己的）：obsutil config -i=你的AK -k=你的SK -e=https://obs.cn-north-4.myhuaweicloud.comobsutil cp 本地文件.txt obs://你的桶名/test/obsutil ls obs://你的桶名/test/obsutil cp obs://你的桶名/test/本地文件.txt ./下载.txt注意：obsutil 的 Endpoint、区域、桶名必须一致；对象名尽量只用字母、数字、短横线和点，避免中文、空格和特殊字符，否则签名 URL 容易因编码失效。大文件超过 100MB 不要一次性 PUT，用分段上传或 SDK 断点续传，分段大小建议 5MB 到 100MB；上传图片、PDF 时一定要指定 Content-Type，否则对象会按 application/octet-stream 存储，浏览器打开只能下载、不能预览。 四、临时分享单个文件：Python SDK 生成签名 URLfrom obs import ObsClientobs = ObsClient(access_key_id="你的AK", secret_access_key="你的SK", server="https://obs.cn-north-4.myhuaweicloud.com")resp = obs.createSignedUrl("GET", "你的桶名", "reports/2026-11-10.xlsx", expires=3600)print(resp["signedUrl"])这个链接 1 小时后失效，只授权这一个对象。需要给别人长期看时，再考虑桶策略加 Referer 防盗链，而不是直接开公共读。 五、生命周期：两条规则必须配1. 沉降规则：热数据到期后自动沉降到低频/归档，别手工搬。2. 清理规则：删除未完成的分段上传碎片；分段上传失败或取消后，碎片会一直占空间计费。删桶失败时先查：桶里是否还有对象、历史版本、未完成分段上传，清空后再删。 六、快速排错表403：先查桶策略和 IAM 策略，两处都可能拒绝；注意“无权查看”有时会伪装成 404。404：先用控制台确认对象确实存在，再核对对象名和区域。301 或签名失败：核对 Endpoint 与桶区域、AK/SK 是否一致。503 SlowDown：请求太集中，把键名前缀打散（加散列或按业务分桶），并给上传加退避重试。上传成功但打不开：先查 Content-Type 和 CORS，而不是反复重传；网页直传前要在桶的 CORS 配置里放行自己的域名和方法。账单异常：先查请求次数和公网流出流量，别只看存储量；不要写脚本每秒 LIST 全桶，ListObjects 默认一次最多返回 1000 条，超了要用 marker 分页。 按这个顺序在测试桶跑一遍，遇到问题按排错表定位，基本就不用再为“新手坑”返工了。

先给结论：不要先定规格再上业务。正确的顺序是先量负载，再按“够用+20%~30%余量”起步，用按量付费验证一到两周，最后把稳定的基线负载转包年包月；峰值交给弹性伸缩，而不是长期买一台大规格机器。 一、先给负载画像，三个问题定型1. 是 CPU 密集还是内存密集？Web、API 服务先看 CPU 和并发；缓存、数据库、大数据先看内存；视频转码、AI 推理再考虑 GPU 或加速型。2. 峰值是多少？日常 QPS、峰值 QPS、单请求耗时、峰值持续多久，这四个数决定规格，而不是凭感觉。3. 瓶颈在哪一层？CPU、内存、磁盘 IOPS、网络带宽，先定位再选型，盲目加核数解决不了磁盘和带宽瓶颈。 二、按画像选系列（以华为云 ECS 常见系列为例）- 通用型（CPU:内存约 1:4）：大多数 Web、API、中小数据库的默认选择；- 计算型（约 1:2）：计算密集、游戏服务端、视频编码；- 内存型（约 1:8）：Redis、MySQL、大数据内存计算；- 磁盘增强型 / 超高 I/O 型：数据库、Elasticsearch、高 IOPS 场景；- 突发性能型：个人博客、测试环境，靠 CPU 积分，不适合长期满载。 三、起步规格怎么算，给一个可复用的估算方法单核能扛的并发约等于 1 / 单请求 CPU 耗时。例如单请求 CPU 耗时 50ms，单核约 20 QPS；峰值 200 QPS 就需要约 10 核，再留 20%~30% 余量，12 核起步，然后用压测校准。内存按“应用常驻内存 + 缓存峰值 + 系统预留 1~2GB”估算，MySQL 建议缓冲池占内存的 60%~70%。估算只是起点，上线前一定要用按量实例跑压测，看 CPU、内存、P99 响应时间三条线再定。 四、什么时候升配、什么时候降配（看阈值，不凭感觉）- 长期 CPU 超过 70%，或 P99 延迟持续抬升：升一档，或横向扩容加机器；- CPU 长期低于 20%、内存长期低于 30%：降一档，省下的钱用在监控和备份上；- 规格调整后继续观察一周，确认瓶颈真的消失再收尾。 五、省钱的四把刀1. 计费方式：先按量验证，稳定后转包年包月；长期稳定负载可评估预留实例，适合中断的无状态任务可评估竞价实例；2. 弹性伸缩 + 负载均衡：峰值自动扩、峰后自动缩，不要为一年几次的峰值长期买大机器；3. 拆分而不是放大：数据库独立部署、读写分离、缓存前置，往往比单机一直加配置划算；4. 配套资源别超配：系统盘按实际数据量选类型和大小，带宽按峰值流量选，闲置实例及时关机或释放，每月看一次费用中心账单复盘。 六、一个落地的选型示例- 日活不高的企业官网、博客：2 核 4G 通用型起步；- 日均几万 QPS 的 API 服务：4 核 8G 通用型起步，配负载均衡 + 弹性伸缩；- MySQL 主库：8 核 32G 内存型 + 高 I/O 云硬盘。 最后提醒：规格不是一次定死的，建议每月复盘一次云监控和账单，规格跟着业务走，才是成本与性能真正的平衡点。

补充一个前面楼层提得较少的角度：把账算全再选规格，很多人只比实例价格，忽略了带宽、磁盘和流量。 一、先算总成本，不只算实例费。每月总费用约等于实例费 + 带宽/流量费 + 云硬盘费 + 快照备份费。Flexus L 这类套餐还要单独看月流量上限（如 100G）和超量后的规则，流量超了限速或额外计费，实际成本会一下子上去；大文件下载、视频中转这类吃流量的活不要走这台机器。 二、用预算倒推规格。先定一个每月能接受的成本上限，再在这个上限里选最大的可用规格，而不是先定规格再看价格。举例：个人博客、小站，Flexus L 2 核 2G 包年包月通常就够；日活上万的 Web 加独立数据库，通用型 2 核 4G 起步、数据库独立用 RDS，别把数据库和应用挤在一台机器上抢内存和磁盘 IO。 三、留一条便宜的退路。选型时确认这款实例支持变配、变配是否需要关机、快照能不能回退。能平滑升配的规格可以先买小一点，业务涨了再升；不能平滑变配的，宁可一开始留 30% 余量。 一句话：实例价格只是账单的一部分，先算总成本、再按预算倒推规格、最后确认能低成本升配。

先给一个可操作的结论：拥塞控制不是“限速”，而是发送方在不知道瓶颈在哪里的情况下，用拥塞窗口 cwnd 做“探测—反馈—调整”的闭环；真正能发的量始终是 min(cwnd, rwnd)，rwnd 是接收方通告的，cwnd 才是拥塞控制管的。 一、四个机制的分工（以 Reno/NewReno 为基准）1. 慢启动：初始窗口一般约 10 MSS，每收到一个新数据的 ACK，cwnd 加 1 MSS，所以一个 RTT 内窗口大致翻倍，呈指数增长，直到达到 ssthresh。它“慢”在起步小，不慢在增速——目的是快速探到带宽上限，又不一开始就把队列打满。注意严格说法是“每 RTT 翻倍”，不是“每个 ACK 翻倍”。2. 拥塞避免：cwnd 达到 ssthresh 后，每收到一个 ACK，cwnd 增加 MSS*MSS/cwnd，相当于每 RTT 只涨约 1 MSS，线性试探。这就是 AIMD 的“加性增”。3. 快速重传：连续收到 3 个重复 ACK，说明后续报文仍能到达、只是中间丢了一个，不必等 RTO 超时，立即重传疑似丢失的段。乱序也会产生重复 ACK，所以“3 个”是一个工程阈值，不是丢包的绝对证明，SACK 可以进一步精确定位丢了哪几段。4. 快速恢复：重传后不回慢启动。ssthresh 降为当前 cwnd 的一半，cwnd 先按 ssthresh 加上已确认的重复 ACK 数膨胀，随后随新 ACK 回落到 ssthresh，再进入拥塞避免。Tahoe 没有这一步，超时或快重传都会回到慢启动，恢复更慢；这正是 Reno 与 Tahoe 的关键区别。超时则是另一档信号：RTO 到期说明链路可能严重拥塞，ssthresh 降半、cwnd 回到 1 MSS，重新慢启动，并伴随 RTO 指数退避。 二、CUBIC 与 BBR 的思路差异CUBIC 仍是丢包驱动，但窗口增长不再按 RTT 线性走，而是按“距上次丢包的时间”做三次函数增长：离峰值远时涨得快，接近峰值时放缓，适合高带宽高时延链路，也更公平地对待不同 RTT 的流。缺点同样来自丢包驱动：只有丢包才减速，大缓冲链路容易把队列填满，延迟被顶高，即 bufferbloat。BBR 是模型驱动：持续估计瓶颈带宽 BtlBw 和最小 RTT RTprop，目标发送量就是 BDP = BtlBw × RTprop，并周期性做带宽探测和排空探测。它不把随机丢包直接当拥塞，在无线、跨洋等有随机丢包的链路上更稳；但多条 BBR 流共存、或与 CUBIC 混跑时，公平性需要专门验证，BBRv2 加入了丢包和 ECN 信号来缓解这个问题。 三、云上排查建议1. 先算 BDP：例如 100 Mbps × 50 ms ≈ 625 KB，窗口到不了 BDP 就跑不满，别先怪算法。2. 用 ss -ti 看 cwnd、rtt、重传，用 iperf3 对比算法，用 tc + netem 注入时延和丢包复现。3. 先区分信号：丢包集中在带宽打满时刻、且 RTT 同步上升，才更像真拥塞；EIP 或共享带宽限速、MTU 分片、NAT 会话老化造成的丢包或重置，也会被误判为拥塞。4. 全球加速 GA 缩短端到端 RTT 后 BDP 变小，窗口爬升更快，这是加速在拥塞控制层面的收益之一，但它不改变“丢包驱动还是模型驱动”这个算法选择。

补充一个更便于落地的判断方法：不要只比同 vCPU，而要比同预算和同内存需求下的业务表现。先说 Go 高并发网关这个场景：如果内存已经够用，c 系列通常更划算。原因不是字母本身，而是选型逻辑不同：c 系列是计算型，内存配比更低，同预算下往往能换到更多 vCPU 或者更高一档的网络基线；Go 服务内存占用相对稳定，内存余量够用时，瓶颈大概率在 CPU 和收发包上，这正是 c 系列的强项。反过来，如果网关还跑了缓存、连接池很大、峰值内存会明显波动，就要先算内存安全边际：峰值 RSS 加上 GC 和突发连接的预留后，如果 c 系列的内存余量不足，宁可选 s 系列，也不要让一次内存抖动变成 OOM 或频繁 GC。关于单核和网络 PPS 能不能用基准测试测出来：可以，但要分开测。sysbench cpu 主要测纯算力，适合看单核和多核的理论差距；wrk 测的是端到端网关能力，包含了协议解析、连接管理和后端延迟，不能直接等同于 CPU 差距。网络 PPS 建议再单独用 iperf3 或小包收发测试看基线，同时记录 wrk 的 QPS、P95、P99 和错误率，而不是只看峰值 QPS。一个常见的误区是压到 CPU 100% 就下结论，正确做法是先找到目标延迟下的最大并发：例如在 P99 不超过业务阈值的前提下，两种规格各能支撑多少并发，再换算成单位成本能支撑的请求量。关于同规格跨族对比的实际感知：我的建议是，纸面差距只有在瓶颈恰好落在 CPU 或网络上时才会被明显感知。如果瓶颈在后端数据库、磁盘 IO 或下游接口，换 c 还是 s 几乎看不出区别；如果瓶颈在网关本身的 CPU 和收发包，c 系列的优势会体现在同样并发下更低的延迟和更少的 CPU 占用上。给你的验证清单可以这样做：同一可用区、同一镜像、同一内核参数；先跑 sysbench cpu 单核和多核，再跑 wrk 的阶梯并发，最后用 iperf3 看网络基线；压测时同时看 CPU 使用率、steal 时间、内存 RSS、网络收发包和磁盘等待，定位瓶颈到底在哪；每种规格至少重复三次取中位数；最后用单位成本支撑的请求量来算性价比，而不是只比同 vCPU 的绝对性能。这样得出的结论，才可以直接用于这批服务的选型。

先回答你的核心诉求：“之后你能自己读取活动列表id吗？”——可以，但要先解决 401。 你的现象很有价值：“活动列表 API 用 STS 凭证返回 401，但发布 API 用 STS 可以工作”。同一套 STS 凭证，发布接口能过、列表接口不过，说明凭证本身是有效的，问题大概率出在列表接口的请求这一侧。建议按下面顺序排查： 1. 对比两个接口的完整请求把发布 API 和活动列表 API 的 URL、Header、签名方式逐项对照。展览馆 open-api-public 接口要求的是 STS 临时凭证头（X-Tmp-Ak / X-Tmp-Sk / X-Security-Token），确认列表接口的请求里这三个头都带齐了，缺一个就会 401。楼上有同学提到 Skill 文档里的端点和实际有出入，也对照一下 SKILL.md 里写的列表接口地址。 2. 查 STS 凭证是否过期STS 是临时凭证，申请时可设置有效期（最短 15 分钟）。智能体的典型用法是会话开始时换一次 STS 然后反复使用——如果发布 API 调得早、列表接口调得晚，STS 可能在中间过期了。重新换取 STS 后立刻调列表接口验证一下。 3. 区分 401 和 403401 是凭证无效或过期，403 是凭证有效但权限/委托不满足。云码道只提示“获取活动 ID 失败”时，先去调试日志里看真实的状态码，再决定查凭证还是查委托权限，方向完全不同。 4. 检查本机时间运行云码道的机器如果系统时间偏差过大，带时间戳的签名会被服务端判定为请求过期，表现同样是 401。排查权限之前先对一下时，这个坑很容易误判成权限问题。 5. 兜底方案如果列表接口一时调不通，先把 trainingCampId 做成可配置项，从网页端手动拿到活动 ID 填进去，保证发布主流程先跑通，自动获取作为增强项再慢慢修，不要让一个列表接口卡死整个发布流程。 调通之后欢迎回来更新下结论，方便后面遇到同样问题的人。希望对你有帮助！