补充一个真正按选型场景落地的思路（楼上的回答是通用排查模板，没有讲选型本身）： 1. 先定业务画像，再定规格：先分清业务是 CPU 密集还是内存密集。Web/API、轻量应用一般 CPU 优先，选通用型；缓存、数据库、大内存场景选内存优化型；突发流量、低频任务选突发性能型加弹性伸缩。先跑起来再压测，不要一上来就买顶配。 2. 按量起步，压测定型：新业务先用按量计费加小规格上线，用云监控看 CPU、内存、磁盘 IO、网络 PPS 的峰值和均值。峰值利用率长期低于 30% 就降配，经常打满 80% 再升配。跑一两周拿到真实数据后，再决定包年包月或预留实例，锁定折扣。 3. 成本三件套：包年包月适合长期稳定业务，折扣大；按量适合波动和测试业务；弹性伸缩加定时伸缩用来应对波峰波谷，避免为峰值长期买单。存储也要分层：系统盘用高效云盘，数据盘按 IO 需求选型，冷数据放对象存储。 4. 别只比单价：同规格还要看 vCPU 与内存的比例、网络带宽、磁盘 IOPS 上限和突发额度，低价小规格如果频繁触发限流反而更贵。同时留 20% 左右的余量应对突发。 一句话：先按量小规格跑起来，用监控数据说话，再用包年包月或预留把长期成本打下来。

平衡成本和性能，核心是“按需选型、从小起步、用数据说话”。分享几点实操经验： 1、先按业务类型定大类：Web/API 这类计算密集选通用型或计算型；缓存、数据库这类内存密集选内存型；IO 密集看磁盘类型。别一上来就买顶配。 2、从小规格起步：先选满足预期的最小规格，用按需计费跑一段时间，配合云监控看 CPU、内存、网络带宽的实际水位，再决定升配还是降配。 3、压测定基线：用真实业务流量做压测，找到瓶颈点（是 CPU 先满还是内存先满），按瓶颈选规格，避免“CPU 闲置、内存爆满”这种错配。 4、计费方式搭配：长期稳定运行的业务用包年包月/预留实例，成本能低不少；流量波动大的部分用按需+弹性伸缩，波峰自动扩、波谷自动缩。 5、定期复盘：每月看一次监控数据，长期水位低于 30% 就降配，持续超过 70% 再考虑升配。规格不是一次定死的，跟着业务走最省钱。

1 楼的清单已经很全了，补充几个函数侧容易漏的点： 1. 函数配 VPC 需要“委托”FunctionGraph 往子网里创建 ENI 需要 agency（委托）授权，没配或权限不足时函数连 VPC 都进不去。去函数配置页检查 VPC 委托是否存在、是否包含 VPC 操作权限。 2. 函数 ENI 自己的安全组出方向大家都盯着 RDS 的入方向，但函数 ENI 所属安全组的出方向如果被收紧过（默认是全放行），照样连不出去。对照看一下函数配置里绑定的安全组出方向规则。 3. 子网 DNS函数里用 RDS 内网域名连接时，走的是子网配置的 DNS。如果子网 DNS 被改成自建 DNS 且没做内网转发，域名解析失败表现出来就是超时。先在函数里连内网 IP:3306，如果 IP 通、域名不通，就是 DNS 的问题。 4. 先做最小复现，把代码和网络分开在函数里写一段最小测试代码，只做 socket 连接 RDS 内网地址，看报什么错：Connection timed out 是链路问题，Connection refused 是端口/服务问题，Access denied 是账号白名单问题。别一上来就调业务代码。 5. 冷启动的 ENI 创建耗时函数长时间没调用后首次触发，或并发扩容时，创建 ENI 要几十秒，可能被误判为连接超时。把函数超时时间先调到 60 秒以上，再看日志里的真实错误。 排查顺序建议：委托 → 函数安全组出方向 → RDS 安全组入方向（按函数子网网段放行）→ 子网 DNS → 最小复现看错误类型。

补充一个楼主问到的“直接在 LXC 的 config 里配”的做法——LXC 自带 proxy 设备，不用手写 iptables/nftables，配置跟着容器走，重启自动生效： lxc config device add web proxy8080 proxy listen=tcp:0.0.0.0:8080 connect=tcp:10.0.3.100:80 这条配置直接写进容器的 config，宿主机重启、容器重启都不丢。原理是 LXC 在宿主机上起一个转发进程（默认 nat 模式），把宿主机 8080 的流量转给容器 80 端口。 几个注意点：1. 容器 IP 还是建议固定（lxc.net.0.ipv4.address = 10.0.3.100/24），否则 connect 指向的 IP 变了要重新配 device；2. listen 写 0.0.0.0 会监听宿主机所有网卡，只想内网访问就改成内网 IP；3. UDP 服务把 tcp 换成 udp 即可；4. 华为云安全组同样要放行 8080/TCP，云上这步省不了；5. 验证：ss -lntp | grep 8080，能看到转发进程在监听，再 curl http://宿主机IP:8080 测试。 和 nftables DNAT 的取舍：proxy 设备简单、跟着容器走、不用维护防火墙规则，适合端口不多的小机器；端口多、规则复杂（比如按源 IP 限流）还是 nftables 灵活。生产上二选一即可，别两套叠加，否则排错会很痛苦。

前面几位已经把按瓶颈选族、计费拆分讲得很全了，补充几个容易漏掉的省钱点：一、换个算账单位：别比单台价格，比“满足峰值 SLA 的最低总成本”同一业务用 2 台 4 核做负载均衡，往往比 1 台 8 核便宜且可用性更高；反过来数据库这类有状态服务，单台纵向扩容反而比多台分片省事。先定峰值 P95 延迟和可用性底线，达不到底线的再便宜也不选，超过底线很多的就是在为闲置付费。二、非生产环境是最好省的钱开发、测试环境夜间和周末基本没人用，定时启停（下班关机、上班开机）能直接省掉一半以上时长；测试库、压测机用完即释放，不要长期挂着按需实例。生产环境的包年包月折扣，不要套用到生命周期只有几周的临时环境上。三、把流量留在内网应用与数据库、缓存、对象存储尽量同区域同 VPC，走内网免费；跨区域、公网回源都会产生额外流量费。静态资源先走 CDN 回源到 OBS，ECS 只留动态请求，带宽压力下来后实例规格往往可以直接降一档。四、每月做一次闲置复核按标签（项目/环境）看账单，重点查三类：CPU 长期低于 20% 的实例、已解绑未释放的 EIP 和云盘、过期快照和镜像。降配和释放比任何选型技巧都直接，复核周期固定下来，成本才不会慢慢涨回去。

必须释放，关机不停费。按量付费 ECS 的费用是分开算的，关机只影响其中一项：1. 普通关机后 vCPU、内存仍为你保留占用，照常计费；即使关机时选了“关机不收费”，也只停算力这一项，盘和 EIP 照收。2. 彻底停费要做释放：删除实例，系统盘一般随实例删除，数据盘默认保留、要手动删；EIP 解绑后还要单独释放，删实例时勾了“随实例释放”也不保险，删完单独去 EIP 列表确认一遍；带宽包同样是独立资源，也要单独核对。3. 别看一眼就下结论：按量资源按小时出账有延迟，等最后一期账单出完，再去费用中心按产品核对 ECS、EIP、带宽、云硬盘四个列表都干净，才算真正清完。

先分清两种超时：建连就超时查网络侧，跑一半被掐断查超时配置。重点：函数 VPC 访问要真正生效并发布新版本；RDS 入方向放整个函数子网网段而非单个 IP；RDS 白名单地址组也要含该网段；函数超时先调大到 60 秒验证；同子网 ECS 直连可隔离定位。

结论先行：df 读的是文件系统元数据里的「已分配块数」，du 是遍历目录树逐个累加的。两者差值大，说明空间被 du 遍历不到的地方占了。你已经用 lsof 查过没发现明显的，那就按下面这个顺序查，基本都能命中。 第一步：先对齐统计口径，确认差值df -hT /                      # 确认哪个挂载点满了、文件系统类型sudo du -x -d1 -h / 2>/dev/null | sort -rh | head -15du 必须加 -x（不跨文件系统）且用 root 跑，否则权限不足跳过的目录会造成「漏统计」的假象。对比 df 的 Used 和 du 的总和，差值就是要找的「隐形空间」。 第二步：查已删除但被进程占用的文件（最常见lsof | grep deleted 输出太多容易看走眼，直接这样查：sudo lsof +L1 | awk 'NR>1{printf "%.1fM %s %s:%s\n",$7/1024/1024,$9,$1,$2}' | sort -rn | head -10+L1 只列出链接数为 0 的文件（即已删除但仍被占用的），按大小排序，一眼就能看到凶手。 处理时不一定要重启进程，直接截断就行，空间立即释放：sudo : > /proc//fd/    # FD号取自 lsof 的 FD 列 日志文件是重灾区，事后记得给它 logrotate。 第三步：查被挂载点「盖住」的旧数据（第二常见）典型场景 /data 写了几十 GB，后来又把一块云硬盘挂载到 /data 上。旧数据还占着原文件系统的空间，但 du 走的是挂载后的目录树，看不见了。sudo mkdir -p /mnt/rootviewsudo mount --bind / /mnt/rootviewsudo du -sh /mnt/rootview/* 2>/dev/null | sort -rh | head# 对比 /mnt/rootview/data 和正常 du 看到的 /data，差的就是被盖住的sudo umount /mnt/rootview 第四步 journal 和容器日志（ECS 上最容易灯下黑的两项）journalctl --disk-usage                              # 看 systemd 日志占了多少sudo journalctl --vacuum-size=200M --vacuum-time=7d  # 清理并限制大小sudo du -sh /var/lib/docker/containers/* 2>/dev/null | sort -rh | head   # 容器 json 日志 单个容 -json.log 没做轮转时能涨到几十 GB，du 逐层查时很容易忽略。 第五步： inode 耗尽和预留块df -i /    # IUse% 到 100% 就是海量小文件把 inode 吃光了sudo tune2fs -l /dev/xxx | grep -i reserved    # ext4 默认给 root 预留 5% 1→5 跑一遍，df 的 Used 基本就能和各项加总对上。ECS 上我遇到最多的是第二种（日志删了但进程占着）和第四种（journal/容器日志），du 逐层查时最容易漏掉这两处。按 排除器的  ：查    ：先往加上   ）