新手踩 OBS 的坑，根因几乎都是同一句话：把对象存储当成了本地文件系统。下面按"权限、区域、对象键、上传、浏览器直传、计费、报错对照"七类列出最高频的问题和对应做法。一、权限：桶策略、ACL、IAM 三套东西别混用桶默认私有。为了"让链接能打开"直接把桶设为公共读，是最危险的做法——一旦桶里混入日志、备份、用户上传件，等于全量泄露。对外分享单个对象用临时签名 URL（带过期时间），而不是长期公共读。桶策略管"谁能对这个桶做什么"，IAM 权限管"这个账号/委托能调用哪些 OBS API"，对象 ACL管单个对象的读写权限。三者是叠加关系，排查 403 时要三处一起看，只看一处会漏。给应用授权优先用委托（临时 AK/SK），不要在主程序里硬编码永久 AK/SK；临时凭证过期会直接报签名类错误。做了 CDN 或防盗链后，回源请求也要放行，否则会出现"控制台能下载、页面 403"。二、区域与 Endpoint：创建后改不了桶的区域创建后不能修改。选错区域只能新建桶迁移，所以创建前先确认业务部署区域。同区域 ECS 访问 OBS 要用内网 Endpoint，走公网 Endpoint 会产生公网流出流量费，而且延迟更高；本地开发/跨区域才用公网 Endpoint。很多"账单莫名变高"就是 Endpoint 配错。跨区域访问还要注意网络连通与带宽，别把跨区域当同城用。三、对象键不是目录，别按文件夹思维操作OBS 没有真正的目录，"文件夹"只是对象键的前缀。控制台里的"新建文件夹"实际是创建了一个以 / 结尾的零字节对象。对象键不要以 / 开头，否则会出现空前缀层级，列举和同步工具容易出错。删除"目录"不会级联删除下面的对象，要按前缀批量删除；同理，重命名目录等于复制+删除，大目录会非常慢。列举对象是分页的，必须处理 NextMarker/ContinuationToken，只取第一页会漏对象。四、上传：大小、分片、覆盖三个坑大文件不要单次 PUT，用分片上传：分片号从 1 开始，除最后一片外每片不小于 100KB，单片最大 5GB，总片数上限 10000。超大文件要先把"总大小 ÷ 10000"算一遍，确保每片不小于最小值，再决定分片大小。分片上传失败要断点续传（记录已成功的 partNumber），并且合并完成后清理未完成的分片——未合并的分片会占用存储并可能计费。同一个对象键并发写入是"最后写入生效"，不会报错也不会合并。需要防覆盖就开版本控制，或把版本号/时间戳放进对象键。上传后建议校验 ETag 或自己算 MD5，尤其是跨网络批量上传。五、浏览器直传：CORS 和签名是两大拦路虎浏览器直传前必须给桶配置 CORS 规则（允许的来源、方法 PUT/POST、允许的 Header），否则预检请求直接失败；如果前端要读响应头里的 ETag，还要在 ExposeHeaders 里显式暴露。前端不要持有 AK/SK。正确做法是后端签发临时凭证或表单 POST Policy，前端只拿短期授权上传。直传失败先看浏览器 Network 里的预检请求（OPTIONS）状态码，再看 OBS 返回的 Code 字段，不要只看控制台报错文案。六、计费：免费额度之外的隐形支出计费项不止存储容量：还有请求次数、公网流出流量、低频/归档的取回费用和最短存储时长。归档存储提前删除或提前取回都会额外收费。临时文件、日志、备份一定要配生命周期规则自动转低频/归档或过期删除，否则容量只增不减。大量小文件会放大请求次数和列举成本，能打包就别散着存。七、常见报错对照表403 AccessDenied：桶策略/ACL/IAM 三者之一没放行，或对象不存在但无列举权限（OBS 对无权限对象也可能返回 403 而非 404）；403 SignatureDoesNotMatch：AK/SK 错、签名算法或签名 Header 不一致、代理改写了 Host/Header；403 RequestTimeTooSkewed：客户端时钟偏差过大，校准 NTP；404 NoSuchBucket / NoSuchKey：Endpoint 区域与桶区域不一致也会表现为找不到桶；400 EntityTooLarge / InvalidPart：单次上传超限或分片号、ETag 不匹配；400 MalformedXML：批量删除、生命周期、CORS 等配置的 XML 结构不合法。上线前检查清单桶区域、Endpoint（内网/公网）确认无误；桶策略 + IAM + ACL 三处权限按最小授权配好，未开放公共读；CORS 规则覆盖实际前端域名与上传方法；大文件走分片 + 断点续传，并有未合并分片清理机制；生命周期规则已配置，低频/归档的最短存储期与取回费已评估；关键桶开启版本控制，误删可恢复。把这六项在测试桶里跑通再切生产，绝大多数"新手坑"都能提前暴露。

判断 FunctionGraph 适不适合，先看任务是否同时满足四个特征：事件驱动、无状态、单次执行短、流量波动大。四个都中，函数通常比常驻 ECS 便宜一个量级；中得越少，越应该用容器或 ECS。一、按"触发器"来对应场景，最不容易选错FunctionGraph 的场景基本可以按触发器类型反推，落地时直接看这张对应关系：OBS 触发器：对象上传/删除后自动处理，例如图片压缩、加水印、生成缩略图、视频转码、文档解析、病毒扫描。这类是典型的事件驱动，注意事件可能重复投递，处理逻辑必须幂等（按对象 ETag 或业务 ID 去重）。API 网关（APIG）触发器：轻量 HTTP 后端、Webhook 接收、表单提交、小程序接口。鉴权、限流、CORS 尽量放在 APIG 层，函数只做业务；对延迟敏感的接口配置预留实例消除冷启动。定时触发器：日报/周报生成、过期数据清理、资源巡检、对账、缓存预热。注意时区配置、错过调度后的补偿，以及多实例并发时的分布式锁，避免同一任务跑多份。消息/数据流触发器（SMN、DIS、Kafka 等）：消息清洗、格式转换、写入数据库或 OBS，构成轻量 ETL。要设置合理的批处理大小、重试次数和死信/失败兜底，避免毒消息无限重试。胶水/编排层：把多个云服务或内部 API 串起来，做告警聚合、工单同步、第三方回调转发。这是函数最容易被低估的用法——不承担重活，只做路由和适配。轻量 AI/Agent 工具函数：把一次模型调用、一次检索、一次外部工具执行封装成函数，供工作流按需调用，空闲时零成本。二、明确不适合的场景，能省掉一次架构返工长连接/WebSocket 服务：函数实例不保证常驻，连接会被打断；长时间跑批、大文件全量处理：受单次执行时长上限约束，应拆成多段、改用容器/ECS，或用专门的大数据/媒体处理服务；依赖本地磁盘或进程内缓存的常驻服务：函数是无状态的，临时目录不保证保留，缓存要外置到 Redis；7×24 高 QPS、低延迟的在线主服务：冷启动和按量单价叠加后，往往不如常驻容器；需要 GPU 常驻的推理服务：应选 GPU 容器/专属实例，不要硬塞进函数。三、成本拐点怎么算，而不是凭感觉把两种方案折算到月成本再比较：函数月成本 ≈ 调用次数 × 单次计费时长(GB-秒) × 单价 + 请求次数费常驻月成本 ≈ 实例月费（含闲置时间）核心变量是平均并发 × 常驻时间。如果业务全天都有稳定并发，函数实例实际一直"热"着，按量费用会迅速逼近甚至超过常驻实例；反之，一天只跑几次、每次几百毫秒，函数成本可以低到忽略。经验判断：日均调用少、单次短、峰谷差大 → 函数；持续高并发、长连接、重计算 → 容器/ECS。也可以做混合架构：函数负责触发、编排和轻量逻辑，重活交给容器或批处理服务。四、上线前的四个检查项幂等：重试、重复事件、至少一次投递都会导致重复执行，写库要带唯一键或状态机校验；超时与重试：函数超时要小于上游网关/消息可见性超时，重试要有上限并配死信；并发与连接数：函数实例数暴涨会打爆数据库连接，必须走连接池/代理，或限制预留并发；权限最小化：每个函数单独委托、只授予需要的 OBS/日志/网络权限，避免一个函数权限过大。一句话总结：事件驱动、无状态、分钟级以内、流量波动大——满足就用函数；常驻、长连接、重计算、低延迟——用容器或 ECS；拿不准就算"平均并发 × 常驻时间"的成本拐点。

这个问题本质不是"选大还是选小"，而是把选型拆成四个可量化的决策：规格族、vCPU/内存配比、磁盘与带宽、计费方式，最后用"单位有效请求成本"来裁决。下面按顺序给方法。一、先定规格族，再谈核数同样是 4 核 8G，通用型、计算型、内存型的实际表现差别很大。先压测定位瓶颈资源，再对号入座：CPU 先打满、延迟随并发线性上升：选计算型（c 系列），不要用通用型硬扛；内存先到 80% 或频繁 GC/OOM：选内存型（m 系列），数据库、缓存、大 JVM 堆尤其明显；CPU、内存都不高但 iowait/await 高：问题在磁盘，选磁盘增强型或换 EVS 类型，加 CPU 没用；日常负载很低、只有短时突发：可看突发性能型（t 系列），但它是靠 CPU 积分运行的，持续高负载会把积分耗光并限速，不适合作为常态高 CPU 业务；Web 前后端分离、无特殊瓶颈：通用型（s 系列）即可，配比均衡、单价最低。二、用利用率区间定容量，而不是拍脑袋建议按 P95（不是均值）设阈值：CPU 长期低于 60%~70%、内存低于 75%~80%、磁盘 await 与 IOPS 低于规格上限的 70%、带宽低于 60%。落在这个区间说明规格与业务匹配。连续一周 P95 CPU 20% 且内存 40%：优先降配，这是最直接的省钱手段；P95 已贴阈值、但峰值只持续很短：不要直接升固定规格，用弹性伸缩补峰值；峰值持续数小时以上：升固定规格更划算，弹性频繁启停反而更贵、更不稳定。三、峰值用"固定 + 弹性"组合，不要为 1 小时峰值买 24 小时把固定规格按峰值负载的 70% 左右选，剩余 30% 交给弹性伸缩或队列削峰。注意两点：弹性伸缩有冷却时间和扩容时长，必须提前预热（定时策略 + 预热实例），否则高峰来了还在创建实例；无状态服务才能放心弹性，有状态服务要先做会话外置。四、规格之外的两笔钱：磁盘和带宽很多"选型贵"其实贵在这两块：系统盘按容量和 IOPS 计费，通用型 SSD 的 IOPS/吞吐通常随容量提升，小容量盘跑高并发数据库会先撞 IOPS 上限；公网带宽按固定带宽或流量计费，静态资源走 CDN、同区域走内网可以省掉大部分流量费。这两项要在选规格时一起算，不能只看 vCPU 单价。五、计费方式按"运行时长形态"选7×24 稳定运行：包年包月，单价最低；开发测试、临时任务、明显潮汐：按需 + 弹性，用完即释；可中断的离线计算（渲染、批处理）：竞价实例，成本最低但要接受被回收，必须做检查点；不确定长期形态：先按需跑一个完整业务周期，拿到真实账单后再转包周期。六、用一个公式做最终裁决把候选方案都折算成单位有效请求成本：月总成本 = 实例月费 + 磁盘月费 + 带宽/流量费 + 弹性溢出费单位请求成本 = 月总成本 / 月成功请求数在满足 P95 延迟和错误率目标的前提下，比较各方案的单位请求成本，而不是比较配置单。经常出现"高配单机"比"低配多机 + 弹性"单位成本更高的情况，因为前者长期闲置。七、降配前的安全边界降配前先确认应用侧上限没有被配置卡住：连接池、线程池、JVM 堆、GC 参数、文件句柄数。很多团队升配后性能没变化，就是应用自己先限流了；反过来，降配后先压测一轮，观察 P95 延迟、错误率和 GC 次数，再决定是否保留。另外升配/降配通常需要重启，要安排变更窗口并确认快照可用。一句话总结：先按瓶颈定规格族，再按 P95 定容量，峰值交给弹性，最后用单位请求成本横向比较——选型不是选最大或最小，而是选"刚好覆盖 P95、峰值能弹性、单位成本最低"的那一档。

先按报错码分流，别一上来就改配置"密码重置了还是连不上"最常见的原因是改的密码和业务实际使用的认证路径不是同一条。先看业务报什么错，方向完全不同：1045 Access denied：网络是通的，问题在账号、密码、host 授权或认证插件。2003 Can't connect / 超时：监听地址、端口、安全组或实例没起来。1049 Unknown database：库名或连接的库不对。你提到"本地能登录、业务连不上"，基本可以把范围收敛到认证与授权层，重点查下面几处。1. 本地登录走 socket，业务走 TCP在服务器上直接 mysql -uroot -p 往往走的是 localhost 的 socket 账号；业务用 IP + 3306 走 TCP，命中的是另一条 host 记录。先在业务所在机器上用同样的账号手动连一次：mysql -h 数据库内网IP> -P 3306 -u 业务账号> -p这里能连上 → 问题在业务配置/连接池；这里也连不上 → 问题在数据库侧授权或网络。2. 核对账号的 host 授权用 root 登录后执行：SELECT user, host, plugin FROM mysql.user;确认业务账号的 host 是否覆盖业务机器 IP（或所在网段 / %）。只有 'app'@'localhost' 而没有 'app'@'10.0.0.%' 时，本地能登、远程必被拒。需要时补授权：CREATE USER 'app'@'10.0.0.%' IDENTIFIED BY '新密码';GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO 'app'@'10.0.0.%';FLUSH PRIVILEGES;3. 重置密码用对语句，注意认证插件MySQL 5.7+/8.0 推荐 ALTER USER 'app'@'10.0.0.%' IDENTIFIED BY '新密码';，不要再用旧式的 UPDATE mysql.user 改表（容易漏掉 FLUSH PRIVILEGES 或改错 host）。另外 MySQL 8 默认 caching_sha2_password，老客户端/老驱动可能不认，表现为认证失败。要么升级客户端/驱动并启用 SSL，要么显式改为 mysql_native_password：ALTER USER 'app'@'10.0.0.%' IDENTIFIED WITH mysql_native_password BY '新密码';4. 业务侧的密码和连接池是否真的更新了数据库密码改了，业务的配置文件、环境变量、K8s Secret、配置中心是否都同步？改完必须重启业务或重建连接池，否则旧连接和旧密码缓存仍在生效。连接池的 maxLifetime 太长时，也会让失效连接继续被复用。若前面挂了 ProxySQL/HAProxy/读写分离中间件，代理层的账号密码同样要改。5. 确认监听地址不是只绑了 127.0.0.1检查 bind-address 与 skip-networking。若 bind-address = 127.0.0.1 或开了 skip-networking，外部 TCP 根本连不进来。改完重启 MySQL，并用 ss -lntp | grep 3306 确认监听在 0.0.0.0 或内网 IP。6. 网络与安全组（只用于 2003/超时场景）如果报的是拒绝/超时而非 1045，再到安全组放行 3306、检查 VPC 路由与防火墙。注意：1045 说明 TCP 已建连，此时在安全组上耗时间没有意义。7. 密码里的特殊字符密码含 @ : / # ? & 时，写在 URL、JDBC 串、YAML 或 shell 里都可能被转义或截断。优先用环境变量/密钥管理注入，shell 里用单引号，JDBC 用 ?user=..&password=.. 时注意 URL 编码。8. 最后确认"连的是不是同一个实例"DNS、VIP、内网域名可能指向旧实例或只读节点。用 SELECT @@hostname, @@port, @@version; 在业务侧连接上后核对，排除连错库、连到从库、连到旧 IP 的情况。建议的排查顺序就是：看报错码 → 业务机器同账号手连 → 查 host 授权与认证插件 → 同步业务配置并重启连接池 → 查 bind-address → 最后才看网络。按这个顺序，绝大多数"重置密码后仍连不上"都能一次定位。

选型不是"挑最大的"，而是先把三件事算清规格选型的本质是：用可量化的负载指标反推 vCPU/内存/网络/磁盘，再用弹性与计费方式压成本。顺序错了，要么性能不够，要么长期为闲置买单。1. 先给业务定类型CPU 密集（编译、转码、加解密、计算服务）：优先高主频、计算型，vCPU:内存约 1:1～1:2。内存密集（数据库、缓存、大数据）：内存型，1:8 甚至更高，别用通用型硬扛。IO 密集（数据库、日志、消息队列）：重点看云盘，而不是只看 vCPU——ESSD 的 IOPS/吞吐等级往往才是瓶颈。网络密集（网关、代理、视频）：看带宽与收发包 PPS，很多规格的带宽上限是独立售卖的。2. 用压测数据算 vCPU，而不是拍脑袋在目标规格上做一次基线压测，得到"单 vCPU 能承载多少 QPS/并发"，再按 P95/P99 峰值（不是平均值）反推所需核数，并预留 30%～50% 余量应对突发。只按 CPU 使用率 20% 就断言"够用"并不稳妥，因为瓶颈可能在内存、磁盘 await 或网络。3. 留意"突发性能型"的积分机制突发性能型（t 系列）单价低，靠 CPU 积分在低负载时攒、高峰时花。适合长期低基线、偶发尖峰的站点；但积分耗尽后会被限频，对延迟敏感或持续高负载的业务不要选它，否则高峰期性能断崖式下跌。4. 成本要按"计费方式 + 弹性"一起算稳定长跑：包年包月或节省计划，单价最低。可预测的波峰波谷：按需 + 弹性伸缩（定时/指标触发），低谷缩容。无状态、可中断的批处理：竞价/Spot 实例，成本可降到按需的一小部分，但要设计好中断重试。短期验证：先按需小规格跑通，再根据监控数据决定升配还是换实例族。5. 用监控持续调优，而不是一次选死上线后看四组指标：CPU 使用率与 load、内存使用与 swap、磁盘 await/IOPS/吞吐、网络带宽与 PPS。如果连续 1～2 周 CPU 与内存都长期低于 30%，就该考虑降配或合并部署；如果长期高于 70% 且延迟抖动，先排查慢查询/锁/GC，再决定升配。6. 先用架构手段，再考虑堆规格很多时候"加配置"是最贵的解法。能加 Redis 缓存、做异步削峰、读写分离、静态资源上 CDN/OBS、把有状态服务拆出去的，往往比直接升到更高规格更省钱，也更容易横向扩展。7. 别忽略这些隐性约束目标可用区是否有该规格库存、账号配额是否够、升配是否需要重启、带宽是固定还是按流量、系统盘/数据盘类型是否匹配 IO 需求。选型时把这些一起确认，能避免"买到了却开不出来"或"上线后磁盘拖后腿"。一句话：先定负载类型 → 压测算核数 → 选对实例族和云盘 → 用计费方式与弹性控成本 → 用监控持续校准。按这个顺序，成本与性能才能同时可控。

先说结论OBS 新手踩坑，多数不在"上传慢"，而在权限、命名、地域、生命周期、分片残留、计费这几件事上。按踩坑概率从高到低说。1. 不要为了"能下载"就把桶设成公共读这是最贵也最常见的错误。正确做法：桶保持私有，临时分享用预签名 URL（有效期按需设置，几小时到几天），长期授权用 IAM 用户/委托 + 最小权限策略。任何一次测试后都要回看桶策略，遗留的 public-read 策略往往几个月后才被发现。2. 桶名全局唯一且不可改，对象键不是目录桶名创建后不能修改，先用"项目-环境-用途"的规则定好，别用 test1、test2。对象键里的 / 只是键的一部分，并不是真实目录，所谓"文件夹"是靠前缀模拟的。因此要在写入前就规划好 业务/日期/类型/ 这类前缀，后期批量挪前缀非常痛苦。3. Region 与 Endpoint 必须对上桶建在哪个 Region，SDK/obsutil 就要用该 Region 的 Endpoint。拿着 A 地域的 Endpoint 去访问 B 地域的桶，报错往往很迷惑（NoSuchBucket、签名不匹配、403）。ECS 与桶同地域还能省跨区流量费、降延迟。4. 版本控制会放大存储账单开启版本控制后，每次覆盖写都会保留旧版本并持续计费。只有确实需要误删恢复时才开；开了就配合生命周期规则，让非当前版本在 N 天后转低频/归档或直接过期删除。日志、备份、临时文件同理，一定要配生命周期，否则测试桶会悄悄涨到几十 GB。5. 大文件走分片上传，失败要 abort大文件用 SDK 的 multipart upload，不要单次 PUT。重点：上传失败或进程被杀时，未完成的分片会占用存储并计费，必须调用 abort 清理，或配置"清理未完成分片"的生命周期规则。分片大小也要调（常见 5–10 MB 起），分片过小请求次数多、过大则重传成本高。6. 计费项不只有存储外网下行流量、请求次数、跨区复制流量、CDN 回源都可能产生费用。静态资源对外提供时，走 CDN 回源 OBS、并给桶加防盗链/Referer 白名单，比直接开公共读安全得多。下载量大的场景，流量费常常超过存储费。7. 几个高频报错的定位顺序403 AccessDenied：先看 AK/SK 是否属于目标账号、桶策略/IAM 是否放行、签名地域是否匹配，最后才怀疑网络。404 NoSuchBucket / NoSuchKey：先核对桶名大小写与 Region，再核对对象键是否多了或少了前缀斜杠。上传成功但读不到：确认读的是同一对象版本、同一 Region，以及是否被 CDN 缓存了旧内容。8. 安全侧建议敏感数据用 SSE-KMS 服务端加密；需要防篡改用 WORM；审计用桶日志或 OBS 访问日志；AK/SK 不要硬编码在代码里，用临时凭证或委托。把这些做成创建桶时的检查清单，比事后补救省事得多。一句话总结：私有桶 + 预签名 URL、先定命名与前缀、Region 对齐、生命周期兜底、分片失败必清理、流量也要算钱。这六条能避开新手 90% 的坑。

关键结论：换成长期 AK/SK 就正常，说明桶策略、网络、Endpoint 都没问题，问题出在「临时凭证本身的权限范围或使用方式」上。STS 临时凭证和长期 AK/SK 最大的区别是：它必须携带 SecurityToken，且权限被 AssumeRole 时指定的策略严格限定。1. 最常见：SDK 没带 SecurityToken（或带错）STS 临时凭证是「AccessKeyId + SecretAccessKey + SecurityToken」三件套，缺一不可。只传了 AK/SK 而没传 token，或 token 字段名写错，就会表现为签名校验通过但鉴权失败，返回 403 AccessDenied。检查初始化 OBS 客户端时是否设置了 securityToken（不同 SDK 字段名略有差异，务必按所用 SDK 文档设置）。确认 token 是从 STS 响应里的 Credentials.SecurityToken 取的，而不是别处的字段。2. 临时凭证的权限被 AssumeRole 的 Policy 收窄了通过 AssumeAgency/AssumeRole 获取临时凭证时，可以传入一个会话策略（Policy），它会对委托本身的权限再做一次「取交集」限制。如果这个会话策略里没包含目标 OBS 桶的动作（如 obs:object:PutObject），临时凭证就只有被允许的那部分权限，对桶上传自然 403。排查方向：确认申请 STS 时传入的 policy 是否覆盖 obs:object:* 及目标资源 obs:*:*:object:桶名>/*。长期 AK/SK 不受这个会话策略约束（它走的是账号/用户的原始权限），所以表现正常——这正好印证了「临时凭证权限被收窄」。3. 委托角色本身的权限不足临时凭证继承的是被委托的IAM 委托/角色的权限。如果这个委托没有 OBS 的写权限，或只授予了读权限，也会 403。到 IAM 控制台检查该委托附加的权限策略是否包含目标桶的 PutObject。4. 桶策略 / ACL 没有对临时身份放行如果桶策略显式写了 Allow 只针对某个长期用户或账号，而没有覆盖「委托身份」的 Principal，临时凭证访问时会被桶策略拒绝。可以临时用桶策略 Deny 之外的方式验证：先确认桶策略里对委托身份的 Principal 有对应 Allow。5. 凭证过期或时钟偏差STS 临时凭证默认有效期较短（常见 15 分钟~1 小时，最长不超过 24 小时）。过期后继续用会 403，需在过期前刷新。本机时间与标准时间偏差过大也会导致签名/有效期校验失败，检查服务器 NTP 同步。6. 快速定位清单按顺序核对：① 客户端是否真的传了 SecurityToken；② AssumeRole 时传入的会话 Policy 是否包含桶的上传动作；③ 委托角色本身是否有 OBS 写权限；④ 桶策略是否对委托身份放行；⑤ 临时凭证是否已过期、机器时间是否准确。多数「长期正常、临时 403」都是 ① 和 ② 两个原因。

结论先说：OPTIMIZE TABLE 对 InnoDB 大表本质上是一次「重建表」，会拷数据、重建索引，期间持有 DDL 锁并消耗大量 IO，4000 万行锁 40 分钟属正常量级。真正的问题往往出在前面「一次性删 4000 万行」这一步，更安全的做法要拆成「分批删 + 在线重建」两段来做。1. 先纠正删除方式：不要一次性删 4000 万行单条 DELETE FROM t WHERE ... 删掉几千万行会带来：超长事务、undo log 暴涨、主从延迟、锁等待堆积。应分批删除：-- 每批只删 5000~20000 行，循环执行直到删完DELETE FROM t WHERE 条件 ORDER BY id LIMIT 10000;每批之间 sleep 几十毫秒到 1 秒，给主从复制和 purge 线程留出消化时间。删除完成后空间会被 InnoDB 标记为可复用，但不会自动归还操作系统——这才是你想 OPTIMIZE 的原因。2. 比 OPTIMIZE TABLE 更安全的重建方式在线 DDL 重建：MySQL 5.7/8.0 支持 ALTER TABLE t ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE，可在 DML 不阻塞的情况下重建表、回收空间（具体是否支持 INPLACE/LOCK=NONE 取决于版本与表特性，执行前先用 ALTER ... ALGORITHM=INPLACE, LOCK=NONE 试跑确认，不满足会直接报错而不会真改表）。第三方在线变更工具：pt-online-schema-change（Percona）或 gh-ost（GitHub），通过影子表 + 触发器/binlog 同步的方式重建，对线上几乎无锁，适合超大表。RDS 控制台的「空间回收/表碎片整理」：华为云 RDS 提供了内置的表空间回收能力，可评估后按指引执行，避免自己踩 DDL 锁的坑。3. 降低锁表影响的配套动作放低峰期执行：重建期间 IO 和 CPU 占用高，务必避开业务高峰。先评估是否真需要重建：删除后空间虽不返还 OS，但可被新数据复用。若表还会继续增长，重建的收益有限，可暂缓。控制 innodb_online_alter_log_max_size：在线 DDL 期间若有大量并发写，超出该值会导致 DDL 失败回滚，需按业务写入量调大。关注主从延迟：重建会产生大量 binlog，从库可能跟不上，必要时临时提升从库规格或错峰。超时与重试：设置合理的 lock_wait_timeout，避免 DDL 等待元数据锁把后续查询全堵死。4. 推荐的落地顺序① 用 LIMIT 分批把 4000 万行删完，确认业务与主从稳定；② 用 ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE 或 gh-ost 在线重建回收空间；③ 重建后 ANALYZE TABLE 更新统计信息，避免执行计划走偏。这样既能回收空间，又能把锁表时间压到最小甚至做到不锁 DML。

核心原因：CodeArts Pipeline 的不同「阶段」运行在各自独立的执行环境里，工作区（workspace）不跨阶段共享。build 阶段打出来的 jar 只存在于 build 任务的临时容器/主机里，阶段一结束环境就销毁，deploy 阶段自然找不到。1. 先理解流水线的执行模型一个流水线由多个阶段（Stage）组成，每个阶段包含若干任务（Task）。每个任务默认在独立的执行环境中运行（容器/弹性云主机），任务结束即回收，任务之间、阶段之间都不共享本地目录。所以 build 阶段产出的 target/app.jar 不会自动出现在 deploy 阶段的工作目录里。2. 正确做法：把产物显式「上传 → 下载」跨阶段传产物必须落一个共享存储，常见三种方式：构建产物（Artifact）上传/下载：build 任务用「上传构建产物」步骤把 jar 传上去，deploy 任务用「下载构建产物」步骤取回来。这是流水线内置能力，最省事，适合同一条流水线内传递。软件包仓库：build 阶段 mvn deploy / npm publish 到私有制品仓库（如 CodeArts 制品仓库），deploy 阶段按坐标拉取。适合多流水线复用。对象存储 OBS：build 阶段把 jar 传到 OBS 指定路径，deploy 阶段用 OBS 下载步骤取回。适合产物较大或需要长期保留的场景。3. 常见踩坑点只在 build 阶段执行了打包，却没配置上传步骤：这是最常见的——本地能看到 ls target/*.jar 有文件，但没上传，跨阶段就丢了。上传路径与下载路径不一致：上传时用了默认产物名，下载时按另一个名字找，导致"下载成功但目录为空"。建议上传/下载用同一个变量（如 ${artifactName}）贯穿。混淆「同一任务内的多步骤」与「跨任务」：同一个任务内的多个步骤共享工作区，可以连续操作；但换任务、换阶段就一定不共享。deploy 阶段没指定产物版本/构建号：下载到了上一次构建的旧包。下载步骤要显式绑定当前流水线运行的构建号。4. 快速定位方法在 build 任务末尾加一步 ls -lh target/ 打印产物，在 deploy 任务开头也加一步 ls -lh 打印当前目录。如果 build 有、deploy 没有，即可确认是「没有做跨阶段传递」；若 deploy 有但文件名不对，则是路径/命名不一致。确认后在两阶段之间补齐上传 → 下载即可。

最可能的原因：HPA 的 CPU 利用率是相对“容器 CPU requests”算的。如果没有给容器配置 resources.requests.cpu，指标就算不出来（或显示为 0），HPA 自然永远不会触发扩容。请先按下面顺序排查。1. 确认指标本身是否算得出来HPA 的 CPU 利用率 = 实际 CPU 使用量 / requests.cpu。执行：kubectl top pod -n kubectl describe hpa -n 若 describe hpa 里 TARGETS 显示 /70%：说明 metrics 拿不到，问题在采集侧，见第 2 点。若显示的是一个远低于 70% 的真实百分比：说明指标正常，只是没到阈值，见第 3 点。2. 指标采集侧排查（TARGETS unknown）metrics-server 未安装或异常：CCE 通常默认提供 metrics API，若是自建集群需确认 kubectl top 能正常返回；否则 HPA 无数据来源。容器没设置 CPU requests：这是最常见原因。给工作负载补上，例如：resources: requests: cpu: "200m" limits: cpu: "1000m"没有 requests，利用率分母缺失，HPA 视为无效指标，不会扩。3. 阈值与采集口径排查“CPU 打上去了”是瞬时峰值，而 HPA 看的是平均值：默认以约 1 分钟窗口的平均 CPU 计算。压测瞬间的尖峰若没持续超过窗口，读数可能仍低于 70%。压测要稳定持续一段时间再看 HPA 状态。利用率口径理解偏差：如果你只用 kubectl top 看到“核数很高”，但 Pod 的 requests 设得更大（如 requests=2、实际用 1.5 核 = 75%），换个 requests 数值结论就完全不同。以 HPA 报告的那个百分比为准。阈值配置：确认 averageUtilization 确实写的是 70，且 targetCPUUtilizationPercentage 没被其它字段覆盖。4. 副本与调度侧排查（指标已超阈值但仍不扩）maxReplicas 已经等于当前副本数：maxReplicas: 1 或默认填小了，HPA 想扩也没有空间，改大上限。缩放冷却/延迟：HPA 有扩容稳定窗口与同步周期（默认几十秒级），刚触发时不会立刻变成新副本，稍等再看 kubectl get hpa -w。节点资源不足：HPA 只是改 Deployment 的 replicas，新 Pod 若因集群 CPU/内存不足一直 Pending，看起来就像“没扩容”。查 kubectl get pods 是否有 Pending，必要时配合节点池自动扩缩容。与其他控制器冲突：同时启用了 VPA 或外部 autoscaler 写同一工作负载的副本数，会相互覆盖，导致 HPA 的效果被抵消。二选一。5. 快速验证给容器设好 requests，用 kubectl get hpa -w 持续观察：先看 TARGETS 是否从 变成具体百分比；再用压测把平均 CPU 稳定压过 70%，正常情况下几十秒内 REPLICAS 就会往上走。若 TARGETS 正常、平均利用率也超了、上限也没卡，但就是不扩，重点查有没有 Pending Pod 或第二个 autoscaler 在抢写副本数。