先说结论：前面几楼把“为什么错、怎么预防”讲得很全了，这里补充一个前面没有展开的实操角度：已经攒了一堆时间戳对不上的历史数据怎么办。我的做法是“先量化偏移、再事后纠正、最后复算复核”三步，而不是直接把这段数据扔掉——扔掉数据等于扔掉了复盘的证据。一、先量化：每台设备到底偏了多少1. 找共同事件：断电、网关重启、人工触发的已知脉冲，对比各设备日志里这个事件的时间戳，相对偏移一目了然。2. 分清两种误差：固定偏移（一直差固定秒数）和漂移（误差随时间线性增大）。看 chrony 的 tracking 日志（offset、漂移率、最近一次同步时间），再按两次对时之间的漂移率拟合一条直线，漂移就能量化。3. 注意跳变点：NTP 大偏移 step 校时会让时间倒退、同一秒出现两次，跳变点前后要分段处理，不能用一条直线硬拟合整段。二、再纠正：给历史数据打补丁，原始数据不动1. 原始数据原样保留，另存一份纠正后的副本，并记录纠正用的偏移参数和参数版本，复盘时能追溯到是哪一版对齐结果。2. 固定偏移整段平移；漂移按拟合的漂移率做线性插值纠正；跳变点前后分段纠正。3. 纠正后复查：用同一个共同事件再对一次表，确认各路时间戳对齐到容忍范围内（比如 500ms）；对不齐的时段标“顺序不确定”，不参与根因排序。三、最后复算：用纠正后的数据重跑一次诊断1. 重跑根因排序，对比纠正前后的结论是否一致；如果结论翻转了，说明原结论就是时钟误差造成的，要以纠正后的为准，并在报告里写明。2. 报告里附上各路信号的偏移估计值和同步状态：误差小于事件间隔，结论才成立；误差大于间隔，只能写“同时段异常”，不能硬排先后。3. 把经验固化下来：chrony 的 offset 接入监控、偏移超阈值告警、设备上线检查清单里加授时配置复查，固件升级后也要复查一次。一句话：时钟修好是治本，历史数据要靠“量化偏移—事后纠正—复算复核”三步救回来；纠正参数留档，结论才可复现。

先说结论：本地能登录只证明“本机这条路”通了。业务连不上时别同时改几处，先把连接链画出来，一段一段打勾，改一处验证一次。一、先画连接链，再逐段验证1. 业务配置段：核对业务配置里的主机、端口、库名、账号、密码，和数据库实际是否一致；确认改的是线上正在跑的那份配置——多副本、多环境、容器镜像内置旧配置最常见，改了测试环境、线上还是旧密码。改完要重启业务或重建连接池，否则旧密码还在连接池里。2. 业务机直连段：在业务所在机器上，用业务账号、业务要连的地址和端口实际连一次：mysql -h 数据库内网IP> -P 3306 -u 业务账号> -p。这里能连上，问题基本在业务配置或连接池；这里也连不上，再往数据库侧查。3. 报错定性段：先把业务完整报错记下来再动手。1045 Access denied 走账号侧；2003 或连接超时走网络与监听侧；1049 Unknown database 走库名与授权侧；握手失败先看认证插件与客户端版本。不看报错就改配置，等于盲改。4. 同一实例段：登录 MySQL 后执行 SHOW VARIABLES LIKE 'port'; SHOW VARIABLES LIKE 'datadir'; SHOW VARIABLES LIKE 'socket'; 再执行 ss -tlnp | grep 3306，看业务配置里的主机和端口是不是和这里一致。同一台 ECS 上可能同时有包安装的 MySQL 和容器里的 MySQL，改了 A 实例、业务连的是 B 实例时，后面改什么都没用。5. 账号与授权段：执行 SELECT user, host FROM mysql.user; 确认业务账号存在，host 包含业务机 IP 或 %，同时确认账号没有被锁定、密码没有过期。注意 root@localhost、root@127.0.0.1、root@% 是三个不同的账号，重置 root 密码不等于改了业务账号的密码。6. 监听与网络段：确认 MySQL 没有开 skip-networking，bind-address 不是只绑 127.0.0.1；在业务机上用 telnet 或 nc 测 3306 是否通；检查 ECS 安全组和本机防火墙是否放行了业务来源的 3306。内网业务优先走内网 IP，公网 3306 不要长期放开。7. 生效配置与日志段：MySQL 可能读多份配置文件，改了 /etc/my.cnf 不一定是运行实例读的那份，用 mysqld --verbose --help | grep -A1 'Default options' 看读取顺序，改完一定要重启 MySQL 再验证。再用 SHOW VARIABLES LIKE 'log_error'; 找到错误日志看一眼：业务日志往往只写“连接失败”，错误日志里才分得清是认证被拒、连接数满还是启动异常。二、两个容易被忽略的小坑一是新密码含 #、$、!、@ 等特殊字符时，在 shell、YAML、JDBC URL 里可能被转义或截断，数据库里存的和业务传的不是同一个字符串，先换一个不含特殊字符的临时密码验证。二是用 skip-grant-tables 方式重置后，一定要恢复正常启动并执行 FLUSH PRIVILEGES，只在跳过授权的状态下验证通过不算数。建议顺序：记报错 → 业务机直连复现 → 按上面七段逐段打勾 → 每改一处复现一次。按这张表走一遍，基本能定位到具体哪一段。

先说结论：有，是电子版证书。领奖金的时候没收到是正常的，这不能说明没有证书，更不影响获奖资格，原因在于奖金和证书根本不是同一条发放线。一、奖金和证书为什么不同时到奖金走的是领奖流程：获奖后按要求提交领奖信息，等审核、走财务打款，整个过程和证书制作没有关系。证书走的是赛后发放流程：组委会要等最终获奖榜单公布后，再统一制作证书，然后通过报名时留的邮箱发给获奖队伍。两件事由不同的环节负责，时间自然不同步。所以只看“领奖金时有没有顺带收到证书”来判断有没有证书，是不准确的。二、第一步：先确认自己在不在最终获奖榜单这是最关键的一步，别跳过。去大赛官网或者论坛公告里找你参加的那一期的最终获奖榜单，核对队名和获奖名次。榜单还没公布，就只能先等着，证书要等榜单出来之后才会安排；榜单里没有自己的队名，那就没有证书，只有进入最终获奖名单的队伍才有。先把这一步确认清楚，后面的等待和催问才有依据。三、榜单已出之后，怎么等证书榜单公布后，留意报名时留的邮箱，团队赛一般是队长报名时填的那个邮箱。证书不会当天就到，通常要等组委会统一制作和发送，需要一段时间。查邮件时注意两点：别只看收件箱，垃圾邮件和广告邮件文件夹也要翻一翻，带附件的证书邮件很容易被误判；确认邮箱地址本身没填错，如果报名时邮箱写错了，证书自然发不到你手里。收到证书后及时把原文件下载保存好，电子版可以自行打印。四、等了很久还没收到，怎么核对补发如果榜单已经公布一段时间、奖金也领了，邮箱里还是没有证书，就别干等了，主动去核对。建议先把信息准备齐再联系：参赛队名、参加的期次、获奖名次、报名时留的邮箱、获奖人姓名。带着这些信息，在论坛私信版主“赛事资讯小助手”，请对方帮忙核对。信息给得越全，对方核对得越快；如果只发一句“没收到证书”，对方还得来回追问队名和期次，反而耽误时间。拿到证书后也要核对姓名、奖项和期次有没有写错，有错尽早反馈更正。最后提醒一句：证书和奖金的发放都以最终获奖榜单和官方邮件为准，论坛里其他帖子的说法只能作为参考，不同期次的流程细节也可能有调整。按上面“先查榜单、再等邮件、最后带齐信息私信核对”这个顺序处理，一般都能解决。

1 楼、7 楼、8 楼已经把公开渠道、验货方法和资产管理讲得很透了，我补充一段前面没展开的：在云上怎么把抽取—清洗—入库这条链路跑起来。 一、先把存算分开，别在本地堆 PDF1. 原始 PDF 统一放 OBS 一个桶里，按来源和批次分目录，例如 raw/arxiv/2026、raw/gov/2026；抽取后的文本放另一个前缀 clean/。抽取失败可以单独重跑，不用重新下载。2. 每个批次留一份清单：来源、许可类型、下载时间、文件哈希、抽取工具版本。某个来源要下架或某批质量出问题时，按清单处理，和 8 楼的资产管理思路是一回事。 二、在云上跑抽取，分两步走1. 先在 AI 开发者空间 DevKit/Notebook 里小样本验证：装 PyMuPDF、pdfplumber，拿 20 个文件抽一段正文人工看一眼，确认双栏、表格、水印的处理效果，再决定全量用哪个工具；扫描件才上 OCR，别一上来就全量 OCR，成本差一个量级。2. 文件量上万以后再上 ModelArts 批量作业：按文件分片跑，每片输出一个 JSONL，失败的分片单独重跑，不用全量重来。 三、入库前三个检查点1. 先算 token 账再囤数据：按 7 楼的算法，20 页 PDF 正文约 1 万 token，目标多少 token 就先算清需要多少文档。2. 去重要做两层：文件 MD5 精确去重，再用 MinHash 做近似去重（阈值可参考 1 楼的 0.8），否则同一份白皮书几十个站点各存一份，模型会反复记同一段。3. 每批随机抽 100 条人工读一遍，重点看乱码页、目录页、页眉页脚残留，自动指标发现不了这些。 四、成本上容易忽略的两笔OBS 存储、流出流量和请求次数都要算；OCR 和向量化是算力大头，先在小样本上测准确率和单价，确认有效再全量。 一句话：现成语料解决起步量，云上跑通抽取—清洗—去重—入库之后语料才真正能用；先小样本验证、再算 token 账、最后扩规模，顺序别反了。

结论先说：只关机不能保证完全停费，关键看两点——你用的是哪种关机、以及这台机子还挂着哪些独立计费的资源。确定彻底不用了，正确收尾是“备份→删除实例→释放 EIP 和多余的盘→去费用中心核对”，而不是只点一下关机。 一、先分清两种“关机”1. 在系统里执行 shutdown / poweroff，或控制台普通关机：操作系统停了，但实例占用的 vCPU、内存资源仍为你保留，按量计费一般继续收，这是很多人关机后还看到扣费的原因。2. 控制台关机时勾选“关机不收费”（部分规格、区域支持，关机弹窗里会提示）：关机期间 vCPU、内存、镜像不再计费。注意这是关机方式决定的，不是所有实例、所有区域都有这个选项，关机前先看弹窗说明。 二、关机也停不掉的费用1. 云硬盘：系统盘、数据盘只要盘还在，就按容量持续计费，与开机关机无关。删除实例时系统盘一般随实例删除，数据盘默认不随实例删除，删完实例要到云硬盘控制台再确认一次。2. 弹性公网 IP：EIP 是独立资源，绑着实例时按带宽/流量计费，解绑后不释放还会收闲置保有费，不用了一定要到“弹性公网 IP 和带宽”里释放。3. 快照、镜像：做过整机镜像或云硬盘快照的，超出免费额度的部分也会持续计费，长期不用的要清理。 三、建议的操作顺序1. 先备份：重要数据做整机镜像或云硬盘快照，确认备份能用再删。2. 只是暂停、以后还要用：控制台选“关机不收费”关机，数据保留在盘里，下次开机就能用；同时把不需要的 EIP 释放掉。3. 确定彻底不用：控制台删除/退订实例，勾选同时删除数据盘（或删完再去云硬盘里手动删），再释放 EIP、清理快照，最后到费用中心按产品核对一次，确认没有持续出账的资源。4. 顺手设一个费用预算告警，按量付费最容易栽在“忘了释放”上。 一句话：关机是暂停使用，释放才是停止计费；测试机用完，备份后删实例、清 EIP 和盘，再对一次账单，才算真正收尾。

前面楼层已经把已删未释放、挂载遮挡、inode 耗尽、预留块这四个经典原因讲得很全了，你也说 lsof 没查到明显的。我补充三个在 ECS 上容易被漏掉、楼上没有展开的检查点，按顺序查一遍，基本能把 df 和 du 的差额“算账”算出来。 一、稀疏文件和预分配文件：块占用不等于逻辑大小6 楼只提了一句，这里展开一下。du 统计的是实际占用的数据块，ls -lh 显示的是逻辑大小，两者对不上时要反过来想：虚拟机磁盘镜像、数据库预分配文件、用 fallocate 预分配的日志文件，逻辑内容可能很小，但块已经全占了；反过来，稀疏文件是逻辑看起来很大、实际占块很小。直接对比同一批文件就能看出来：du -sh /datadu -sh --apparent-size /datafind /data -xdev -type f -printf '%b %p\n' 2>/dev/null | sort -rn | head -20如果某几个文件的块数（第一列，单位 512 字节）明显偏大，就先确认它们是什么业务在用，再决定是截断、迁移还是调小预分配。 二、容器命名空间里的已删文件：宿主机 lsof 可能查不到如果这台 ECS 跑了容器，容器里被 rm 的日志在宿主机上不一定能用普通 lsof 看到，因为容器有自己的挂载命名空间，文件删在容器 overlay 层的上层目录里。换个姿势查：docker exec 容器名或ID> lsof +L1nsenter -t 容器主进程PID> -m -p find /proc -lname '* (deleted)' 2>/dev/null | head同时看一眼 overlay 层和容器日志：docker system df -v 和 du -sh /var/lib/docker/overlay2/* | sort -rh | head。确认是容器里的已删文件后，在容器内用 : > /proc//fd/ 截断，或重启对应容器，不要直接在宿主机上删 overlay2 下的文件。 三、确认你查的路径真的在满的那块盘上ECS 上常犯的一个低级错误：df 显示满的是 /，du 却一直在查 /data（另一块云硬盘），两边根本不是同一块盘。先对照：lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTdf -hTsudo du -x -d1 -h / 2>/dev/null | sort -rh | headdu 加 -x 是关键：只统计当前文件系统，不跨挂载点，否则 /data 的数字会混进根分区的结果里。确认挂载点后，再对满的那块盘逐层往下钻。 最后给一个核对公式：df 的 Used ≈ du 可见总计 + 已删未释放 + 被挂载遮挡 + 文件系统元数据与预留块。逐项打勾，哪一项数字最大，凶手就是谁。清理之前先确认文件归属和业务用途，正在写的生产日志不要直接 rm，用 truncate 或 logrotate 处理，删错了比磁盘满更麻烦。

前面几楼已经把“适合什么形态”讲得很全了，我补充一个前面没有展开的落地方向：别只停留在场景清单，先用一条最小链路把 FunctionGraph 跑通，再决定要不要扩大使用。这样能直接验证冷启动、超时、权限和成本，而不是凭感觉选型。 以最常见的“对象存储上传后自动处理”为例，链路可以这样搭： 1. 先定触发器和输入：用 OBS 对象创建事件触发函数，函数入参里只取桶名、对象键和大小，不要把整个文件读进内存。第一步先做校验：扩展名、大小上限、是否重复对象键，不合格直接记日志返回，不要往后传。2. 再做处理和落库：校验通过后才做转码、生成缩略图或格式转换，处理结果写回另一个 OBS 桶或前缀；同时把“对象键、处理状态、耗时、结果地址”写一条记录到数据库或表格里，方便后续对账。不要把处理结果只放在函数日志里，日志翻起来很难对账。3. 最后做通知和兜底：处理成功后发一条 SMN 或写一条消息队列通知下游；处理失败要区分“可重试”和“不可重试”：临时网络、限流类错误可以重试，参数错误、文件损坏类错误不要无限重试，直接进死信或人工队列，并把原始对象键和报错写进记录。4. 权限按最小化配：给函数用的 IAM 委托只允许读源桶、写目标桶和写数据库/发通知，不要直接给账号级大权限；先在测试桶里跑通，再切到正式桶。 落地前建议先压三项指标，再决定这条链路是否适合长期用函数承载： - 单次执行耗时是否稳定在超时限制内，大文件要先分片或改异步分段处理，不要让一个函数扛全量任务。- 并发上来后，下游数据库连接数、目标桶写入频率是否扛得住；扛不住就加队列削峰或改批量写入。- 同一个对象被重复触发时，结果会不会重复写入或重复扣费；落库前用对象键做唯一键或幂等标记，是最省事的做法。 一句话总结：FunctionGraph 最适合先从“一个触发器、一次处理、一条记录、一次通知”这样的小链路开始验证，跑通后再按触发来源扩展到定时任务、Webhook 和轻量接口；链路越小，冷启动、超时和成本越容易算清楚。

前面几楼已经把权限、区域、版本控制、生命周期、CORS 和 CDN 缓存讲得很全了，我补充几个新手在“能上传、能打开”之后还容易踩、且排查时容易漏的点，侧重点不同，供对照参考。 一、存储类别选错，文件不是打不开就是取回很慢新建桶或上传时，存储类别要按访问频率选，不要默认全选标准存储。热数据用标准存储；一个月访问几次的备份、日志用低频访问存储；基本不访问、只做归档的用归档存储。最容易踩的是：把冷数据放进归档存储后，又按普通对象直接下载，结果取回要等很久甚至报错。正确做法是先对归档对象做恢复操作，等恢复完成后再下载，并注意归档取回本身也有费用和最短存储时长，频繁删改冷数据反而更贵。上线前先在测试桶里放一个归档对象，完整走一遍“恢复—下载—计费”再定策略。 二、同一个区域，Endpoint 用错也会慢或报错区域选对还不够，Endpoint 也要和访问位置对应：在华为云 ECS 内访问同区域 OBS，优先用内网 Endpoint，走内网不收外网流量，速度也更稳；从本地电脑、公司网络或跨区域访问时，只能用公网 Endpoint。排查时可以对照三点：桶所在区域、代码或工具里配的 Endpoint 域名、访问方是在云内还是云外。如果同一段代码在 ECS 上很快、在本地很慢或报连接问题，先核对 Endpoint，而不是先放宽桶权限。 三、静态网站与防盗链，要先定“谁能看、从哪看”如果用 OBS 做静态网站托管或图片直链，常见问题不是文件没传上去，而是入口配错：静态网站托管要单独开启并指定索引文档和错误文档，只上传文件是不够的；只想让自己网站引用图片时，要在桶策略或防盗链里限制 Referer 来源，而不是把桶改成公共读。建议顺序是：先确认桶仍为私有，再用临时签名链接给单人分享；需要长期公开的静态资源，单独建一个公开桶并只放公开内容，业务数据和公开资源不要混在一个桶里。 四、大文件上传，重点在分段与失败清理超过 100MB 的文件不要用单次上传硬扛，网络一抖就得重传。正确做法是走分段上传：按固定大小切分、并行上传各分段、最后合并完成，并开启 SDK 的重试和断点续传；上传程序异常退出后，要定期清理未完成的分段，否则这些碎片会一直占用存储并计费。自查清单可以是：分段大小是否合理、失败分段是否可重传、未完成上传是否定期清理、最终对象大小和本地文件大小是否一致。 五、计费不要只看存储量新手常以为“存了多少就收多少”，实际上 OBS 的费用还包括请求次数、外网流出流量、归档取回和跨区域复制等。排查账单时，先看费用中心里 OBS 的费用构成，再对应到桶和操作：如果请求次数异常高，往往是程序在循环列对象或高频小文件读写；如果外网流量异常高，往往是图片、视频被公开链接大量拉取，这时要先收紧公开访问和防盗链，而不是先扩容。 一句话总结：权限和区域是第一道门，过了这道门之后，再按“存储类别、Endpoint、公开入口、分段上传、费用构成”这五项逐项核对，大多数新手问题都能在不动生产数据的前提下定位。

补充一个前面几楼讲得较少、可直接照着算的落地方案：用一个具体小业务把“峰值、基线、扩容”算出来，再把结果变成弹性伸缩策略，而不是凭感觉定规格。 一、先用一个算例定基线假设是一个小型 Web 应用加数据库：平时约 200 并发，活动峰值约 800 并发，单实例压测能稳定支撑约 300 并发。那么基线至少要 1 台撑平时负载，峰值需要约 3 台，留 1 台冗余，峰值目标就是 4 台左右。先算出这个“平时几台、峰值几台”，再去选单机规格，顺序不要反。 二、单机规格按瓶颈定，不要只加核数先看压测时先到瓶颈的是哪一项：CPU 先跑满选计算型，内存先吃紧选内存型，磁盘等待高先看磁盘类型和 IOPS，网络先满先看带宽。只加核数解决不了内存或磁盘瓶颈，钱花了问题还在。 三、把峰值交给弹性伸缩，而不是常驻大规格在控制台的弹性伸缩中可以这样配：伸缩组最小 1 台、最大 4 台，期望 1 台；新增告警规则，CPU 平均值连续 5 分钟超过 70% 就加 1 台，低于 30% 持续一段时间就减 1 台；冷却时间设 300 秒左右，避免刚扩容又缩容来回抖动。数据库这类有状态服务不要放进同一个伸缩组，要单独定规格和备份。 四、上线后每月做一次复核每月固定看一次云监控和账单：CPU 长期低于 20% 的降一档，经常超过 80% 的升一档或加副本；闲置测试机及时关停或释放；把基线部分按长期稳定量转为包年包月，波动部分继续按需加弹性伸缩。 一句话：先算平时与峰值各需要几台，再按瓶颈定单机规格，最后用弹性伸缩和月度复核兜底，成本就不会长期为峰值买单，峰值来了也不会直接卡住。

针对你说的这个现象补充一个角度：旧连接能跑、新服务和后台任务连不上，往往不是数据库彻底死了，而是“新连接的名额被先占满了”。前面几楼的排查顺序很全，这里重点说怎么先让新服务恢复、再分清是谁在占名额，避免一上来就重启或调大上限。一、先判断是数据库满了，还是应用池等不到连接新服务起不来时，先看两边日志，不要只看数据库一侧：如果应用日志里是获取连接超时、排队等待，可能是应用池本身已满或连接迟迟不归还；如果数据库侧明确报 Too many connections，再按数据库满来处理。两者处理方向不同，前者先查应用池和重试逻辑，后者先查占用分布。二、给新连接留一条路：先停非核心、再放核心高峰期先暂停可以延后的后台任务和报表任务，这类任务往往一次开很多连接，又不直接影响在线交易。停掉之后，观察新连接是否恢复：如果恢复了，说明问题出在连接分配上，而不是数据库性能本身。恢复后，再按优先级分批放行任务：核心交易先放，报表和批量任务放到低峰或限速执行，并给不同任务用不同账号，这样下次能一眼看出是谁占的。三、新服务启动时最容易踩的重试风暴新服务起不来时，很多人会反复重启服务，结果每次启动都先抢一波连接，把最后的名额也耗光。建议启动前先做三件事：把启动时的连接池初始值调小，先用少量连接验证能连通；给获取连接设一个较短的超时，超时就快速失败并记录，而不是无限等待；重试加随机延迟和次数上限，不要所有实例同时重试。等服务能稳定启动后，再逐步把池子调回正常值。四、按“服务、账号、主机”三层定位，不要只看总数定位时建议分三层记下来：第一层是哪个服务占得多，第二层是该服务用哪个账号，第三层是来自哪几台主机或实例。如果是某一台新扩容的主机占得多，先检查这台主机的池配置和版本；如果是后台任务账号占得多，先限制这个账号的并发或错峰；如果是所有服务均匀上涨，再考虑是不是流量真的涨了。把这三层结果留下来，后面复盘和调参数才有依据。五、什么时候才考虑调大上限或加代理只有同时满足三点才适合调大：已经确认不是泄漏和慢查询拖住连接；流量增长是合理的、且有监控数据支撑；实例内存和规格留有余量。否则调大只是把问题往后推。长期看，更稳妥的是把核心和非核心分账号、给后台任务限流错峰、必要时用数据库代理或读写分离把连接收敛，而不是让所有服务直接抢同一个上限。