先说结论：平衡成本与性能的核心不是“买多大”，而是“先量负载、再选系列、最后用计费方式和弹性伸缩调成本”。没有负载画像就定规格，要么性能不够，要么长期为闲置资源买单。一、先量负载：拿到四项关键指标再选型上云前或现有业务迁移时，用云监控 CES 至少看 7 天的曲线，重点看峰值和均值：1. CPU：使用率峰值和均值，业务是单核还是多核并行，决定 vCPU 数量；2. 内存：占用峰值，决定内存配比；3. 磁盘：IOPS 和吞吐量峰值，决定云硬盘类型；4. 带宽：公网带宽峰值和流量曲线，决定带宽计费方式。没有历史数据时，先用小规格上线、真实流量跑几天再调整，不要一次买满。二、按业务类型选规格族（华为云 ECS）1. 通用型（s 系列，vCPU 与内存约 1:2 或 1:4）：Web 服务、小程序后端、企业官网、轻量数据库，是中小业务的默认选择；2. 计算型（c 系列，1:2，高主频）：CPU 密集型计算、游戏服务器、视频编解码、批量处理；3. 内存型（m 系列，1:8）：Redis、大内存数据库、内存计算、实时分析；4. 磁盘增强型（d 系列）：自建数据库、日志分析等 I/O 密集型业务；5. 突发性能型（t 系列）：间歇性低负载的开发测试、个人博客、定时任务，平时积累积分、突发时消耗，持续高负载会被限速，不适合做生产主力；6. 鲲鹏（ARM）规格：单价通常更低，但要先确认应用、中间件和第三方二进制能在 ARM 上运行，镜像也要用对应架构；7. GPU 型：模型推理、视频处理等负载才需要，纯 Web、数据库业务买 GPU 型是浪费。三、成本优化：计费方式跟业务生命周期走1. 长期 7×24 小时稳定运行的业务用包年包月，通常最划算；2. 短期测试、活动、临时任务用按量计费；3. 能随时中断的离线批处理、渲染、压测任务可以考虑竞价实例；4. 轻量场景（个人博客、轻量小程序后端、开发测试）可以看 Flexus 云服务器 L 实例，套餐价通常更划算，但要注意它带流量包，用量大时要盯紧余量；5. 磁盘别一步到位买最高档：一般业务从高效云盘起步，出现 IOPS 瓶颈再升级到 SSD、极速型云盘；系统盘和数据盘分开，数据盘可独立扩容；6. 带宽看流量曲线选计费：流量平稳用固定带宽，波峰波谷明显用按流量计费；同业务的 ECS、RDS、OBS 尽量放在同一区域、可用区，内网流量不收费。四、弹性伸缩，别为峰值长期买单业务白天高、夜间低或有活动尖峰时，正确做法是“中等规格 + 弹性伸缩”：把 ECS 放进伸缩组、前面挂负载均衡，CPU 持续高于 70% 时自动扩容，低谷时自动缩容。预留 20% 左右的余量应对峰值即可，不要长期为峰值规格付费。五、一个可落地的操作流程1. 小规格起步（如 2vCPU 4GB），真实流量跑 3–7 天；2. 看监控定升降：CPU 持续高于 70% 或内存经常打满就升配，长期低于 20% 就降配；3. 需要调整时用“变更规格”在线升降配，磁盘和带宽也可以单独调整，不用重建机器；4. 压测看 P99 延迟，不只看平均 CPU：同样是 CPU 60%，P99 延迟 200ms 和 2s 是两回事。六、三个常见坑1. 只看 vCPU 核数，不看主频和代际：同是 4 核，不同代际性能能差不少；2. 忽略云盘 IOPS 和带宽上限：CPU 没满，磁盘先满了；3. 按量计费的机器关机不等于停费：资源仍被占用，长期不用应该释放而不是只关机，否则账单会一直走；上线前在费用中心设好预算告警。总结：先用 7 天监控曲线定负载画像，再按业务类型选规格族、用价格计算器算三种计费方式，最后小规格起步、跑几天按监控升降配。规格选型不是一次性决定，而是一个“买小—观测—调整”的循环。

先说结论：df 和 du 统计的不是同一个东西。df 读的是文件系统超级块里“已分配块”的总数；du 是沿目录树逐个文件累加。两者对不上，说明空间藏在 du 遍历不到的地方。按下面顺序查，基本都能定位（下面假设满的是 /，请换成 df 显示的实际挂载点）。一、先把口径对齐——很多人第一步就查错了1. 用 root 跑，并保留报错：sudo du -x -h --max-depth=1 / 2>/tmp/du.err，然后看 /tmp/du.err 里有没有 Permission denied。权限不足被跳过的目录最容易漏统计。2. 一定要加 -x：不加 -x，du 会跨进其他挂载点，把别的盘也算进来，数字就没法和 df 对。3. 用字节对账：df -B1 / 记下 Used，再跑 sudo du -x -s -B1 / 记下总计，两者的差值就是要找的“隐形占用”，先有数再往下查。4. 别拿 ls -lh 的大小和 du 比：稀疏文件逻辑大小大、实际占用小；硬链接 du 只计一次。二、已删除但仍被占用的文件——最常见，但要这样查才准你说 lsof 查过没发现，常见原因有三个：不是 root 跑的（看不到系统服务的句柄）、输出太多被淹没了、文件在容器或另一个挂载命名空间里。sudo lsof +L1上面这条只列链接数为 0 的文件，也就是已删除仍被打开的。也可以这样看：sudo lsof -nP | grep deleted | sort -k7 -rn | head更直接的办法是扫 /proc：sudo find /proc/[0-9]*/fd -lname '* (deleted)' 2>/dev/null确认之后不用重启进程也能释放空间，用截断代替删除：: > /proc//fd/FD 号取 lsof 输出 FD 列的数字部分，截断后空间立即回来。长远看：日志加 logrotate 并用 copytruncate，别直接 rm 运行中服务正在写的大文件。三、挂载点把旧数据“盖住”了——ECS 上第二常见典型场景：先往 /data 写了几十 GB（日志、备份），后来又把一块云硬盘挂载到 /data 上。旧文件仍占父文件系统的空间，但 du 沿挂载后的目录树看不见。验证方法（不用 umount，不影响业务）：sudo mkdir -p /mnt/rootview && sudo mount --bind / /mnt/rootviewsudo du -sh /mnt/rootview/data把结果和 du -sh /data 对比，如果前者大了几十 GB，凶手就是它。查完记得 sudo umount /mnt/rootview。也可以先用 findmnt -R / 看完整挂载树找可疑挂载点。四、inode 耗尽——先分清是容量满还是 inode 满df -i /海量小文件（缓存、会话文件、邮件队列）会把 inode 吃光，表现也是写不进文件。但要注意：inode 满时 df -h 的已用空间并不大，它解释不了“df 已用远大于 du”。定位小文件密集的目录：sudo du --inodes -x -d1 / 2>/dev/null | sort -rn | head五、ext4 预留块ext4 默认给 root 预留 5% 空间，普通用户看 df 会显示 100%，root 却还能写。用 tune2fs -l /dev/xxx | grep -i reserved 确认。数据盘可以适当调低，例如 sudo tune2fs -m 1 /dev/xxx，系统盘别乱调。六、ECS 上最容易灯下黑的三处1. systemd journal：/var/log/journal 经常攒到几个 GB，du 逐层查时藏在 /var 里很不起眼。journalctl --disk-usage应急释放（不重启任何服务）：sudo journalctl --vacuum-size=200M --vacuum-time=7d根治：在 /etc/systemd/journald.conf 加 SystemMaxUse=200M，然后 sudo systemctl restart systemd-journald。2. Docker 容器日志：docker system df 看不到容器日志的大小。sudo du -sh /var/lib/docker/containers/* 2>/dev/null | sort -rh | head单个 *-json.log 没有轮转时能涨到几十 GB。应急：sudo truncate -s 0 /var/lib/docker/containers/容器ID>/容器ID>-json.log（不重启容器）。根治：/etc/docker/daemon.json 里配 log-opts 的 max-size 和 max-file，改完需重启 docker，请选维护窗口做。3. /tmp、崩溃转储和 coredump：sudo du -sh /tmp /var/tmp /var/crash；coredumpctl list 看看有没有堆积。七、还没对上，再查这两类1. 文件系统特性：Btrfs 的快照和子卷用 sudo btrfs filesystem usage / 查；XFS 的预分配（fallocate）会让 df 已用大于文件逻辑大小，用 xfs_bmap -v 看。2. 容器/命名空间视角：宿主机上的 lsof 看不到容器里打开的已删文件，用 docker exec 进容器查，或 nsenter -t 容器主进程PID> -m lsof。一键排查（按顺序跑，哪项数字最大，凶手就是谁）df -hT; df -isudo du -x -d1 -h / 2>/dev/null | sort -rh | headjournalctl --disk-usage 2>/dev/nullsudo lsof +L1 2>/dev/null | headsudo du -sh /var/lib/docker/containers /tmp /var/crash 2>/dev/null安全提醒：定位到文件再动手删，先确认归属和业务用途；不要直接删正在写的大日志，用截断或轮转；umount、调预留块这类操作先在维护窗口做。

先说结论：1楼、2楼把三关和证据卡讲得很清楚了，这里补充一个能直接落地的操作版：按“结构初筛→计算复核→纸面合成→表征复现”四步走，每步给出通过标准和否决条件，走到哪一步、证据到哪一步，结论就写到哪一步。 一、结构初筛：不用进实验室，先筛掉明显不合理的- 化学合理性：价态是否合理、是否电中性；阳离子配位环境是否符合常见配位；有无部分占位、无序导致成分不确定。- 几何合理性：键长、键角是否落在合理区间，有没有原子间距小于共价半径之和这种明显不合理的接触。- 有无近亲：查 Materials Project、ICSD、COD，看有没有同结构类型、同化学体系的已合成化合物；有近亲的优先级明显高于完全没有先例的。 二、计算复核：稳定性要算全，方法要交代- 热力学：形成能为负不够，要看凸包能量 Ehull，一般 Ehull 小于 0.05 eV/atom 优先，超过 0.1–0.2 eV/atom 要谨慎；注意不同数据库、不同泛函的能量基准不能直接混比。- 动力学：声子谱无虚频；有限温度下用 AIMD 跑几十 ps，看结构是否保持。- 力学：弹性常数满足 Born 稳定性判据。- 性能复核：带隙等关键指标 PBE 会低估，用 HSE06 或 GW 复核；关键结论换方法、换参数做敏感性检查，换了就变的结果不能当依据。- 适用范围：候选若远离模型训练分布，预测误差的参考意义下降，优先级下调。 三、纸面合成评估：进实验室前先写合成预案- 反应热力学：算反应吉布斯自由能，判断反应方向；同时画出可能的反应路径和中间产物。- 动力学与方法选择：固相法看扩散和温度窗口；水热/溶剂热看前驱体溶解度、pH 和矿化剂；溶胶-凝胶、助熔剂法、化学气相沉积各有适用场景，按前驱体性质选方法，不是一种方法包打天下。- 工艺窗口：亚稳相往往只有很窄的温度、气氛、升降温速率和淬火窗口，预案里要先写出窗口的上下限和备选路线。- 前驱体与安全成本：可获得性、纯度、价格、毒性、管制；反应温度和气氛是否在现有设备能力内。- 杂相清单：列出最可能共生的竞争相，表征时逐项排除。 四、表征与复现：做出来不等于复现- 表征闭环：XRD 对照预测衍射图 + Rietveld 精修确定晶格参数和相纯度；成分用 EDS/ICP；形貌用 SEM/TEM；价态用 XPS；热稳定性用 TG-DSC。- 性能测试：固定测试条件（电流密度、电压窗口、温度、湿度等）测性能，不同条件的结果不能直接比较；报告误差棒和样本数。- 复现标准：换批次原料、换一天、换操作人，至少重复 2–3 次；保留失败批次和全部原始数据；条件允许时换实验室按同一方案复现。- 工艺窗口与产率：温度、时间、配比单因素扫描，摸清窗口宽度和产率；只成功一次、条件稍变就做不出来的，先不报“已合成”，先报“窗口待摸清”。 五、结论分级写法- A级“已复现”：计算三项通过 + 多批次复现 + 表征闭环。- B级“已合成（单次）”：做出样品但未多批次复现。- C级“仅计算筛选”：只有计算证据。每级结论只写已拿到的证据，不把预测性能写成实测成果。 一句话：候选结构是优先级排序，不是合成保证书；结构、计算、合成、表征、复现五栏证据都齐了，才算“能合成且可复现”。

先说结论：有现成的，而且能直接下载。1 楼给的是“自己去哪里找 PDF”，下面补一个“前人已经解析好、能直接下载的数据集清单”，这是楼主问的“现成的”最直接的答案。 一、能直接下载的现成 PDF 语料（按推荐顺序） 1. peS2o（Hugging Face：allenai/peS2o）：Semantic Scholar 上 4000 万+ 篇学术论文，用 GROBID 解析成纯文本，约 570 亿 token。做知识、推理类预训练，先拿它打底最省事。 2. RedPajama-Data-1T（Hugging Face：togethercomputer/RedPajama-Data-1T）：1.2 万亿 token 的开源复现数据集，其中 arXiv 子集约 285 亿 token，来源就是 PDF 论文，许可清晰。 3. The Pile（Hugging Face：EleutherAI/the_pile）：总量 825GB，里面 arXiv 约 56GB、PubMed Central 约 50GB，都是 PDF 解析来的，适合做中英混合配比里的英文部分。 4. S2ORC（Semantic Scholar Open Research Corpus）：8100 万篇论文的解析语料，是 peS2o 的上游之一，需要更大规模或自己定制解析口径时用它。 5. arXiv 官方批量镜像 + PubMed Central 开放获取子集：arXiv 提供 S3 批量镜像（Requester Pays），PubMed Central 开放获取子集可通过 NCBI 的 FTP/S3 批量取。想要原始 PDF、按自己的流程解析时走这两条。 6. CORE（core.ac.uk）：聚合全球开放获取论文全文，提供 API 与批量下载，适合按学科批量取。 7. 商业数据集：楼主提到的亮数据 PDF 数据集（4.5 亿有效链接、900TB）。买之前先按 7 楼说的拿样本验货：抽取后正文占比、去重后剩余比例、随机抽 100 条人工读一遍，三项都过再谈采购。 二、下载方法（一条命令就能跑） Hugging Face 上的数据集用 huggingface-cli 或 datasets 库直接拉，例如：huggingface-cli download allenai/peS2o --repo-type dataset或 Python 里 datasets.load_dataset("allenai/peS2o", streaming=True) 流式读取。注意先确认磁盘空间：peS2o 全量数百 GB，The Pile 全量 800GB+，建议先下 arXiv 这类子集做小样本验证，再决定全量。 三、拿到之后的三件事（前面几楼已讲透，这里只列顺序） 1. 先算 token 账再囤数据：按 7 楼的算法，20 页 PDF 正文约 1 万 token，目标多少 token 就先算清需要多少文档；2. 去重与验货：文件 MD5 精确去重 + MinHash 近似去重（阈值可参考 1 楼的 0.8），每批随机抽 100 条人工读一遍；3. 许可清单：每批留一份来源、许可类型、抓取/购买时间、文件哈希，许可出问题要下架时按清单处理。 一句话总结：现成 PDF 语料直接能下载的是 peS2o、RedPajama、The Pile、S2ORC 这几套，按“先下载、验货、再扩规模”的顺序走，比自己从头抓 PDF 快得多。

先说结论：成本与性能的平衡点不在“买多大”，而在“分层定规格 + 用监控定档 + 用计费方式兜底”。同一业务的不同层，选型逻辑完全不同，混在一起按峰值买，必然又贵又浪费。一、按层拆，不要一台机器包打天下Web/网关层：无状态，用 2 核 4G 通用型多台加负载均衡，坏一台不影响业务，靠横向扩容扛峰值；应用层：先看语言和框架，Java 服务先算堆内存再定内存，CPU 密集型再考虑计算型；数据库/缓存层：最忌省内存，MySQL、Redis 直接上内存型，数据盘用高 IO 云硬盘，IOPS 不够表现为偶发慢查询，加核解决不了；离线任务层：定时任务、转码、批量处理走按需或竞价，跑完即释放。选型速查：Web/API（无状态）用通用型，CPU 与内存比约 1:2，2 核 4G 起步，多台加负载均衡；Java 应用用通用型或内存型，按堆内存加约 30% 余量反推；MySQL、Redis、Elasticsearch 用内存型，约 1:4 或 1:8，内存先行，数据盘用高 IO；计算密集（转码、推理、压测）用计算型，单核性能优先；低频、间歇任务用突发性能型或按需，长期满载不适用。二、起步宁小勿大，用 7 天监控定档1. 先用最小规格上线（例如 Web 层 2 核 4G），导入真实流量或做压测；2. 看云监控 CES 一周曲线：CPU 峰值长期高于 70% 就升一档，长期低于 20% 就降一档，内存、磁盘 I/O、带宽同理看峰值和均值；3. 压测找到拐点：逐步加并发，找到响应时间开始劣化的并发数，再留约 30% 的余量；4. ECS 支持变更规格（关机后在控制台变更），选小了能升、选大了能降，所以起步不用一次到位。三、成本主要不在实例单价，在三项搭配1. 计费混用：长期稳定的核心服务用包年包月；波动的 Web 层用按需加弹性伸缩（AS）自动扩缩；能容忍中断的离线任务用竞价实例；2. 带宽按峰值买、按需用：公网带宽按峰值留余量，流量波动大时考虑弹性带宽或 CDN 分流，别把带宽成本都压在 ECS 上；3. 磁盘与闲置：数据库用高 IO 盘，日志盘不用高档盘；开发测试环境下班、周末关机，闲置机器是最贵的成本。四、上线后每月复核一次每月看一次 CES 曲线和费用中心账单：CPU 长期低于 30% 降档；内存吃紧换内存型；带宽峰值与均值差距大，改弹性带宽或 CDN 分流。选型不是一次性的，跟着业务曲线调档，成本和性能才能一直处在平衡点。一句话总结：先按层定规格族，再用小规格实测，看监控曲线定档，最后用包年包月加按需加弹性伸缩的组合降成本。

先说结论：新手用 OBS 踩的坑，根源大多是把它当成本地硬盘或当成普通网站在用。OBS 是对象存储：对象一旦写入就不可原地修改、没有真正的“文件夹”和“改名”，权限、存储类别、区域和计费都是创建或上传时就要定好的。下面按最容易踩的顺序讲，前面楼层提到的点我尽量不再重复，只补具体做法和容易忽略的细节。一、权限：桶保持私有，分享单个文件用临时签名 URL新建桶默认是私有桶，这是最安全的状态，不要图省事改成“公共读”——公共读等于把桶里所有对象挂到公网，搜索引擎也能爬到。需要临时分享时，用 SDK 生成带过期时间的签名 URL，只授权单个对象，用完即失效。Python SDK 示例（请按所用 SDK 版本核对方法名和参数）：from obs import ObsClientobs = ObsClient(access_key_id="你的 AK", secret_access_key="你的 SK", server="https://obs.cn-north-4.myhuaweicloud.com")resp = obs.createSignedUrl("GET", "你的桶名", "reports/2026-11-10.xlsx", expires=3600)print(resp["signedUrl"])注意三点：签名 URL 里的桶名、对象名、区域 Endpoint 必须一致，对象名含中文或空格要先确认编码；AK/SK 绝不要写进前端 JS 或提交到代码仓库，浏览器直传要走后端签发的临时凭证；桶策略里 Principal 不要随手写“*”，那等于对所有人放行。二、存储类别与生命周期：热数据别放归档，碎片要定期清标准、低频访问、归档、深度归档的价格和取回代价完全不同：归档和深度归档取回要等几分钟到几小时，还收数据取回费，提前删除也要收费。天天要读的热数据放标准存储；几个月才读一次的冷数据再考虑沉降，沉降规则建议按对象名前缀分目录配，不要对整个桶一刀切。另外两个计费细节：分段上传失败或取消后，残留的碎片会一直占空间计费，生命周期规则里要专门加上“删除未完成的分段上传”；开了版本控制后，控制台“删除”对象只是打删除标记，旧版本还在占空间，要在版本列表里彻底删除，或用生命周期清理历史版本。三、对象名与元数据：上传时就要定好，事后改起来很贵对象名尽量只用字母、数字、短横线和点，避免中文、空格和特殊字符，否则签名 URL 容易因编码失效。OBS 没有真正的“文件夹”，所谓目录只是对象名的公共前缀；也没有“改名”操作，想改名只能复制成新对象再删旧对象，复制会产生新写入费用，删之前务必先校验新对象。上传图片、PDF 时如果不指定 Content-Type，对象会按 application/octet-stream 存储，浏览器打开会直接下载而不是预览。上传时按文件类型设置 Content-Type；已经传错的要重新上传或复制时指定新的元数据，不能只改名字。四、区域、Endpoint 与 SDK：三者必须对上桶建在哪个区域，就要用哪个区域的 Endpoint，SDK 里写错区域，常见表现是 301 重定向或签名校验失败。AK/SK、Endpoint、桶区域三者要一起核对，桶一旦创建就不能改区域，跨区域搬数据要用跨区域复制（需开版本控制）或迁移工具，复制期间新旧桶都要计费。大文件不要一次性 PUT：超过 100MB 建议用分段上传或 SDK 的断点续传，分段大小建议 5MB 到 100MB；批量上传前先在测试桶跑通，并确认超时、重试和并发数是否适合弱网环境。五、计费与限流：请求次数和流量也是钱除了存储容量，PUT、GET、LIST 请求次数也收费：不要写脚本每秒 LIST 全桶做统计，ListObjects 默认一次最多返回 1000 条，超了要用 marker 分页取。公网流出流量要收费，同区域 ECS 访问建议走内网 Endpoint；配了 CDN 加速后，删除或更新对象不会自动清 CDN 缓存，更新静态资源要主动刷新缓存或给文件名加版本号。短时间大量请求还可能触发 503 SlowDown：如果键名都以同一前缀开头（如同一日期目录下几万个文件），请求容易集中触发限流，缓解办法是把键名打散（前缀里加散列或按业务分桶），并给上传加退避重试。六、浏览器直传与静态网站：先配 CORS，别拿对象 URL 当网站网页用 JS 直接往 OBS 传文件，桶没配 CORS 规则，浏览器会报 No 'Access-Control-Allow-Origin'，要在桶的 CORS 配置里放行自己的域名和方法。直接用对象 URL 打开 HTML 文件，浏览器大概率会下载或显示 XML，而不是渲染页面——那只是对象访问地址，不是网站托管；想当静态网站用，要在桶上开启静态网站托管，并按网站托管的访问方式访问。七、快速排错表403：先查桶策略和 IAM 策略，两处都可能拒绝；注意区分“无权访问”和“对象不存在”。404：对象名或区域可能错了，无权查看时也可能伪装成 404，先用控制台确认对象确实存在。301 或签名失败：先核对 Endpoint 与桶区域是否一致。503 SlowDown：请求太集中，先把键名前缀打散并加退避重试。上传成功但打不开：先查 Content-Type 和 CORS，而不是反复重传。新手第一天建议：先建一个测试桶，把“私有桶 + 临时签名 URL + 生命周期（沉降与清理碎片）+ 版本控制 + 删桶前清空”完整跑一遍，再往生产桶放真实数据；同时在控制台把存储量、请求次数、流出流量的告警配好，敏感文件开启服务端加密（SSE-KMS），并定期检查访问日志。

结论先说：FunctionGraph 是事件驱动、无服务器、按量计费的计算服务，最适合“有明确触发事件、单次执行短、无状态、无需常驻”的任务；需要一直在线、跑很久、存状态的任务不适合，改用 ECS / CCE。一、适合的场景1. 事件驱动的文件处理：OBS 上传图片后自动触发，生成缩略图、打水印、转码、日志清洗后入库。文件到了才花钱，不用常驻一台服务器等事件。2. 定时任务：Timer 触发器每天凌晨做数据汇总、报表生成、过期文件清理、定时同步，替代常驻 cron 服务器。3. 轻量 API 后端：配合 APIG 做 Webhook 接收、小程序后端、表单提交，请求量小、波动大时按量计费比包月 ECS 划算。4. 异步解耦削峰：SMN 消息、DMS 队列触发函数做订单通知、短信发送、工单流转，高峰自动扩容，低谷缩到零。5. 运维自动化：定时巡检、告警触发自动处理（磁盘清理、实例重启）、资源标签核查。二、不适合的场景1. 单次执行很长的任务：函数有单次最长运行时间限制，超时会被中断，长跑批、超大文件全量处理要拆成小任务或用 ECS / 批量计算。2. 常驻服务和长连接：WebSocket、需要一直监听端口的服务不适合，函数执行完实例就回收。3. 强状态和大本地存储：函数无状态，本地 /tmp 是临时的，持久化要走 OBS、RDS 或 Redis。4. 冷启动敏感的低延迟实时链路：闲置后首次调用有冷启动耗时，毫秒级实时交互要评估或用预留实例。5. 固定出口 IP 场景：函数出口 IP 不固定，对接需 IP 白名单的第三方要走 NAT 网关固定出口 IP。三、一个可直接照做的例子：OBS 上传图片自动生成缩略图步骤：控制台 FunctionGraph 创建函数（运行环境 Python 3.9）→ 配置 OBS 触发器（源桶、事件为对象创建）→ 给函数配置 IAM 委托，授予 OBS 读源桶、写目标桶的权限 → 上传图片测试。函数入口示例（handler(event, context) 是 FunctionGraph Python 运行时的标准入口）：import osfrom io import BytesIOfrom PIL import Imagefrom obs import ObsClientdef handler(event, context):    record = event['Records'][0]    bucket = record['obs']['bucket']['name']    key = record['obs']['object']['key']    client = ObsClient(access_key_id=os.environ['AK'], secret_access_key=os.environ['SK'], server='https://obs.cn-north-4.myhuaweicloud.com')    resp = client.getObject(bucket, key)    img = Image.open(BytesIO(resp.body.read()))    img.thumbnail((320, 320))    buf = BytesIO()    img.save(buf, format='JPEG')    buf.seek(0)    client.putContent(os.environ['DST_BUCKET'], 'thumb/' + key, buf)    return {'statusCode': 200, 'body': 'ok'}注意：AK/SK 不要写死在代码里，放环境变量；OBS 触发是异步的，失败会重试，写库 / 写对象前要做幂等判断（同一事件可能处理两次）。四、选型前算三笔账1. 触发器能不能画出“事件 → 函数 → 下游服务”这条链，画不出就别硬用。2. 成本：低频、波动大的流量用函数划算；24 小时持续高频流量要拿日调用量 × 单次耗时跟 ECS 包月价对比。3. 下游连接数：函数并发起来后，RDS / Redis 连接数会被打高，要配连接池或代理；依赖包越小冷启动越快。一句话总结：事件来、干活走、不驻留，就用 FunctionGraph；常连接、有状态、跑得久，就用 ECS / 容器。

补充一个落地的视角：前面几楼把判断标准讲得很全了，这里补一份可以直接照做的落地清单，重点是函数写出来之后，怎么保证它在生产上不出事。一、先定一个最小可跑的组合：OBS 触发图片处理用户上传原图到 original/ 前缀，OBS 触发函数，函数下载原图、生成缩略图，写回 thumbs/ 前缀。关键配置有三点：第一，输出必须写到不同前缀，避免函数写回又触发自己，形成循环触发；第二，触发器只订阅 original/ 前缀的创建事件；第三，函数入口只做一件事——处理单张图片，批量靠事件拆分，不要在函数里循环扫整个桶。二、幂等和重试必须先写好，再上生产函数可能被重复触发（超时重试、事件重投递），所以写结果时要按对象名做幂等：先查目标文件是否已存在且对应同一个源对象，已存在就直接返回成功；写数据库先按唯一键（订单号加事件类型）去重再插入。失败时不要在函数里无限重试，让平台按配置重试两次，仍失败进死信队列，人工或定时任务再处理；函数里只重试可重试的错误（网络超时、服务暂时不可用），参数错误、鉴权失败直接返回，不重试。三、连接和并发：保护下游，而不是只看函数扩容函数并发上来后，下游第一个被打爆的通常是数据库。做法是：数据库连接放在函数全局变量里复用，不要每次调用都新建连接；给函数设置合理的最大并发数；高峰期在函数前面加消息队列削峰，函数按固定并发消费。压测前先算一笔账：函数最大并发乘以单实例连接数，要小于数据库最大连接数，超了就先降并发或加队列，不要先调大数据库连接数。四、冷启动和超时：按调用频率分开处理低频、延迟不敏感的任务（定时对账、文件处理）冷启动可以忽略；面向用户的同步接口如果对延迟要求高，要用预留实例，或者改成异步：网关收到请求后立即返回“已受理”，函数异步处理完再通过消息或回调通知结果。单次执行接近超时上限时，把任务拆小：一个函数只处理一条消息或一个文件，长任务拆成多步，用工作流或队列串起来，不要靠调大超时硬撑。五、上线前检查清单触发器订阅范围是否收敛到最小前缀和事件类型；输出是否会自触发形成循环；失败重试次数、死信、告警是否配好；日志是否打印了事件编号、对象名、耗时，方便按一次调用追踪；成本是否算过：按预估调用量乘以单次内存和时长，对照按量单价，和一台包年云服务器对比。一句话：FunctionGraph 最适合“事件一到就干活、干完就走”的短任务；能不能长期稳定跑，取决于幂等、重试、并发和下游保护这四件事有没有做扎实。

结论先说：只关机不能完全停费。确定彻底不用了，要做“删除/释放”实例，并把云硬盘和弹性公网 IP 一并处理掉。一、关机后各项资源怎么算钱1. 实例规格（vCPU、内存）：普通关机后，实例仍占用计算资源，会继续按实例规格计费；关机时如果控制台提供“关机不收费”选项并勾选（部分规格和区域支持），关机期间 vCPU、内存、镜像停止计费。2. 系统盘、数据盘（EVS 云硬盘）：云硬盘是独立计费的资源，只要盘还存在就按容量持续计费，开关机完全不影响它。3. 弹性公网 IP（EIP）：独立计费，关机后继续按其计费模式收费；即使把 EIP 从实例上解绑，只要没释放，就会继续产生保有费用。4. 快照/镜像：做了整机镜像或云硬盘快照的，超出免费额度的部分也会持续计费。二、两种场景怎么选- 短期不用、以后还要开机：关机时勾选“关机不收费”，算力费停掉，只剩磁盘和 EIP 的费用；需要时开机，数据都在。- 确定彻底不用：按下面的收尾顺序处理。三、彻底停费的收尾顺序1. 先备份：重要数据做整机镜像或云硬盘快照，确认备份可用。2. 在 ECS 控制台删除（释放）实例：系统盘一般随实例删除，数据盘按需勾选一并删除。3. 到“弹性公网 IP 和带宽”控制台解绑并释放不再用的 EIP；到“云硬盘”控制台清理残留的数据盘和不再需要的快照。4. 最后到“费用中心-账单”核对，确认实例及关联资源不再出账。一句话：关机是“暂停使用”，释放才是“停止计费”；测试机用完记得备份→删除实例→释放 EIP 和多余的盘，费用才会真正停下来。

楼主已经用 lsof 排除了已删未释放，这是很好的起点。下面补一个能把差额算清楚的办法：不要只比 df -h 和 du -sh 的“大概”，要按字节把每一项都算出来，差额对不上就说明还有一项没查到。 一、先把口径对齐，按字节算差额假设满的是 /，请换成 df 显示的实际挂载点：df -B1 / ; sudo du -x -B1 -s / 2>/tmp/du.err; df -i /du 必须用 root 跑、加 -x 限定同一文件系统，不要用 /* 展开，也不要丢掉标准错误——权限不足被跳过的目录最容易漏统计。df 的 Used 减去 du 的总计，就是你要找的“隐形占用”字节数，后面每一项都要能对应上这个数。 二、最容易漏的三类“隐形占用”1）挂载点遮挡：先往目录写了数据，后来又把盘挂到该目录上，旧数据就被盖住，du 走挂载后的目录树看不到。验证不用 umount：sudo mount --bind / /mnt/rootview，然后 sudo du -sh /mnt/rootview/原目录 对比。确认后把遮挡的数据移走或删除。2）容器 / 命名空间盲区：lsof 如果是在容器里跑的，只能看到该容器内的进程。一定要在宿主机上用 root 再跑一次 sudo lsof +L1，以及 sudo find /proc/[0-9]*/fd -lname '* (deleted)'，按大小排序看前几行。容器日志也要直接看文件：sudo du -sh /var/lib/docker/containers/*，单个 -json.log 没有轮转时能涨到几十 GB，用 truncate -s 0 截断，不要直接 rm 正在写的日志文件。3）journal 与临时文件：journalctl --disk-usage，du -sh /var/log/journal /tmp /var/tmp /var/crash；journal 可用 sudo journalctl --vacuum-size=200M --vacuum-time=7d 应急释放，并在 /etc/systemd/journald.conf 里设 SystemMaxUse 上限根治。 三、两个常被误当成主因的项inode 耗尽（df -i）能解释“还有容量却不能新建文件”，不直接解释 Used 远大于 du；ext4 预留块（tune2fs -l 查看 Reserved block count）一般只占 5% 左右，只能解释 Size、Used、Avail 的算术关系，解释不了几十 GB 的差额。稀疏文件也要注意：du 统计实际占用块，ls -lh 显示逻辑大小，两者别混着比。 四、处理与验证确认是某个进程持有已删文件后，不必先杀进程：用 : > /proc//fd/ 截断即可立即释放空间；能重启的服务用 systemctl reload 或重启对应进程。清理完再跑一遍 df -B1，如果 Used 没有下降，说明持有的进程还在，或者你清的是 du 本来就能看到的文件，差额项还没找到。 按“字节对账 → 挂载遮挡 → 宿主机 lsof / 容器日志 → journal/tmp”这个顺序查一遍，基本都能把差额算平。如果方便，请补充 df -B1、df -i、du -x -B1 -s 的具体数字和 findmnt -R 的结果，可以进一步定位到某一项。