补一个带算例的角度：前面几位把“先看监控、再选规格族、再算计费”讲得很全了，我补充一套能直接套用的算例和检查表。核心就一句话：CPU、内存、磁盘、带宽四项分开定，别拿一台机器的规格去包所有。一、拿一个具体业务算一遍假设一个小程序后端：日活 5000，峰值集中在晚上 2 小时，接口平均耗时 80 毫秒，单个请求分摊内存约 10MB。1. 并发：峰值 QPS ≈ 日活 × 人均请求数 ÷ 峰值秒数 ≈ 5000 × 20 ÷ 7200 ≈ 14，留 3 倍余量，按 45 QPS 规划。2. CPU：45 QPS × 80 毫秒 ≈ 3.6 核·秒/秒，峰值约 3.6 个 vCPU 在跑，加上系统开销，4vCPU 是合理起点；2vCPU 在峰值会排队。3. 内存：应用堆 2GB + 连接池和缓存 1GB + 系统 1GB，8GB 是底线，4GB 容易在高峰先 OOM。结论：这类业务从 4vCPU 8GB（通用型 1:2）起步是合理的；如果日活只有几百，2vCPU 4GB 就够了，先按真实量级算，不要凭感觉买。二、四项分开定，各自的判断标准CPU：看峰值时单核是否跑满。Java、Go 这类多线程应用看总利用率；单线程的老应用要看主频和单核性能，核数堆多了没用。内存：看峰值占用 + 堆外内存。数据库、缓存、JVM 应用的内存配比要往 1:4、1:8 去，不要按 1:2 硬套。磁盘：系统盘和数据盘分开。数据盘先看 IOPS 和增长速度：日志、数据库类业务先看 IOPS 再看容量；容量不够可以在线扩，不用一次买满。带宽：看峰值出方向流量。图片、视频、下载类业务带宽比 CPU 更先成为瓶颈；同业务的 ECS、RDS、OBS 放在同一区域/可用区，内网流量不计费。三、升配降配的检查表（按周复核，不按天折腾）CPU 峰值连续 3 天超过 75%，或 P99 响应时间持续恶化 → 升配一档；内存峰值连续超过 85% → 先查泄漏和缓存配置，再升配；CPU 峰值长期低于 20% 且内存低于 30% → 降配一档，省下的钱补带宽或备份；变更规格在控制台“更多 → 变更规格”里做，升配一般要重启生效，安排在低峰期，动手前先做快照。四、容易漏算的三笔钱弹性公网 IP + 带宽：按流量计费的业务，突发流量时带宽费可能超过机器本身；云备份和快照：按量计费，保留份数多了也是一笔钱，设好保留策略；长期闲置的测试机：按量计费关机不停费，不用的就释放，别只关机。建议上线前在费用中心设预算告警，超支先收到提醒，而不是月底看账单才发现。一句话总结：先按真实 QPS 和内存占用算出“最小够用档”，再用一周监控验证升降，最后用预算告警兜底。规格不是一次选对的，是算出来、跑出来、再调出来的。

前面几楼把认证链讲得很全了，用户名、authorized_keys、sshd 开关、密钥格式、VNC 旁路基本都覆盖了。我补充两个前面没展开的排查点，都是“密钥和密码同时被拒”时容易漏掉的。一、先确认你连的是不是这台机器密钥和密码同时被拒，还有一种可能：你连到的根本不是这台实例。弹性公网 IP 解绑后又绑到另一台实例，或者本地存的旧 IP、DNS 记录指向了别的机器时，你手上的钥匙和密码再对也没用——对方那台机器里没有你的公钥，root 也没有设过你以为的密码。验证办法：第一，控制台实例详情页核对当前绑定的弹性公网 IP，和你 ssh 命令里用的 IP 是否一致；第二，用控制台远程登录（VNC）进这台机器，看 hostname 和内网 IP 是否和你以为的一致；第三，本地执行 ssh-keyscan -t ed25519,rsa 公网IP 取服务端主机密钥指纹，和本机 ~/.ssh/known_hosts 里存的同一 IP 的指纹比对——指纹对不上，说明你连到的不是原来那台机器。二、ssh-agent 里钥匙太多，正确那把还没轮到就被服务端掐断了如果你本机 ssh-agent 里加载了很多把钥匙（ssh-add -l 能看到），ssh 默认会把 agent 里的钥匙一把一把递上去试。服务端默认 MaxAuthTries 是 6 次，试到第 6 把还没中就会直接断开，-vvv 里能看到连续几个 Offering public key 之后出现 Too many authentication failures 或者直接 Permission denied，看着像“这把钥匙不对”，其实是根本没轮到它。验证办法：ssh -o IdentitiesOnly=yes -i 你那把私钥 用户名@公网IP，只递这一把钥匙再试一次。如果这样能登进去，就是 agent 里钥匙太多的问题；平时可以把不用的钥匙从 agent 里清掉（ssh-add -D），或者在 ~/.ssh/config 里给这台机器写死 IdentityFile 和 IdentitiesOnly yes。这两点查完如果还不行，再回到 1 楼的思路：用 VNC 看 /var/log/secure 或 /var/log/auth.log 里最新那条认证失败记录，措辞会直接告诉你是哪一环拒的。

前面几楼把对时方法、信号对齐、模型侧处理讲得很全了，我补充一个前面没展开的角度：给 AI 加一道物理因果先验，再配合事后重算和训练时做时钟抖动增强——让判定对时间戳误差本身不敏感，而不是只修时钟。一、用设备的故障传播因果图给排序加约束时间戳只能给出记录顺序，不能证明因果。先把设备已知的故障传播链写出来，例如电机：轴承磨损→振动增大→摩擦生热→温度升高→电流增大。这个链的物理方向是确定的，反过来（温升导致轴承磨损）在短时间内几乎不可能。AI 排序时，先用这张图做校验：时间戳说温升先、振动后，与因果图冲突时，不应直接采信时间戳，而应把这条结论标为“顺序存疑”，提示先核查时钟偏移。这比只看时间戳先后多了一道物理防线。图可以来自设备 FMEA 或运维经验，先做关键设备、再逐步扩展，不必一次建全。二、时钟偏移事后算出来了，要重算结论并留版本很多偏移是事后才发现的，比如通过共同事件对齐后，才知道振动一路慢了十秒。这时不要只把时钟修好就完事，要用修正后的时间戳把当时的根因结论重新跑一遍，并保留两个版本：原始结论（基于未对齐数据）和修正结论（基于对齐后数据），注明偏移量和对齐方法。否则报告里留下的仍是错的先后顺序，后续复盘也分不清是现场真故障还是时钟问题。三、训练时主动注入时钟误差，做抖动增强训练数据里混进没对齐的时段，模型会把误差当特征学进去。反过来可以在训练时主动给样本注入已知的时钟偏移和漂移，例如随机让一路信号整体平移几秒，再让模型在这种扰动下仍能给出正确结论，学到的就不再是“振动先于温升多少秒”这种脆弱的绝对时序，而是变化幅度、趋势和共现关系。评估时也要用带偏移的测试集验收，而不是只用干净数据。一句话：时钟要修，但 AI 的判断不能只押在时间戳上——因果图先验防颠倒、事后重算纠历史、抖动增强防过拟合，三件事一起做，先后结论才经得起时钟漂移。

前面几楼已经把核心结论讲全了：普通关机不停算力费、关机不收费只停算力、盘和 EIP 独立计费、彻底不用要释放。我这里不重复结论，补充几块前面回答较少展开、但新手最容易踩坑的内容：一张“四种状态费用对照表”、在控制台核对账单的具体路径、关机不收费的适用边界，以及一套防“忘了释放”的收尾办法。一、先看对照表：四种状态下，到底哪几项还在收钱按量付费 ECS 的账单其实是几笔费用拼起来的：实例规格（vCPU 加内存）、系统盘和数据盘（EVS 云硬盘）、弹性公网 IP（EIP）、镜像和快照、云备份，以及其他关联资源（比如负载均衡、带宽包）。同一台机器，在不同状态下这几笔的表现完全不同：运行中：以上各项都在正常计费。普通关机（系统内执行关机，或控制台直接关机，不勾选关机不收费）：实例规格继续计费，因为 vCPU 和内存资源仍为你保留占用；系统盘、数据盘继续按容量计费；EIP 继续按购买时的计费方式计费；镜像、快照、云备份继续计费。也就是说，普通关机几乎省不下钱，只省了按流量计费的出方向流量这一小项，因为关机后基本没有流量了。关机不收费（控制台关机时勾选该选项，部分规格和区域支持）：实例规格停收；系统盘、数据盘、EIP、镜像、快照、云备份照常收。这是最容易误解的一点，很多人以为点了这个就“不花钱了”，其实盘和 IP 的钱一分不少，关机不收费省的只是算力这一项。删除实例并释放关联资源后：实例规格停收；系统盘一般随实例删除而停收，前提是创建时勾选了随实例删除，默认就是勾选的，删除确认页还要再看一眼；数据盘默认不随实例删除，仍在按容量计费，直到手动删除；EIP 解绑后不释放会产生闲置保有费，释放后才停收；快照、镜像、云备份保留多久就收多久，与实例是否删除无关。所以只看“关机”两个字判断不了花不花钱，要看你用的是哪种关机，以及盘和 IP 处理了没有。二、别凭感觉猜，花三分钟在控制台核对一遍第一步，打开控制台弹性云服务器 ECS 列表，找到这台实例，看状态是不是已关机，再点进详情核对有没有挂载的数据盘、绑定的 EIP，记下它们的资源 ID 和名称。第二步，打开费用中心，进入账单管理中的账单详情，按产品筛选弹性云服务器、云硬盘、弹性公网 IP 三项，分别看最近两天有没有新增出账；再按资源筛选这台实例、这几块盘和这个 EIP，看每一项的计费状态和金额。第三步，释放或关机操作做完后，第二天再回来查一次账单，确认这台机器相关的资源项不再产生新费用。只看一次不够，因为按量计费是按小时结算出账的，当天查可能还看不到完整结果。很多“关机了还在扣费”的疑问，查到这一步就清楚了，大概率是某一块数据盘或某个 EIP 还在计费。三、关机不收费不是万能的，四个边界条件第一，不是所有规格和区域都支持。关机时控制台有没有出现“关机不收费”这个选项，是最直接的判断标准，没有这个选项就是当前规格或区域不支持，不要硬找。第二，包年包月实例不适用这条规则，因为费用已经按购买周期付过了；竞价实例、专属主机、带本地盘等特殊类型也可能不支持或规则不同，用之前先看控制台提示。第三，关机不收费期间实例仍然占用配额，所在可用区库存紧张时，重新开机可能失败；长期关机不收费的机器不要当作免费仓库来用，数据还是要靠镜像或快照另外保存。第四，再次开机后公网 IP 可能变化，尤其是没有绑定固定 EIP 的场景，域名解析、防火墙白名单、第三方回调地址都要重新核对；需要固定出口 IP 的，先绑定 EIP 再关机。四、释放之前，先按“留数据还是留机器”做决定彻底不用、数据也不要：先备份确认，再删除实例（删除确认页勾选同时删除数据盘），然后释放 EIP，清理不需要的快照和备份，最后到费用中心核对。以后可能还要用、数据要留：别把整机留着烧钱。先做整机镜像，或者系统盘加数据盘快照，验证镜像能正常创建新实例，再释放原实例、释放 EIP、删除原盘；下次需要时用镜像几分钟重建一台，比长期留着一台关机不收费的机器划算，而且镜像的存储费用通常比整块云硬盘低。注意镜像和快照本身也收费，留一份能用的就够了，过期及时清理。只停几天、很快复用：关机不收费即可，但先评估一下 EIP 的计费方式，按流量计费的 EIP 闲置期间也可能产生保有费，不用的 EIP 直接释放，下次再申请。五、防“忘了释放”：两道保险第一道是费用预算告警。在费用中心预算管理里新建按量费用预算，设置金额阈值和短信、邮件通知；测试机专用的预算可以设得很低，一旦超支立刻能发现。第二道是定时收尾。测试环境的机器可以配合云监控告警或函数工作流做定时关机；确定不再用的，直接在日历上记一个释放日，到日子先检查一遍费用中心再释放。多人共用的测试机，删除前先和同事确认，避免删掉别人的环境。六、收尾检查清单，照着打勾就行数据已备份：镜像或快照已创建，确认过能恢复、能用来创建新实例。实例已删除，或者已按场景选择关机不收费。系统盘确认随实例删除，或已手动删除。数据盘逐块确认已删除，或已明确要保留。EIP 已解绑并释放，不再用的不留。快照、镜像、云备份只留需要的，删除过期副本。费用中心次日再查一次账单，确认这台机器的资源项不再出账。域名解析和白名单如 IP 变过，同步更新。一句话总结：前面楼层说了“关机不等于停费”，再补充一句——“停费要按资源项逐项停”：实例、磁盘、EIP、快照和备份，每一项都要在控制台确认状态，缺一项，账单上就还会多一行。

补充一个前面回答较少展开的角度：先把 df 和 du 的差额算出来，再按“块占用、命名空间、文件系统层”三类去认领这笔差额。前面很多回答讲了已删除未释放、挂载遮挡、inode、预留块，这四项查完还对不上时，往往就卡在这三类上。楼主说 lsof 没找到明显的，更值得按下面顺序走一遍。一、先做差额对账，别凭感觉找大文件很多排查是“du 一层层翻，翻到哪算哪”，没有先算差额，结果查了半天也不知道还差多少。先把数字算死：df -B1 --output=source,target,used /datasudo du -x -B1 -s /data用 df 的 Used 减去 du 的总计，就是要找的差额。注意 du 必须加 -x，只统计同一个文件系统；不要用 du -sh /data/*，这样会漏掉隐藏目录，也不要把报错丢掉，权限不足被跳过的目录最容易漏统计，报错本身就是线索。如果差额只有几百 MB，可能是小文件尾部和元数据累积；如果差额是几十 GB，一定有整块的“看不见的占用”，继续往下查。二、稀疏文件：ls 看着很大，du 看着很小，或者反过来7 楼提过一句稀疏文件，这里展开说，因为它最容易把人绕晕。du 统计的是实际占用的数据块，ls -lh 显示的是逻辑大小，两者本来就不是同一个口径：ls -lhs /data/bigfiledu -h /data/bigfiledu --apparent-size -h /data/bigfile一个用 fallocate 预分配、或者虚拟机磁盘镜像、数据库预分配文件，逻辑大小可能远大于实际占用；反过来，一个小文件占满一个 4K 块是常态，海量小文件时，块尾部浪费加起来也很可观。找这类文件不要只按 ls 的大小排序，要按块占用排序：sudo find /data -xdev -type f -printf '%b %p\n' 2>/dev/null | sort -rn | head -20其中 %b 是 512 字节块数，最能反映真实占用。如果发现某个 qcow2、vmdk、ibdata1、或者应用的预分配文件占了大头，先确认它是业务数据还是可以安全清理的临时文件，不要直接删数据库的数据文件。三、容器和命名空间：宿主机上的 lsof 可能根本看不到它如果这台 ECS 跑了 Docker 或者其他容器，宿主机上的 du、lsof 看到的只是宿主机命名空间的视图。容器里一个进程删了文件但还持有句柄，宿主机 lsof 不一定能对应上；反过来，容器里写的文件可能落在 overlay 的上层目录里，du 在宿主机上要到 /var/lib/docker/overlay2 下面才看得见。先确认是不是容器在占空间：docker system dfsudo du -sh /var/lib/docker/overlay2 2>/dev/null | sort -rh | headsudo ls -lhS /var/lib/docker/containers/*/*-json.log 2>/dev/null | head更关键的是进容器命名空间里再查一次已删除文件。用 nsenter 进到可疑容器的挂载和进程命名空间，或者直接 docker exec 进容器里跑 lsof +L1，对照宿主机上的结果。只在宿主机上查一遍就下结论“没有已删文件”，在有容器的机器上是不可靠的。容器日志没有轮转时，单个 -json.log 涨到几十 GB 非常常见，清理时用 truncate -s 0 截断，不要直接 rm 正在被写的日志文件。四、文件系统层：预分配、延迟分配与孤儿 inode即使目录树里没有任何大文件，文件系统本身也可能还占着块。常见有三类：第一是应用用 fallocate 或者数据库预分配了空间，文件删了、句柄也关了，但预分配的块要等文件系统回收；第二是写操作用了延迟分配，数据还在内存里没落盘，df 的统计和实际落盘进度有时间差，这时过几分钟再看 df，数字可能会自己回落；第三是文件系统元数据损坏或孤儿 inode，文件删了但 inode 没有正确释放，这种情况 du 永远查不到，只能用文件系统检查工具看。对 ext4 可以先只读看一眼超级块和已分配块的大致情况：sudo tune2fs -l /dev/vda1 | grep -E 'Block count|Free blocks|Reserved block'sudo dumpe2fs -h /dev/vda1 2>/dev/null | head -30如果是 xfs，用 xfs_db 看分配组的使用情况。如果怀疑是孤儿 inode 或者元数据损坏，不要在业务盘在线的情况下直接跑 fsck 修，这类操作要在维护窗口、卸载文件系统或者以只读方式挂载后做，修之前先对云硬盘做快照备份。凡是涉及到“修文件系统”的步骤，都先备份再动手。五、云盘特有：扩容了磁盘，文件系统没扩ECS 上还有一个高频坑，和 df、du 的口径都无关：云硬盘在控制台扩容后，如果没有执行 resize2fs 或者 xfs_growfs，df 显示的还是旧容量，容易误判成“du 找不到大文件”。反过来，如果根分区是 LVM，物理卷扩了、逻辑卷没扩，或者 thin pool 的元数据满了，表现也很像“空间被谁占了”。核对链路要完整：控制台云硬盘容量、lsblk 看块设备大小、pvdisplay、lvdisplay、df -hT 看文件系统大小，四层数字要对得上。哪一层断了，就在那一层扩：lsblk -fsudo pvdisplay | grep -E 'PV Name|PV Size|Free PE'sudo lvdisplay | grep -E 'LV Path|LV Size'sudo resize2fs /dev/vda1只在控制台扩容、不扩文件系统，是新手最容易重复踩的坑。六、安全清理的顺序，别越清理越危险定位到占用之后，清理也有顺序。先做快照或者备份，再动手；先处理日志、临时文件、缓存这类可再生的东西，最后再碰业务数据；正在被进程写的文件用截断而不是删除，删了也不会立刻释放，反而可能让应用写到一个不存在的文件描述符上；数据库的数据文件、正在运行的虚拟机磁盘镜像，绝对不要直接 rm。清理完之后，把防复发也做掉，否则下个月还会再满一次：给 journal 设上限，给容器日志配轮转，给应用日志配 logrotate，给磁盘使用率配告警（比如 80% 告警、90% 紧急），再加一个每周跑一次的 du 巡检，把顶层目录的大小变化记下来。这样下次 df 再报警，你手里有上周的基线，一眼就能看出是哪一层目录突然涨起来的。总结一下这条补充链路：先算 df Used 减 du 的差额，锁定要找的数量级；再查稀疏文件和按块排序的大文件；有容器就进命名空间里再查一遍已删文件和 overlay；然后看文件系统层的预分配、延迟分配和孤儿 inode；最后核对云硬盘、LVM、文件系统三层容量是否对齐。按这个顺序走，差额基本都能认领到具体的某一项上。

补充一楼的回答，讲一个现场能直接用的“先判别、再算账、最后做预检”的做法，避免下次滚动发布又卡在同一个地方。一、先判别：insufficient ENI、子网 IP 不足、残留占用是三种不同的卡法1. insufficient ENI：单节点 ENI 配额打满。看节点上已绑定的弹性网卡数是否到了该 ECS 规格的上限，Pod 分布是不是集中在个别节点上。2. 子网 IP 不足：报错一般是 failed to allocate IP。去 VPC 控制台看容器子网的“可用 IP 数”，如果节点、ELB、Pod 都挤在同一个子网，Pod 还没到 ENI 上限，IP 先被别的资源占满了。3. 残留占用：Pod 已经删了，但网卡没及时释放。重点查处于 Terminating、Failed 状态的 Pod，以及滚动发布中旧版本迟迟不退出的 Pod，删 Pod 腾 ENI 只是临时止血，这类残留不清理，腾出来的位置很快又会被占回去。现场判别可以用这两条命令：kubectl get pods -A -o wide | awk '{print $8}' | sort | uniq -c | sort -rnkubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.status.allocatable.pods}{"\n"}{end}'第一条看 Pod 在各节点上的分布，第二条看每个节点的 Pod 上限（Turbo 下这个上限和 ENI 配额直接相关）。如果某个节点的 Pod 数已经贴近 allocatable.pods，就是它先满了。二、再算账：发布前先算三笔数1. 节点池能装多少 Pod：节点数 ×（单规格 ENI 上限 - 主网卡 1 - 预留 1）。按楼主的 3 节点、每节点约 10 个算，满打满算 30 个左右，60 个 Pod 的业务本来就装不下，滚动发布时 maxSurge 再多出几个新 Pod，必然先卡住几个。2. 滚动发布峰值 Pod 数：副本数 + 副本数 × maxSurge。先算峰值，再拿峰值去对照第一条的容量，而不是拿平稳期的 60 个去对照。3. 子网要留多少 IP：Pod 峰值数 × 1.5，再加上节点、ELB 等其他资源要占的 IP。容器子网建议单独划，不要和节点子网混用，/24 留给 60 个 Pod 加扩容余量确实偏紧，扩到 /23 更稳妥。三、发布前预检清单（每次滚动发布前跑一遍）1. 每节点 Pod 数 / 该规格 ENI 上限，超过 80% 就先扩节点池，别直接发布。2. 容器子网可用 IP 数，大于峰值 Pod 数的 1.5 倍再发布。3. 预热池只解决“发布时 ENI 创建慢”，不解决“配额不够”，预热数按一次发布最大并发新增 Pod 数配，一般取副本数 × maxSurge，配 5~8 个就够了，配多了只是白占子网 IP。4. 清理 Terminating、Failed 状态的 Pod，确认没有残留占用再发布。长远看，60 个 Pod 用 3 个 8C16G 节点本来就不匹配，最稳妥的是加节点（或换 ENI 上限更高的规格）把单节点 Pod 数压到上限的 70% 以下；如果以后还要继续扩副本，再评估新建 Trunk 模式的节点池做迁移。只删旧 Pod 重试，治标不治本。

平衡成本与性能，关键是先量化负载、再按需选型、最后用弹性兜底，而不是一开始就买大规格。一、先看负载画像再选规格。用云监控看业务一周的 CPU、内存、磁盘 IO、带宽的均值和峰值：CPU 长期跑满、内存利用率低，说明瓶颈在计算；反之则是内存。不同业务适合不同系列：Web 应用、小型数据库选通用型（vCPU:内存约 1:2 或 1:4）；视频编码、游戏、科学计算等 CPU 密集型选计算型；缓存、内存数据库选内存型（约 1:8）；流量低且波峰不确定的轻量业务可以用突发性能型，但不要拿它当长期主力扛持续高负载。二、从小起步、留出弹性。先按均值加 30% 余量选型，峰值通过弹性伸缩或临时升配兜底，比长期买大规格便宜得多。稳态业务优先包年包月或预留实例，波动大的部分用按需计费；另外磁盘按实际 IO 选云硬盘类型，带宽按业务峰值选，不够再升，初期不必一次买满。三、定期复核。每月看一次监控：CPU、内存长期低于 20% 就降配，频繁超过 70% 或出现排队就升配；业务扩容优先横向加节点而不是一味纵向加配置，这样单台故障影响也更小。一句话：用数据定规格，用弹性扛峰值，用包年包月省稳态成本。

先说结论：一楼说得对，提交页一般没有向选手开放的自助删除。我再补充一个关键点：先分清错的是草稿还是最终版，再决定怎么处理，两者的后果完全不同。一、先区分错的是哪一份1. 在大赛官网“我的作品/提交记录”里核对两条记录的状态、作品名称和提交时间。草稿只是暂存，一般不进入评审；只有状态为“已提交”的最终版才会进入评审。2. 如果错的只是草稿里的内容，而最终版是你正确的作品，那基本不影响评审，不用处理。3. 如果错的是最终版，再看第二步。二、最终版错了，提交入口还开着就先覆盖1. 很多赛道在截止前允许重新提交，系统一般以最后一次提交为准——先按要求重新提交正确作品，再截图留存新的提交时间和作品名。2. 不同赛道规则不一样，提交前先看该赛道的参赛须知、FAQ，确认是否允许重复提交、是否以最后一次提交为准；不要连续多次重复提交。三、不能重新提交时，找官方后台处理1. 通过大赛官网的“联系我们/在线客服”，或在本论坛“华为开发者大赛”板块发帖说明，提供赛道、团队名或报名手机号、误提交的作品名称与提交时间、正确作品的名称，申请由官方在后台撤回或删除误提交的作品。2. 保留沟通记录和工单号，尽量在提交截止和评审开始前联系，越临近截止可改动的余地越小。四、两点提醒1. 不要注册小号重新报名：同一选手多账号参赛可能违反赛规，严重的会被取消资格。2. 以后提交前，先在草稿里逐项核对作品文件、赛道、赛区，确认无误再点最终提交。

补充一个可以直接照着落地的角度：前面几楼把场景分类和选型方法讲得很全了，我给一个“最小可跑”的完整链路——一段 Python 处理函数骨架 + 控制台上的接线步骤 + 常见翻车点，照着做半天就能跑通。一、一段能直接参考的 Python 函数骨架（OBS 上传触发缩略图）import jsondef handler(event, context):    body = json.loads(event) if isinstance(event, str) else event    for record in body.get("Records", []):        bucket = record["obs"]["bucket"]["name"]        key = record["obs"]["object"]["key"]        if not key.startswith("raw/"):            continue  # 只处理原图前缀，避免循环触发        # 1. 用 OBS SDK 下载原图到 /tmp        # 2. 生成缩略图（200px），上传到 web/ 前缀        # 3. 把 web/ 地址写入数据库，写库时用对象 key 做唯一键去重        #    函数可能因超时被重试，写库必须幂等    return {"statusCode": 200, "body": "ok"}说明：event 是 OBS 事件通知的 JSON 字符串，字段结构以平台文档为准；AK/SK 别写进代码，用 IAM 委托给函数授权。二、控制台上的接线步骤（缺一不可）1. 先给函数建一个 IAM 委托，只授权读 raw 桶、写 web 桶，最小权限。2. 在函数上创建 OBS 触发器，事件选“对象创建”，前缀过滤填 raw/，只有新原图上传才触发。3. 内存和超时按实测设置：图片处理偏 CPU 和内存，内存从 512MB 起步测，超时按最慢一张图的耗时乘 2 配，不要用默认值硬扛。4. 日志接到云日志服务，按请求 ID 查；函数实例用完就回收，事后登不上机器查。三、容易翻车的四个点1. 循环触发：函数写回同一个桶、同一前缀会再次触发自己，结果是无限递归。处理完必须换桶或换前缀。2. 数据库连接打满：函数瞬间扩到上百并发，每个并发都新建一条数据库连接，RDS 连接数会先扛不住。办法是限制函数并发上限，或在前面加消息队列削峰，数据库侧可用读写分离代理做连接复用。3. 超时重试导致重复写库：重试是“至少一次”语义，写库、发消息、扣减库存都必须用业务唯一键做幂等，不能假设只执行一次。4. 定时触发器的时区：定时触发器默认按 UTC 走，配 cron 时要先换算成北京时间，否则每天凌晨 3 点的任务会在上午 11 点跑。一句话：函数适合“事件触发、单次几秒、无状态、流量起伏”的逻辑，照着上面接线、把幂等和并发上限先处理好，就能直接上生产。

补充前面回答里较少提到的三类坑，都是“能上传、能打开”之后才暴露的。 一、上传后行为不对，先查 Content-Type 而不是权限。图片、PDF、视频上传时如果没有正确设置 Content-Type，浏览器可能直接下载而不是在线预览，视频也无法边下边播。上传前按文件类型显式设置，例如图片 image/jpeg、PDF application/pdf，上传后用对象地址直接访问验证一次，再看 CDN 侧是否还需要刷新缓存。 二、同名覆盖和删除不可逆，不要只依赖“还能下载”。同名对象上传会覆盖旧对象，删除对象后如果没有开启版本控制就无法找回。重要数据先开启版本控制，删除操作先在测试桶验证，生产桶的删除和覆盖要有审批或二次确认，关键文件另外做跨桶或跨区域备份，而不是只靠一个桶里的副本。 三、不要把 OBS 当追加式日志或数据库用。对象存储不支持对已有对象做追加写，频繁改写小对象、把每次日志都写成一个新对象，会导致对象数量暴涨、请求费用上升。日志类场景先在本地或 ECS 上按时间聚合，再定时批量上传；需要频繁修改的数据放在数据库或文件系统里，OBS 只存最终归档结果。 自查顺序建议：先确认 Content-Type 和访问方式，再确认版本控制与删除保护，最后看写入模式是否适合对象存储。这样能避开一批在测试时看不出来、上线后才发现的问题。