前面几楼的框架很全了，我补一个自己的真实教训和一个可以直接抄的决策流程，侧重点是“什么时候不该升配”。先说教训：我第一台 ECS 买的是 4 核 8G 包年包月，跑个人博客加几个接口服务，结果半年下来 CPU 均值不到 10%，内存常驻不到 1GB，多花的钱纯粹是买了安心。后来降到 2 核 4G 通用型，响应时间没有任何变化，账单直接少了一半。选型最贵的错误不是买小了（买小了可以升），而是买大了长期空跑。我的做法现在是四步：一、按需试跑两周，再决定包年包月新业务先用按需的 2 核 4G 跑一到两周真实流量，同时开着云监控 CES。数据跑出来再决定：如果负载稳定、预计长期跑，就转包年包月拿折扣；如果负载潮汐明显，就保持按需加弹性伸缩。先按需后包年，比一上来就包年包月买大规格容错率高得多。二、无状态层和数据库层分开算Web 和接口这种无状态层，瓶颈来了优先水平扩容，多加一台 2 核 4G 做负载均衡，而不是把一台机器越升越大；数据库、缓存这种有状态层才优先垂直升级内存和磁盘 I/O。升配之前先确认瓶颈：磁盘 I/O 跟不上就换高 I/O 盘，带宽打满就升带宽，盲目加核数解决不了这两个问题。三、按 P95 而不是峰值定规格上线后看一周监控：CPU、内存长期低于 20% 就降档；P95 经常超过 80% 再升档。只看瞬时峰值很容易被一次部署、一次定时任务带偏。变配一般要关机或重启生效，留在业务低峰期做，变更前先给云硬盘做一次快照，万一新规格不合适还能退回来。四、共享型、突发性能型别当通用型用这类实例靠 CPU 积分工作，平时负载低、偶尔突发很划算；需要长期跑满 CPU 的业务直接选通用型或计算型，否则积分耗尽会被限速到基线水平，到时候再升配也救不回来。下单前先确认目标区域有货、账号配额够用，避免买到一半才发现要换区域。一句话：先按需跑出真实画像、再决定包年包月；无状态层横向扩、有状态层纵向升；按 P95 调规格，成本和性能基本能对上。

前面几楼把权限、区域、存储类型、分段残留讲得很全了，我补充一个按“真实翻车”排优先级的角度，都是我自己刚踩过的坑，重点在权限和计费这两类最贵的坑上。 一、权限：默认私有，别图省事改公开读 新建桶默认是私有，这是对的。很多人为了让图片、前端页面能访问，直接把整个桶改成公共读，这是新手最贵的一个坑：我之前一个只放官网图片的桶就是这样，一夜之间流出流量翻了十几倍，查下来是图片直链被采集站引用，流量费全算在我们头上。正确做法是：桶保持私有，需要分享单个文件时，在控制台对象详情里生成带过期时间的临时签名 URL；需要长期公开的静态资源，单独建一个公开桶，并配 Referer 防盗链白名单，只允许自己域名引用，保存后用 curl 带 Referer 和不带 Referer 各测一次，前者应返回 200，后者应返回 403。给应用授权走 IAM 用户或委托，不要把 AK/SK 写进前端代码和公开仓库。 二、计费：存储只是账单的三分之一 新手常以为 OBS 只收存储费，实际上请求次数、外网流出流量、取回费用都可能单独计费。低频存储最小存储时长 30 天、归档 90 天，文件存几天就删照样按最短时长收费；归档对象下载前要先发起恢复，恢复也要花钱和时间。开了版本控制后，控制台点“删除”只是打一个删除标记，旧版本仍在桶里继续计费，想真正释放空间要在生命周期规则里再配“删除过期版本”。建议上线前先看一次费用中心里的 OBS 账单构成，别只看存储量。 三、排障和上线前验证，别只凭控制台猜 报 403 先查 AK/SK 是否过期、IAM 策略和桶策略是否同时覆盖桶和对象、是不是用了过期的临时凭证；报 404 先核对区域、桶名和对象键，区域填错常表现为找不到桶。排障时用 obsutil 更直接：obsutil ls obs://桶名/前缀 看对象列表，obsutil stat obs://桶名/对象键 看大小、存储类型和元数据。大文件走分段上传，顺手给桶配一条生命周期规则，定期清理未完成的分段上传和过期对象。 建议新手先用一个测试桶把“建桶、上传、授权、生命周期、版本清理、删除”完整走一遍，账单核对无误后再上生产桶。希望对你有帮助。

先说结论：没有业务数据就不要按核数拍脑袋，先把业务翻译成资源画像，再按「小一档起步、压测验证、监控复核」走一圈。这个问题我最近是实测过的：同一套 Spring Boot + Nginx 的应用放在 Flexus 上跑，从选型到上线后调优，踩过的坑可以直接复用。一、先算一笔内存账，Java 应用尤其要算Spring Boot 内嵌 Tomcat 空跑大约就要占 300-500MB 内存，再加上堆外内存、系统本身和 Nginx，2 核 2GB 的机器留给 JVM 堆的常常不到 1GB。我的做法是把 -Xmx 设在总内存的一半左右，留足系统和堆外余量。堆设得太大，系统内存一紧张就开始用 swap，接口延迟直接翻倍，还不如一开始就选对内存。二、按场景对号入座，别只看核数个人博客、演示站、轻量 Web：2 核 2GB 的轻量规格足够，重点是够用和便宜。企业官网、API 服务、小程序后端：建议 2 核 4GB 通用型起步，系统盘用高效云盘，带宽按实际峰值选。MySQL、Redis 这类有状态服务：优先内存型，4 核 16GB 起步，内存不足时数据库频繁刷盘，比 CPU 不足更难受。转码、批量计算：选计算型，核数给足，内存可以相对小一些。拿不准就选通用型，它最不容易错。三、计费方式按稳定运行时长选长期稳定跑的业务包年包月更划算，短期活动、测试、波动大的业务按需更省。还有两点容易漏：一是突发性能型规格靠 CPU 积分，持续高负载几十分钟后会回落到基线，核心业务不要用它扛峰值；二是公网出方向带宽和跨区流量有时比规格本身还贵，做总成本时要单列。四、上线后用数据复核开云监控看 CPU、内存利用率、磁盘 IOPS、出网带宽四条曲线，连续观察 7 天：P95 长期低于 40% 就降一档，经常跑满就升配或横向扩容。只凭感觉选规格，迟早要么浪费钱、要么半夜被流量打垮。规格不是一次选定的，是一轮一轮调出来的。

前面几位讲的是通用排查思路，我补几个 OBS 新手真正会踩到的具体坑，都是按控制台实际操作能验证的。一、权限：默认私有，别图省事改公开新建桶默认是私有，这是对的。很多人为了让图片、前端页面能访问，直接把桶改成公开读或公开读写，这是最危险的一步。需要对外提供访问时，优先用临时签名 URL，或者用桶策略只放行指定的来源；做完就回头检查一次桶概览里的访问权限和桶策略，确认没有全网放开。二、区域和桶名：建错了改不了，只能重建桶名全局唯一，建好之后区域不能改。建到错误区域后，只能在正确区域重新建桶再迁移数据。SDK 或工具里填的访问地址要和桶所在区域一致，区域填错会报桶不存在或无权限，跨区域访问还会很慢。建桶前先确认业务以后常驻哪个区域。三、存储类型：便宜的另一面是取回费和最短存储时长标准、低频访问、归档的单价差别很大，但低频和归档都有最短存储时长，提前删除也按最短时长计费；归档数据取回要等待，还要收取回费用。热数据放标准存储，30 天以上不常访问的再用生命周期规则转低频或归档，不要一上来全桶选最便宜的类型。四、上传：大文件用分片上传，文件名用英文和数字大文件不要用单次上传，网络一断就得重传，改用分片上传，断点可以续传。浏览器直传前要先配好跨域规则，否则前端会报跨域错误。文件名尽量用英文、数字、短横线和下划线，中文、空格和特殊字符在签名时容易因为编码不一致导致 403。五、静态网站托管：不开托管，访问对象地址只能下载只把文件传到桶里，访问对象地址默认是下载，不是打开网页。想当静态网站用，要在桶上开启静态网站托管，并配好默认首页和错误页面，再用托管地址访问。六、删除：误删默认找不回来，重要桶先开版本控制不开启版本控制时，删掉的对象就是删掉了，误删很难恢复。重要桶先开启版本控制，删除只是打上删除标记，可以恢复；配自动过期删除规则前，先确认规则不会误删还在用的冷数据。新手建议：先建一个测试桶练手，默认保持私有、开启版本控制、配好生命周期，跑通权限和访问方式后再往生产桶放数据。

这个问题核心就一句话：把“留白多大、在哪、里面不能有什么”和“主体多大、在哪、朝哪”都写成能对照检查的数字，而不是写感觉词。下面是我实测下来比较稳的写法。一、先定画幅，再分区先固定画幅比例，再按画面宽高划分区域，不要留给模型自己分配。例如竖版海报：上方 25% 为标题留白区，下方 75% 为画面区；设备主体位于右下方，宽度约占画面一半，左侧中部留给三条说明文字。这样写的好处是生成后能直接量：留白区是不是真空了 25%，主体是不是在右下、有没有跑到中间。二、留白区要写清三件事1. 位置和大小：上方 25% 区域，浅色净空。2. 底色性质：纯色平坦、无渐变、无装饰线、无强反光、无复杂纹理。3. 禁止项：该区域不要出现任何文字、图标、边框和水印。只写“留白”两个字不够，模型会把留白当成可以放装饰图案的自由区，禁止项必须点名。三、主体要写死三个数字主体描述至少包括：1. 位置：右下方四分之一区域，不要居中。2. 占比：宽约占画面 50%，不要铺满画面。3. 朝向：主体朝向左侧文字区，关键部件朝向画面中心。位置、占比、朝向三项缺任何一项，生成结果都容易漂移；只写“主体突出”等于没写。四、一个可以直接套用的模板把提示词固定写成五句，依次是画幅、主体、留白、背景、禁止项。举个例子：竖版 3:4 海报；上方 25% 浅色净空，预留两行标题；设备主体在右下方，约占画面宽度一半，朝向左侧；左侧中部留三条说明文字位置；画面背景简洁干净，留白区内不要出现文字、装饰线和水印。五、验收和改错方法1. 先出低成本草图，只看分区关系对不对：留白是不是空的、主体是不是在规定位置、标题区放两行字会不会压到主体。2. 再把真实文案叠到留白区，检查字数、边距和底色对比度；文字放不下时先压缩文案或重新分区域，别只缩小字号。3. 出问题一次只改一项：位置歪了就改位置描述，留白被占了就加禁止项，不要同时改速度、角度和占比，否则不知道是哪句引起的。六、最常见的两个坑一是互相矛盾的要求：同时让主体居中铺满，又要保留整块完整文字区，这两个要求本身就冲突，先去掉一个。二是坐标只是目标：按比例写的分区生成后仍须人工核对实际位置，验收不过就按验收结果改数字，不要反复抽卡碰运气。

补充 1 楼的四步排查法，从“怎么量化、用什么工具、怎么在评审流程里落地”三个角度再展开一点。一、量化：别只看均值差，要做显著性检验分组样本量不够时，均值差可能是随机波动。建议用置换检验（permutation test）：把客户分组标签随机打乱重算差异分布，看真实差异是否落在极端位置；或者用 bootstrap 给差异算置信区间。统计显著不等于业务显著：差异哪怕显著，也要看它对通过率、分数段分布的影响幅度，再决定修不修。如果客户分组和业务水平本身相关（比如大企业项目规模天然更大），先做分层或倾向得分匹配（PSM），在业务水平相当的子集里再比较，否则差异会被业务因素污染。二、工具：别手写脚本从零做公平性评估可以用 Fairlearn、IBM AI Fairness 360（AIF360）这类开源工具，直接算 demographic parity、equalized odds 这些指标；想定位是哪些特征在驱动差异，可以用 SHAP 看特征贡献：若企业名称、所在地这类无关特征的 SHAP 值排在前列，就是偏差信号；提示词侧可以固定输出格式（JSON：分数 + 逐项依据 + 引用材料页码），依据写不出来就不采纳，方便事后审计。三、流程：把检测变成固定动作对照测试集固定下来，每次模型或提示词改版都跑一遍，差异指标记基线，出现漂移再排查；评审留痕：模型评分、依据、人工复核结论都存档；被评客户能申诉、能要求复核；评分者一致性：同一份材料请两位评审员独立打分，算 Cohen's Kappa 或组内相关系数（ICC），一致性低先修标准、再测模型。最后提醒：删掉敏感词不等于消除偏差，地址、行业、规模等代理变量还会继续泄露身份，删除之后要重新测一遍确认差异是否真的消失。

补充一个落地的切入点：别先从核心链路改起，先挑一个已有的低频定时运维任务做试点（比如每天凌晨的临时文件清理或报表汇总），用 Timer 触发器跑两周，验证三件事：冷启动对业务有没有影响、日志和告警能不能定位到某次调用、失败重试会不会重复写库（幂等）。试点通过后，再把事件驱动的数据处理、APIG 轻量接口这类场景迁过来。另外一个判断：把函数当成“胶水层”最合适——它负责在两个服务之间搬运和转换数据（OBS→处理→RDS、APIG→校验→SMN），而不是自己扛业务主逻辑；主逻辑一旦变重、变长、需要常驻，就该回到 ECS 或容器。一句话：先试点一个定时任务验证冷启动、日志和幂等，再按“事件触发、短时无状态”的清单逐步迁移。

先给一个能直接用的结论，再讲一个我实际搭过的例子，最后给一张对照表，帮你判断自己的业务适不适合。先说结论：三句话判断FunctionGraph 适合的任务同时满足这三点：1. 触发是离散的：平时没流量，事件来了才跑，比如 OBS 上传、定时触发、API 请求、消息到达。2. 单次执行时间短：一次能在函数超时上限内跑完，不用常驻进程。3. 不需要进程内状态：不用靠内存缓存、本地磁盘或长连接记住东西，状态放 OBS、数据库或消息队列里。三条里有一条不满足，就先别急着迁，先看后面的对照表。一个真实能跑通的例子：OBS 图片自动处理这是我最近搭过的最小闭环，适合拿来练手：1. 在 OBS 里建两个桶：原图桶和结果桶。2. 建一个函数，触发器选 OBS 事件通知（对象创建）。3. 函数收到事件后只做三件事：下载原图、生成缩略图和打水印、把结果写回结果桶，并在数据库里记一条记录。4. 再挂一个定时触发器，每天凌晨跑一次，清理原图桶里超过 30 天的临时文件。为什么选这个练手：触发源、执行时长、费用都看得见——平时没上传就没调用，有上传才计费；单次处理一张图一般几秒内完成；出问题时看函数日志就能定位到某一次调用。对照表：适合 vs 不适合适合 FunctionGraph 的：OBS 上传后自动转码、缩略图、水印；定时报表、清理过期文件、对账同步；轻量 Web API 和回调接收，比如表单提交、验证码、Webhook；消息到达后的数据清洗、格式转换、通知推送；AI 和数据处理流水线里的一小段逻辑，比如预处理、调模型服务、写回结果。不适合的：单次执行时间可能超过超时上限的长任务；需要常驻内存缓存或本地磁盘状态的服务；WebSocket 长连接；对延迟极其敏感且持续高并发的核心链路。这些更适合 ECS、CCE 或容器部署。成本怎么算：先算再上量计费主要是请求次数加上内存乘以执行时长，还有免费额度。不要只看单价，要按自己的真实流量先算一遍：比如每天 1000 次调用、每次 512MB 跑 2 秒，和一台按量 ECS 24 小时在线对比。低频、突发的流量用函数通常更便宜；如果调用一直很平稳、量又大，ECS 包年包月可能更划算。超时配得越大，单次异常执行烧掉的资源越多，所以超时要按最慢一次执行留余量来配，不要图省事配到最大。落地时容易踩的四件事1. 别让函数互相同步调用：多步任务用函数工作流编排，串行、并行、条件分支和重试都在工作流里定义，不要在函数里再调另一个函数等结果，超时和排障都会变复杂。2. 初始化只做一次：建数据库连接、加载模型这些重的活放函数初始化阶段，别每次请求都重建。并发一上来，每个实例都可能新建数据库连接，下游 RDS 连接数很容易先被打满——先限制函数并发上限，再把连接池调小，尖峰流量改走消息队列削峰。3. 超时和重试要配对：超时按最慢一次执行留余量；函数超时后平台可能重试，写库、发通知这类非幂等操作要先做幂等，比如用对象名加时间戳做唯一键，避免重复执行。4. 配置别写死：桶名、表名、密钥放环境变量或凭据管理；一个函数只做一件事，方便单独升级和排障。30 分钟验证清单1. 建一个 HTTP 触发的 Hello World 函数，用 APIG 暴露出来，调通一次。2. 在函数里打一条日志，去 LTS 里按请求 ID 找到这条调用记录。3. 隔一段时间再调一次，看冷启动的首次耗时变化；对延迟敏感的接口再考虑预留实例。4. 把超时、内存、并发上限按真实最慢一次执行设好，再挂一个 OBS 或定时触发器跑真实事件。建议先从一个非核心的定时或事件任务试点，跑通监控、日志、超时和重试，再推广到更多场景。

ping 通说明网络层面已经没有问题了，平台进度不更新一般是实验判题端还没采集到结果，不是路由的问题，可以按下面顺序排查：1. 先确认路由确实是“对等连接路由”：两端路由表的目的网段要写对方 VPC 的网段，下一跳选你建的那条对等连接（不是 ECS 网卡也不是 NAT 网关）；只看“条目存在”不够，点进路由详情核对目的地址和下一跳。2. 回到实验页面看有没有“验证 / 提交验证 / 完成实验”这类按钮没点——KooLabs 很多实验是点了验证后才触发判题的，ping 通本身不会自动推进度；点了之后等 3 到 5 分钟再刷新页面看。3. 如果点过验证还是不动，退出实验重进一次（不要删对等连接重建），换个浏览器或清缓存再看一次进度，排除页面缓存导致的状态没刷新。4. 超过 30 分钟还不更新，就把你手里那三张截图（ping 完整结果、对等连接状态、两端路由表）加上实验名称、账号和大致操作时间，通过大赛页面上的申诉 / 反馈入口提交人工复核；人工复核时说明“创建对等连接时误点了暂不添加路由，后来是手动补的路由”，让复核的人知道路由是后补的。这一步不用再动网络配置，ping 通、路由都在就是有效的，没必要删了重做，重做反而可能让判题端的状态更乱。

补充几个前面楼层提得比较少、但我自己新手期真实踩过的点，重点是“上线前先自查一次”，而不是出问题后再逐项排查。 一、先分清你要用的桶类型，别建错再重来 标准桶适合做图片、备份、静态资源这些对象存储的常规用途；如果你的场景是 HPC、大数据分析那种需要像本地文件系统一样频繁读写、改写小文件的，就要先确认是不是该用并行文件系统。桶类型、区域、桶名建好之后都不好改，建桶前先想清楚数据的读写方式，而不是先建一个桶再去迁。 二、同区域 ECS 优先走内网，别一上来就走公网 我在 ECS 上访问同一个区域的 OBS 时，一开始图方便直接用公网域名，结果既慢，账单里又多了一笔外网流出流量。改成同区域内网访问之后才正常。所以有个简单的检查顺序：先在控制台确认桶的区域，再确认你在 ECS、函数、容器里用的 Endpoint 是不是这个区域对应的域名；跨区域访问本身没错，但要知道它会产生跨区域流量，而且延迟也更高，调试时先排除“区域对不上”这个原因。 三、静态网站和对象直链是两回事 只想让人下载一个文件，用私有桶加带过期时间的临时签名链接就够了；如果要把 OBS 当静态网站用，首页、错误页、跨域（CORS）要单独配。只开“公共读”却不配静态网站托管，浏览器打开经常是下载文件而不是展示页面；反过来只配托管不配跨域，前端跨域读图片、读 JSON 也会报 CORS 错。这两件事要分开检查。 四、删了对象不等于不花钱，重点看三处残留 前面楼层提过版本控制和未完成分段上传，我再补一个自查方法：上线前到费用中心按 OBS 看明细，把费用拆成存储、请求、流量三项，不要只看总数。如果存储量一直下不来，依次查三处：一是版本控制的历史版本，二是未完成分段上传的碎片，三是生命周期规则到底有没有对你放文件的那个前缀生效。清理之前先在测试桶上把生命周期跑一遍，确认规则不会误删正式数据。 五、上线前 10 分钟自查清单 我现在每次新建桶，都会照着下面这张清单过一遍，10 分钟能避开大多数坑： 1. 区域、桶名、桶类型是不是已经定死了，SDK 和 obsutil 用的 Endpoint 对不对。2. 桶是不是保持私有，需要公开的部分只放行必要的前缀，临时分享用带过期时间的签名链接。3. AK/SK 有没有写进代码或提交到仓库，权限是不是只给这一个桶的最小权限。4. 大文件有没有走分段上传，上传完成后有没有核对对象大小和 ETag。5. 版本控制、生命周期、跨域、静态网站托管，这四项现在的开关是不是自己想要的状态。6. 先用 obsutil 在测试桶上走一遍上传、下载、删除，再到费用中心看一次 OBS 明细，确认没有异常的存储或流量。 比如 obsutil ls obs://你的桶名，可以先确认对象真的传上去了、桶和区域没看错，再去怀疑权限和代码；如果这一步就看不到对象，后面的权限排查都是白做。 一句话总结：OBS 的坑很少在“传不上去”这一步，大多在建桶时选错类型和区域、权限一上来就放得太开、以及删了对象之后费用还在继续。建桶前多想 10 分钟，比上线后翻账单、翻权限省事得多。