前面楼层把场景清单、选型公式、版本管理和定时巡检的例子讲得很全了，这里补两个前面没有细展开的东西：一份可以直接抄走的 OBS 缩略图函数代码，和一种新用法——给 AI Agent 当工具后端。 一、能直接跑的例子：OBS 上传触发生成缩略图 链路：用户上传原图到源桶 → OBS 事件触发函数 → 函数下载原图、Pillow 生成缩略图 → 上传到目标桶。 配置要点：运行时选 Python 3.10，入口写 index.handler，内存 256MB、超时先给 120 秒；Pillow 和 OBS SDK（esdk-obs-python）打进依赖层，不要每个函数重复塞包；OBS 触发器只挂源桶，缩略图写到另一个目标桶，避免写回再触发自己；函数访问 OBS 的权限用 IAM 委托给最小权限（源桶只读、目标桶可写）。  三个调试要1. 先在控制台用测试事件跑通再开 OBS 触发器，事件结构是 Records 数组，每条带 obs.bucket.name 和 obs.object.key；2. 同名覆盖写天然幂等，事件重试也不会产生重复文件；3. /tmp 只能当临时中转，处理完不要指望文件还在，出问题先去云日志 LTS 按 request-id 查日志。 二、新用法 ：给AI Agent 当工具后端 APIG 的 HTTP 触发器把函数暴露成工具接口，Agent 需要查订单、发通知、拉报表时直接调用函数，函数内部再调业务接口或数据库。函数无状态、按调用计费，很适合 Agent 这种低频、间歇的工具调用；Agent 侧用开发者空间的 MCP/工具编排接进来即可。注意两点：工具接口一定要过 APIG 鉴权和入参校验，别把无鉴权的函数直接暴露公网；工具调用也要控制超时，单次几秒内能返回的才放函数里，跑很久的改成异步回调。 一句话：场景选对只是开始，能抄走的代码和跑通的链路才是落地的关键；先拿 OBS 缩略图或定时巡检跑通一次，再往 Agent 工具、消息消费这些场景扩展。 代码如下。AK/SK 用环境变量传入，不要写死在代码里；客户端建在 handler 外面，热实例可以复用连接，冷启动也轻一点。import os from PIL import Image from obs import ObsClient client = ObsClient( access_key_id=os.environ["OBS_AK"], secret_access_key=os.environ["OBS_SK"], server=os.environ["OBS_ENDPOINT"], ) def handler(event, context): for record in event.get("Records", []): src_bucket = record["obs"]["bucket"]["name"] key = record["obs"]["object"]["key"] src_path = os.path.join("/tmp", os.path.basename(key)) dst_path = os.path.join("/tmp", "thumb_" + os.path.basename(key)) client.downloadFile(src_bucket, key, src_path) img = Image.open(src_path) img.thumbnail((320, 320)) img.save(dst_path, format="JPEG") client.putFile("thumb-bucket", "thumb/" + key, dst_path) return {"status": "ok"}

先说结论：有电子版证书的安排，但证书和奖金不是一起发的，领奖金时没收到是正常的；同时证书不是每期都保证有，一定要按自己参加的期次去核对，不能直接拿 2025 年初帖子的结论套自己的期次。一、为什么领奖金时没有证书奖金和证书走的是两条线：奖金按领奖流程审核、财务打款；证书要等最终获奖榜单公布后，由组委会统一制作，再通过报名时留的邮箱发给获奖队伍。所以“领奖金时没收到证书”本身说明不了没有证书，也影响不了获奖资格。二、按这个顺序核对1. 先确认自己在最终获奖榜单内。去大赛官网或论坛公告找自己参加那一期的最终获奖榜单，核对队名和名次。榜单还没公布就只能等，证书要等榜单出来之后才安排；榜单里没有队名，就没有证书。2. 榜单公布后留意报名邮箱。团队赛一般发到队长报名时填的邮箱，查邮件时收件箱、垃圾邮件和广告邮件文件夹都要翻一翻，证书不会当天就到，统一制作和发送需要一段时间。3. 如果榜单已出、奖金已领、等了两三周仍没有证书，就主动核对：带着参赛队名、参加的期次、获奖名次、报名时留的邮箱、获奖人姓名，在论坛私信版主“赛事资讯小助手”，请对方核对本期是否发放电子证书。三、一个重要的提醒2025 年 1 月 22 日版主在“黑客松系列赛题有没有证书”帖子里的被采纳回答是“会有电子版证书”，但那是当时的黑客松系列赛题；不同系列、不同期次的发放政策可能不一样。本帖 9 楼 36 期获奖者就没有收到电子版证书，就是一个反例。所以不要只凭“有证书”这个笼统说法就认定自己的期次一定有，先按期次核对清楚。四、等待期间先留好证据把最终榜单截图、领奖确认邮件、奖金到账记录都保存好。万一自己参加的这期确实不发证书，这些材料也能作为获奖证明，写进简历或用于学校的相关证明。

前面几楼把对时方法、信号对齐、模型侧处理讲得很全了，我补充一个能直接落地的角度：先算“不确定度预算”，再按预算决定这组数据的先后能不能排；能排的，用一段现成的对齐代码把多路信号对到同一时间轴上；不能排的，老实标成“顺序不确定”，不要硬排。一、先算一笔账：这组数据到底能不能排先后一次故障里，先后结论的不确定度来自四项：1. 时钟偏移和漂移：两路时钟差了多少秒，用共同事件或 NTP 偏差实测；2. 采样间隔：温度 1 秒采一次，时间分辨率就是 ±0.5 秒；振动 100 Hz 采，±5 毫秒；3. 阈值确认时间：振动超过阈值 3 秒才算“异常开始”，这 3 秒是检测延迟，不是物理时间；4. 传输和处理延迟：接收时间比采集时间晚多少。四项加起来就是总不确定度 U。判定规则只有一条：|t_A - t_B| U 时，先后排不出来，结论只能写“同时段异常，顺序不确定”；|t_A - t_B| ≥ U 时，才能排先后，而且要把 U 写进结论里。举个具体数：振动时钟慢 2 秒，温度采样间隔 1 秒（±0.5 秒），振动阈值确认 3 秒，网络延迟 0.5 秒，U 约 6 秒。如果振动异常和温升在日志里只差 4 秒，任何“振动先于温升”的结论都是不可信的——差值小于误差。二、能排的，先把多路信号对齐到同一时间轴不要直接拿各路原始时间戳排序。先统一到事件时间，再按容差对齐。Python 里用 merge_asof 一段代码就能做：vib = vib.sort_values('t')tmp = tmp.sort_values('t')aligned = pd.merge_asof(vib, tmp, on='t', tolerance=pd.Timedelta('3s'), direction='nearest')aligned = aligned.dropna(subset=['temp'])要点：tolerance 取 U 的一半左右；对齐后检查未匹配上的行占比，超过 5% 说明时钟漂移还在变，先修时钟再谈结论。三、每条事件至少记四个字段event_time（采集时间）、receive_time（接收时间）、seq（设备自增序号）、sync_age（上次对时距今多久）。出事先看 sync_age：超过 1 小时的同步记录，先后结论先打问号。序号 seq 是救命稻草——同一设备内，序号顺序不受时钟影响，至少能保证单路信号内部不颠倒。四、一个验收小实验人为把一路信号整体平移 5 秒、10 秒，看 AI 结论变不变：如果平移 5 秒结论就翻转，说明这套判断对时钟误差太敏感，上线前必须先把 U 降下来（提高对时频率、缩短采样间隔），而不是先调模型。一句话：时钟要修，但修之前先算清 U；差值小于 U 的，先后就不要排——把“不知道”写进结论，比写错先后更有价值。

先说结论：requests 拿不到不是 requests 的问题，是数据还没生成。按“先找数据在哪，再决定用什么拿”的顺序走，大多数页面都不用上无头浏览器。下面是一套可以直接照着跑的完整流程。一、第一步：先确认数据到底藏在哪（5 分钟，不用写代码）1. 浏览器打开目标页，按 F12 打开 Network 面板，筛选 Fetch/XHR，刷新页面。看返回 JSON 的请求，右键 Copy as cURL，在终端重放一次。能返回 JSON，就直接调接口，这是最快、最稳的路。2. 没找到接口？在 requests 拿到的 HTML 里搜这几个关键字：__NEXT_DATA__、__INITIAL_STATE__、window.__DATA__、__PRELOADED_STATE__。很多 React、Next.js 站点会把首屏数据以 JSON 形式嵌在 HTML 里，用正则或 JSON 解析就能提出来。3. 两处都没有，说明数据确实要靠 JS 执行后二次请求，这时再上无头浏览器。二、第二步：确实要渲染，用 Playwright，等待条件写对最小可跑示例（Python）：from playwright.sync_api import sync_playwrightwith sync_playwright() as p:    browser = p.chromium.launch(headless=True)    page = browser.new_page()    page.goto(url, wait_until="domcontentloaded")    page.wait_for_selector(".target")    html = page.content()    browser.close()三个高频坑：1. 目标元素在 iframe 里：先切到对应的 frame 再取；2. 页面懒加载：滚动到底部再取内容；3. 接口带 sign、timestamp、nonce 类签名参数：别自己算签名，优先复用页面里现成的参数，或直接在浏览器上下文里发请求。三、第三步：从“跑一次”到“每天定时跑”1. 取数和解析分层：取数层只负责返回完整 HTML 或接口 JSON 并落盘，解析层单独写。页面改版时先报“解析失效”，而不是静默产出空表；2. 请求失败要重试（指数退避），遇到 429 先停下来；每次请求记下状态码、返回大小、解析到的字段数，字段缺失率一抬头就告警；3. 部署到云上时，用一台云服务器加系统定时任务跑脚本，数据落盘到对象存储，业务只读落盘后的数据。工具失效不影响历史数据，换工具也只需要改取数那一层。四、合规提醒只采公开可见的数据，遵守目标站点的服务条款与 robots 约定，不绕过登录墙和付费墙、不采集个人信息，频率控制在对方能接受的范围。一句话总结：先找接口和内嵌数据（最快），没有再上 Playwright 渲染（等待条件写对），最后把取数和解析分层、加上重试和告警。这个顺序下来，JS 渲染页基本都能稳定拿下来。

补充几个实操里最容易踩、而且容易被忽略的点，都按“先验证、再改配置”的顺序来，尽量不动生产桶的权限：一、打不开先分清是权限问题还是网络问题先用 obsutil 连通性验证，不要直接改桶策略：obsutil ls obs://你的桶名obsutil cp test.txt obs://你的桶名/test.txt如果 ls 就报 403 或 AccessDenied，基本是 AK/SK、桶策略或对象 ACL 的问题；如果报网络超时或连接失败，再去查 ECS 安全组、代理和 DNS。权限报错时不要图省事把整个桶改成公共读，先看具体缺哪一项权限。二、给别人临时下载，用签名 URL，不要公开桶需要临时分享单个文件时，用 obsutil 生成带有效期的签名链接：obsutil sign obs://你的桶名/test.txt -e 3600-e 3600 表示链接 1 小时后失效。对方用这个链接就能下载，过期自动失效，比把桶设成公共读安全得多。长期对外提供下载的静态资源，单独建一个桶放，读写权限分开管。三、上传失败留下的碎片会一直占空间、一直计费大文件分段上传中途失败后，碎片不会自动消失，控制台的对象列表里也看不到。正确做法是：进入 OBS 控制台 → 对应桶 → 对象 → 碎片管理，查看未完成的分段上传；再到“生命周期规则”里加一条规则，清理 7 天前未完成的分段上传。定期检查一次，账单里经常能省下这笔钱。四、存储类别选错，后面改起来很贵标准存储适合随时读的热数据；低频访问、归档存储单价低，但取回要等、还要收取回费用。不要把每天都要读的热数据放进归档存储，也不要在归档桶上频繁做“先取回再下载”的操作。选型前先想清楚数据的访问频率，建桶时就定好存储类别。五、浏览器直传报跨域，先配 CORS前端页面直接往 OBS 传文件、浏览器控制台报 CORS 错误时，问题不在代码，而在桶没配跨域规则。去桶的“权限管理 → 跨域资源共享（CORS）”里配置允许的来源域名、方法和请求头，保存后再试。只允许自己业务的域名，不要写成通配符放行所有来源。六、批量传文件别用控制台一个个点几十个文件以上就不要在控制台手动传了。用 obsutil cp 批量上传，大文件会自动分段、支持断点续传，传一半断网也不用从头来：obsutil cp ./本地目录 obs://你的桶名/对象前缀 -r传完用 obsutil ls obs://你的桶名/对象前缀 对一下文件数和大小，确认没有漏传。一句话总结：桶建在对的区域、权限默认私有、分享用签名链接、碎片配生命周期清理、存储类别按访问频率选、跨域去桶里配 CORS。按这个顺序过一遍，新手最常见的坑基本都能避开。

先把两件事分开：ping 通只证明跨 VPC 的网络已经通了，不代表实验平台的检测已经跑完或已经采到结果。平台进度不更新，多数是检测口径或检测时机的问题，不是网络问题，可以按下面顺序排查：1、核对检测口径：对等连接的状态是不是“已接受/已建立”；两端 VPC 的路由表里，指向对端网段的路由下一跳是不是这条对等连接；ping 是不是双向都通（从 ecs-test ping ecs-test2 也要通），用的 IP 是不是实验要求的 ECS 内网 IP。2、核对路由一致性：误点【暂不添加路由】后手动补的路由，要和实验手册要求的完全一致——目的网段不能写错、不能只加一端、下一跳类型不能选成默认网关。如果手册要求由平台自动添加路由，手动补的路由在目的网段和下一跳上和自动添加的完全一致才算满足条件。3、触发重新检测：刷新实验页面或重新进入实验；如果页面有“检测/提交/刷新进度”入口，点一次后等待平台的下一个检测周期，不要反复改路由配置，每次改动都可能让检测重新排队。4、超过 30 分钟仍不更新就走人工复核：把已经保存的 ping 完整结果截图（要能看到时间、源和目的 IP）、对等连接详情截图、两端路由表截图一起提交，并写明实验名称、实验账号、开始时间和已等待时长。截图要能证明“同一时段、同一对 ECS、双向连通”，这是人工复核最关键的证据。5、如果人工复核被退回，重点看退回理由里提到的具体检测项，按那一项逐一核对，而不是把整个实验重新做一遍。

先说结论：函数最适合三类活——事件一到就跑的短任务、定时跑的轻任务、接在 API 网关后面的胶水层。前面几楼把这三类和选型框架讲得很全了，我补充一个还没人提到的场景：给 AI Agent 做工具函数、承载 MCP Server。这个场景和函数“按量计费、自动伸缩、无状态”的特性几乎是贴合的，而且正好是开发者空间现在主推的方向。一、为什么 Agent 的工具函数特别适合跑在函数上Agent 调工具的特点是调用量忽高忽低、每次执行都很短、工具本身无状态。常见做法有两种：一个工具写成一个函数，通过 API 网关暴露给 Agent 调用；或者把一个 MCP Server 部署成函数，Agent 通过 MCP 协议调里面的多个工具。举个例子：一个“查订单状态”的 Agent 工具。用户问“我的订单到哪了”，Agent 调工具函数；函数收到 API 网关传来的订单号，查一次 RDS，把结果拼成 JSON 返回，全程不到 1 秒，执行完就释放。工具调用量跟着 Agent 的对话量走，半夜没人问就不产生费用。二、一个能直接照着做的最小例子触发器用 API 网关，函数只干三件事：校验入参、查一次数据源、返回结构化结果。配置上注意三点：内存按实际选一档够用的就行，不用一上来就选最大；超时设 30 秒左右，工具调用一般等不了太久；并发上限要设，避免 Agent 并发一高就把下游 RDS 的连接数打满。函数里不要放模型推理本身。推理耗时长，还可能超过单次执行时长上限，重计算应该走 ModelArts 或 ECS，函数只负责触发、分发和拼装结果。三、成本按“月总账”算费用大头是调用次数加执行时长换算成的 GB-秒。先跑一周灰度拿到两个数：日均工具调用次数、单次 P95 执行时长；月 GB-秒 = 月调用次数 × P95 时长（秒）× 内存（GB），再乘以官网公布的 GB-秒单价就是月费用。判断标准很简单：工具调用集中在白天、夜间几乎为零，函数通常明显比包月 ECS 便宜；如果工具 7×24 被持续高频调用，包月 ECS 往往更划算。Agent 工具大多是前一种，所以函数一般是更便宜的那边。四、三条红线第一，工具函数必须无状态、能重算。函数实例随时会被回收，进度、会话状态一律写到 OBS、数据库或消息队列里，不要记在实例内存和 /tmp 中。第二，写操作必须按业务唯一键做幂等。函数超时重试是“至少一次”语义，查订单、发消息、扣库存这类操作重试后不能重复执行。第三，权限按最小原则配。函数访问 OBS、RDS 时用 IAM 委托，只给它实际需要的桶和操作，密钥不要写进代码。一句话总结：触发是事件或 API 调用、单次几秒、无状态可重算的活，用 FunctionGraph；其中 AI Agent 的工具函数和 MCP Server 是目前最值得优先试的一个场景。建议先在开发者空间跑通一个工具函数，跑一周灰度拿到真实调用量和 P95 时长，再决定是不是全量迁过去。

你已经查过 lsof 且没有明显结果，说明大概率不是“一个正在写入的大文件被删了”这么简单。建议换一个思路：先把 df 与 du 的差额算出来，再按差额的特征分流，而不是继续逐层翻目录。df 读的是文件系统的已用统计，du 是遍历目录树累加，两者口径本来就不同，差额本身就是线索。一、先对齐口径，算出差额用 root 身份、限定同一文件系统、保留报错，假设满的是根分区：sudo df -B1 /sudo du -x -B1 --max-depth=1 / 2>/tmp/du.errsudo df -i /findmnt -T /注意三点：第一，不用 sudo 跑 du，权限不足的目录会被悄悄跳过，du 结果偏小，差额就被人为放大；第二，du 要加 -x，否则会跨到其他挂载点；第三，不要丢掉标准错误，/tmp/du.err 里的大量权限报错本身就是“漏统计”的证据。差额 = df 的 Used - du 的合计，先算出这个数，再往下分流。二、按差额特征分流1. 差额稳定，且约等于分区大小的 5%：优先查 ext4 预留块。sudo tune2fs -l /dev/xxx | grep -i reserved普通用户看到 df 已满、root 还能写入，就是预留块在起作用。数据盘可以酌情调低，系统盘不建议动。2. 差额随业务写入增长，重启或重载服务后消失：回到已删未释放这条线，但要换两种查法。你之前用普通用户跑 lsof 只能看到自己的进程，容器里的进程还可能在另一个挂载命名空间，宿主机 lsof 不一定看得到：sudo lsof +L1sudo find /proc/[0-9]*/fd -lname '* (deleted)' 2>/dev/null确认归属后，能重启服务就重启对应服务；不能停服务时，在确认文件描述符编号后截断对应描述符可以立即释放空间，但不要对数据库等有状态服务随意操作，截断前先确认该文件是否还在被业务写入。3. 差额约等于某个目录在另一视图下的大小：查挂载遮挡。先往目录写了数据、后来又把另一块盘挂到该目录上，旧数据就被盖住了，du 沿当前路径只能看到新盘。生产环境不要直接 umount 业务盘，先用只读方式核对：findmnt -R /sudo mkdir -p /mnt/rootview && sudo mount --bind / /mnt/rootviewsudo du -sh /mnt/rootview/可疑目录如果 bind 视图里出现了 du 之前统计不到的几十 GB，就是它。4. df -i 已满但块占用并不高：这是 inode 耗尽，海量小文件的问题，和“块空间差额大”是两回事。这时要按目录统计文件数量，而不是继续找大文件。5. 容器或特殊文件系统：Docker 环境重点看 /var/lib/docker 的 overlay 层和容器日志（json-log 无轮转时增长很快）；有快照或子卷的文件系统要按文件系统自己的统计工具核对，du 按目录树累加会和文件系统统计对不上；稀疏文件用 ls 看到的是逻辑大小，du 看到的是实际占用块，两者不能直接比。三、动手前的安全顺序定位到具体目录或进程之前，先不要批量删除。先确认数据的归属和保留要求，能归档的先归档，能截断的先截断，需要重启服务的选维护窗口。清理完再跑一次 df -B1 和 du -B1，确认差额已经缩小到可解释的范围（例如只剩预留块），而不是只看“使用率降下来了”。建议你把满的挂载点、df -B1、df -i、du -x 的结果、/tmp/du.err 的报错以及算出的差额贴出来，这样可以直接锁定是预留块、已删文件、挂载遮挡还是 inode 问题，不用再逐个目录猜。

补充一个排查时最容易用错的判断方法：不要只看“有没有索引”，要看“条件能不能在索引里定位”。 一、先做三问定位1. 条件里的列，有没有被改写过？改写包括换类型、套函数、做运算、加通配符前缀。2. 改写发生在列上，还是常量上？只改常量不影响定位，改列就影响。3. EXPLAIN 的 type 是不是 ALL、key 是不是 NULL？是，才谈失效；不是，要先看是不是优化器算过成本后主动选了全表。 二、三类写法的对照隐式类型转换：varchar 列用数字比，列被逐行转成数字，定位失效；int 列用字符串常量比，转的是常量，定位不受影响。字符集不一致同理，被转的是哪一列，就看哪一列的索引。函数运算：DATE(create_time)、YEAR(create_time)、id + 1 都是在列上运算，索引里存的是原始值，算出的值没有现成顺序，无法定位。改写成 create_time 的起止范围、id = 99，条件回到原始列上，才能定位。模糊查询：LIKE 'abc%' 前缀确定，对应索引里一段连续区间，可以走 range；LIKE '%abc'、LIKE '%abc%' 没有确定起点，只能全表或全索引扫描。需要中间或后缀匹配时，改用全文索引或搜索引擎，而不是继续调 LIKE。 三、两个容易误判的点第一，OR 只要有一列没有索引，整体就可能退化，两列都有索引或改写成 UNION ALL 才稳妥。第二，!=、NOT IN 在选择性差时被优化器放弃，是成本选择，不一定是写法失效，改写法前先看 rows 和 filtered。 建议的落地顺序：SHOW CREATE TABLE 确认类型、字符集和索引定义，再对原写法和改写写法各跑一次 EXPLAIN，对比 type、key、key_len、rows 和 Extra，改写后 type 从 ALL 变为 ref 或 range、rows 明显下降，才算真正修复。

前面几楼把选型框架讲得很全了，我补充一个可算账的思路：不要先问“选多大”，先算出“每 1000 次请求要多少资源”，再倒推规格，这样成本和性能就变成同一张表里的两个数，而不是凭感觉取舍。一、先算单机能力，再算需要几台用小规格压测出两个基线：单核在目标延迟下能支撑的 QPS，以及单机在峰值下的内存占用。所需 vCPU ≈ 峰值 QPS ÷ 单核 QPS × 安全系数 1.3；所需内存 ≈ 峰值内存占用 × 1.3，再加上系统和缓存预留。举例：峰值 800 QPS，单核在 P99 小于 200ms 时能跑 120 QPS，那么 CPU 需求约 800 ÷ 120 × 1.3 ≈ 8.7 核，取 8 核起步做验证，而不是直接买 16 核；如果压测发现 P99 先于 CPU 恶化，瓶颈在锁、慢查询或下游，先修瓶颈再加核。二、用分位数做决策，不要用平均值平均 CPU 30% 不代表够用，关键看峰值时段的 P95、P99 利用率和延迟。建议同时看三个数：峰值 5 分钟内的 CPU P95、内存峰值、接口 P99 延迟。CPU P95 长期高于 70% 才考虑升配或扩容；长期低于 30% 才考虑降配；只在 30% 到 70% 之间波动的规格，通常就是当前最合适的档位。三、把成本换算成单位成本再对比同样预算下，比较“每核每月成本”和“每 1000 次请求成本”，不要只比较实例单价。例如：A 方案 8 核月费较高但单机能扛 800 QPS，B 方案 4 核便宜但需要两台加负载均衡，算上负载均衡、带宽和运维成本后，单位请求成本可能反而更高。把磁盘 IOPS、带宽、快照和备份也算进去，避免 CPU 省了钱、账单却在磁盘和流量上补回来。四、给规格留两条退路第一，横向扩展优先于单机翻倍：应用无状态加负载均衡后，峰值靠加机器扛，单机规格可以保持在性价比最高的档位，故障影响面也更小。第二，底座和峰值分开计费：长期稳定运行的部分用包年包月覆盖，短暂峰值用按需加弹性伸缩，伸缩阈值建议设为 CPU 持续 5 分钟高于 70% 扩容、低于 30% 缩容，并设好最小和最大实例数，防止抖动造成费用失控。一句话总结：先压测算出单核 QPS 和峰值内存，用分位数和单位请求成本做决策，底座包年、峰值弹性、横向扩展兜底，这样选出来的规格既有数据支撑，也不会为用不上的性能长期付费。