先给结论：LXC 在 Debian 12 上默认走 lxcbr0 这个 NAT 网桥，容器拿到 10.0.3.x 的私网地址，宿主机之外直接访问不到。要让服务对外可用，有两条路——桥接模式（容器直接拿 VPC 内网 IP，最干净） 和 NAT + DNAT 端口转发（改动小，已有环境常用）。华为云上还要额外放行安全组，这一步最容易漏。方案一：桥接模式，让容器直接拿 ECS 同网段 IP（推荐）思路是把 ECS 的 eth0 挂到 br0 上，容器 veth 也挂 br0，容器就相当于 VPC 里一台独立主机，端口自然可达，不用做端口转发。1. 安装依赖并建网桥：apt install -y bridge-utilsip link add br0 type bridgeip link set eth0 master br0ip addr del /24 dev eth0ip addr add /24 dev br0ip link set br0 upip route add default via dev br02. 容器配置改成桥接：lxc.net.0.type = vethlxc.net.0.link = br0lxc.net.0.flags = uplxc.net.0.ipv4.address = 192.168.0.101/24lxc.net.0.ipv4.gateway = 192.168.0.1lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx3. 注意点：- 网桥方式下必须给容器配独立 MAC，且不能和 ECS 其他网卡撞；- 带宽/安全组是绑在 ECS 网卡上的，所以容器流量同样受 ECS 的安全组约束，要在安全组里放行容器端口；- Debian 12 用 systemd-networkd 或 ifupdown 管理网络，重启后手动 ip 命令会丢，建议写成 .netdev/.network 文件或 /etc/network/interfaces 持久化；- 一台 ECS 想跑多个容器对外服务时，桥接更省心（每个容器一个 IP 一个端口）。方案二：lxcbr0 + DNAT 端口转发1. 给容器固定 IP（DHCP 分配的地址重启会变，转发规则会失效）：lxc.net.0.ipv4.address = 10.0.3.101/24lxc.net.0.ipv4.gateway = 10.0.3.12. 打开转发：sysctl -w net.ipv4.ip_forward=1echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf && sysctl -p3. 加 DNAT（假设容器内是 80，对外用 8080）：iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.0.3.101:80iptables -t nat -A POSTROUTING -d 10.0.3.101 -p tcp --dport 80 -j MASQUERADEiptables -A FORWARD -p tcp -d 10.0.3.101 --dport 80 -j ACCEPT4. 在宿主机本机自测还要加 OUTPUT 链，否则 curl 127.0.0.1:8080 不通：iptables -t nat -A OUTPUT -p tcp -d 127.0.0.1 --dport 8080 -j DNAT --to-destination 10.0.3.101:805. 规则持久化：apt install -y iptables-persistentnetfilter-persistent save华为云侧必做的三步检查1. 安全组入方向放行对外端口（8080 或 80），源地址按需 0.0.0.0/0 或指定 CIDR；2. 如果要用公网访问，确认 ECS 绑定了弹性公网 IP，且 EIP 与安全组规则一致；3. 检查 ECS 内部防火墙（ufw/nftables）是否也放行了，Debian 12 默认无 ufw，但装过 Docker 的系统常有 FORWARD 链 DROP 规则，会把 NAT 流量吃掉——用 iptables -L FORWARD -n -v 看命中计数确认。验证顺序（由内到外，逐层确认）1. 容器内：ss -lntp 确认服务监听 0.0.0.0 而不是 127.0.0.1（只监听回环时转发一定失败）；2. 宿主机：curl 10.0.3.101:80 —— 通说明容器网络 OK；3. 宿主机：curl 127.0.0.1:8080 —— 通说明 DNAT/OUTPUT 规则 OK；4. 同 VPC 另一台机器：curl :8080 —— 通说明安全组内网放行；5. 公网：curl :8080 —— 不通多半还是安全组或 EIP 未绑定。两个常见坑：一是容器里的服务只监听 127.0.0.1，怎么转发都不通，必须改成 0.0.0.0；二是只加了 PREROUTING 没加 FORWARD ACCEPT，装过 Docker 的机器 FORWARD 默认策略是 DROP，表现为"规则看着对但外网连不上"。

stream=True 时接口返回的是 SSE 流，不是完整 JSON，每次 recv 拿到的可能是半条消息。三个处理点：一、按行读而不是按 chunk 读。响应用 iter_lines() 迭代，每行以 data: 开头，去掉前缀后单独 json.loads，遇到 [DONE] 结束。直接对 response.content 或 iter_content 做 json.loads 一定失败，因为一条消息可能被拆成多个 TCP 包。二、注意空行和心跳。SSE 用空行分隔事件，有的服务会定期发 : keep-alive 之类的注释行，解析前先跳过不匹配 data: 的行。三、UTF-8 多字节被截断。iter_lines 有 decode_unicode 参数，设成 True 让 requests 处理编码；如果自己按字节切，中文会被切成半个字符导致解码报错，用 incremental decoder 或者保留 buffer 拼接。另外注意超时要分开设，connect timeout 短、read timeout 长，流式响应一旦设了短的 read timeout 会被中途掐断，表现就是收到一半就断。最后加个 try/except 包住 json.loads，单条解析失败不要中断整个流，记录原始行往下走。

到期后的处理分三个阶段，时间点不同，结果完全不同。 第一阶段，到期但未超过保留期（一般是 15 天）。实例关机、停止服务，但数据还在，可以续费恢复。这期间计算资源不收费，但云硬盘和备份继续按存储计费，很多人以为关机就不花钱了，账单还在走。 第二阶段，超过保留期进入「已释放」或「待销毁」状态。华为云的规则是保留期满后资源被释放，云硬盘可能被删除或转为独立的按需云硬盘保留一段时间。这里有个关键点：随实例一起购买的系统盘和数据盘，释放时是否一起删，取决于购买时的设置（是否勾选「随实例删除」）。 第三阶段，彻底销毁后不可恢复。除非你用备份服务做过整机备份或云硬盘备份，否则数据没了。 几个能救命的做法： 一，提前配置到期提醒。在费用中心设置到期通知，提前 30 天、7 天、1 天各发一次。别依赖邮件，配上短信。 二，开自动续费。对必须长期在线的实例配自动续费，避免人为忘记。 三，定期做云硬盘备份，并把备份跨区域复制。备份是唯一能在资源释放后恢复数据的手段。 四，关键数据不要只放云硬盘。数据库类走 RDS 的自动备份，对象类放 OBS 并开多版本，容器类无状态化，把状态外置。 如果已经过期了，处理顺序：先看控制台的资源状态（是否还在保留期），能续费立刻续；如果已经释放，查「回收站」或者备份列表，有备份就新建实例挂载恢复；都没有的话，只能联系客服确认是否还有内部留存窗口，但不要抱期望。 一句话总结：到期前 30 天是唯一能从容处理的时间窗口，过期之后一切都变成运气。

分片上传中断后残留的碎片本质是「未完成的 multipart upload」，它占存储空间也计费，但不在对象列表里显示，所以很容易被忽略。 两种清理方式，建议都配上。 第一种，生命周期规则自动清理。在桶的生命周期配置里加一条规则，动作选「删除未完成的分片上传」，并设置「碎片过期天数」，比如 7 天。这条规则只作用于未合并的分片，不影响正常对象。官方推荐值一般 7 到 30 天，取决于业务上传的最大耗时。 第二种，主动排查存量。用 obsutil 列出未完成的分片： obsutil ls obs://桶名 -u -u 参数专门列未完成的分片上传。找到之后可以用 obsutil abort 指定 uploadId 清掉。这一步是为了清历史遗留，规则只管以后的。 第三个要一起处理的是客户端侧。碎片产生的根因是客户端上传到一半退出、网络中断、或者程序异常没走到 complete。改进方式：上传前记录 uploadId 到本地或数据库，启动时先做一次 abort 或 resume；给上传加超时和重试上限；SDK 的 partSize 不要设太小，分片数超过 10000 会直接失败。 第四个坑，多版本控制下碎片也占配额。桶开了版本控制，碎片同样计入存储量。有些人看到存储量涨但对象数量没涨，就是碎片或者历史版本。 最后核对方式：控制台桶的「概览」里有一项「未完成的分片上传」，和 obsutil ls -u 的结果对一遍。数量对得上，说明规则生效了。

加了索引但执行计划没走，先确认三件事：索引是不是真的建在查询用到的那一列上、优化器是不是认为全表扫描更便宜、以及 SQL 写法有没有让索引失效。 一，索引与实际条件列不匹配。where a = 1 and b > 2 建了 (b) 单列索引，优化器可能宁可全表扫。要看联合索引，且范围条件放最后。用 show index from 表 确认列顺序，别只看索引名。 二，选择性问题。如果该列区分度极低（比如状态列只有 0/1），优化器算出来走索引回表的成本高于全表顺序扫描，就会放弃索引。用 explain 的 rows 和 filtered 估计值判断，filtered 很低说明筛选性差。 三，SQL 写法导致失效。列上套函数、隐式类型转换、前导通配 like '%x'、or 连接的条件里有一侧无索引，都会让索引不可用。日期列被 date_format(create_time,'%Y-%m-%d')=... 包住是高频坑，改成范围比较。 四，统计信息过期。表数据变化大但没更新统计，优化器按旧的数据分布做决策。analyze table 表名 之后再看执行计划，很多"加了索引没反应"都是这一步解决的。 五，你是不是在看重放缓存。explain 看的是优化器计划，不是实际执行。真正的执行次数在 explain analyze（8.0 支持）或者慢日志里。有些情况计划选了索引，但实际因为回表太多中途放弃。 最后一条：确认索引不是被隐藏或不可见状态。8.0 可以用 alter table 表名 alter index 索引名 invisible 把索引隐藏，隐藏后优化器看不见但索引还在，用 show index 看 Visible 列是 YES 还是 NO。

先止血，再找根因，顺序不能反。 止血：如果还有 super 权限的会话，用 `mysqladmin -u root -p processlist` 或者已经连上的会话 `SHOW PROCESSLIST`，找出 Sleep 时间很长、来源 IP 集中的连接，批量 kill。没有可用会话时，可以临时把 max_connections 调大（`SET GLOBAL max_connections=1000`，无需重启），先把业务恢复，再慢慢查。 找根因，按概率排序： 一，连接池配置和数据库不匹配。应用侧 HikariCP 之类的池子最大连接数乘以实例数，很容易超过数据库上限。十个 pod 每池 50 个连接就是 500，而默认 max_connections 只有几百。这类问题在有扩缩容的集群里特别常见，扩容一次就把数据库打满。 二，应用没有正确关闭连接。代码里 getConnection 之后异常分支没 close，或者用了连接池但事务没提交、连接被长期占用。看 `SHOW PROCESSLIST` 里 Command=Sleep 且 Time 很大的连接，占比高就是这个问题。 三，慢查询把连接占死。一条跑几十秒的 SQL 会一直占着连接，并发一上来就把池子耗尽。开慢查询日志，看 `performance_schema.events_statements_summary_by_digest` 里耗时最高的 SQL。 四，wait_timeout 太长。空闲连接不释放，连接数只增不减。应用侧保持连接池存活，数据库侧把 wait_timeout 调到几分钟，让僵尸连接自己走掉。 长期方案是接数据库代理。华为云 RDS 的读写分离代理能做连接复用，把应用侧上万条连接收敛成后端几十条，这是解决连接数问题最彻底的办法，比一味调大 max_connections 有效得多。调大上限只是把问题推后，内存和上下文切换成本都会跟着涨。

这是 CPU 限流的典型现象，不是 limit 设错了，而是 limit 的机制和你预期的不一样。 CPU limit 在 cgroup v1/v2 里实现为 CFS quota：每个调度周期（默认 100ms）分配固定配额，用完就被 throttle，直到下个周期才能继续跑。一个 limit=1 核的容器，允许在一个周期内用满 100ms 的 CPU 时间。 问题在于：单次请求只需要 5ms CPU，但它消耗得很快，几十个并发请求在同一个 100ms 周期里抢这 100ms，配额提前耗尽，剩下的时间整个容器被冻结。表现出来就是 P50 正常，P99 出现几十毫秒甚至上百毫秒的尖刺，而监控上 CPU 使用率平均值并不高——因为均值和限流是两回事。 三个层面的处理： 一，先确认是限流。看 `container_cpu_cfs_throttled_periods_total` 和 `container_cpu_cfs_periods_total` 的比值，throttle 比例超过 5% 就值得处理了。只看 CPU 使用率永远看不出这个问题。 二，调整 limit 与 request 的关系。limit 不要贴着 request 设。request=500m、limit=1000m 这种配置，意味着突发时有翻倍空间；如果两个都设成 500m，等于把所有突发都掐死。Kubernetes 的 QoS 也会因为 request==limit 变成 Guaranteed，但这对延迟并不是最优。 三，对延迟敏感的 Java 服务，考虑调大 CFS 周期。把 `--cpu-period` 从 100ms 调到 200ms，单次 throttled 的粒度变粗，长尾会明显改善。这属于节点级 kubelet 配置，改之前要评估。 最后一点：Go 运行时按可用 CPU 数设置 GOMAXPROCS，在容器里读到的是节点核数而不是 limit，线程数远超配额，调度竞争更激烈。用 automaxprocs 或手动指定 GOMAXPROCS 等于 limit 的整数部分，通常会立刻看到改善。

这种「不返回也不报错」的状态，基本可以确定不是 SQL 卡住了，而是卡在 MDL（元数据锁）等待上。 MySQL 8.0 加索引默认走 online DDL，也就是 ALGORITHM=INPLACE，期间允许并发 DML。但它必须先拿到表的 MDL 排他锁才能开始。只要有一个长事务还持有这张表的 MDL 共享锁，DDL 就会排队等待，而这个等待默认没有超时，所以表现就是一直挂着。 排查顺序： 一，看谁在等。`SHOW PROCESSLIST` 找到那条 ALTER，State 一般显示 `Waiting for table metadata lock`。确认了这一点，方向就对了。 二，看谁挡着。8.0 用 performance_schema 最准： ```sqlSELECT * FROM performance_schema.metadata_locksWHERE OBJECT_SCHEMA='库名' AND OBJECT_NAME='表名';``` 能直接看到持有共享锁的线程 ID。再到 `information_schema.innodb_trx` 里找对应的 trx_mysql_thread_id，看事务跑了多久、有没有 `trx_state=RUNNING` 却没动静。 三，处理挡路者。要么等长事务结束，要么 kill 掉。注意如果 DDL 已经排队，后面所有访问这张表的查询都会继续堆积在它后面，一波能把连接数打满，所以要尽快决断。 四，下次避免。给 DDL 加上 `lock_wait_timeout`，超时直接失败而不是无限等待： ```sqlSET SESSION lock_wait_timeout = 30;``` 另外，真正的大表加索引更稳的做法是用 gh-ost 或 pt-online-schema-change，先建影子表再迁数据，主表只做一次短暂的 RENAME，把锁窗口压到秒级。华为云 RDS 控制台也提供了无锁变更的选项，改动量大的结构变更优先走那条路。

OBS 上手不难，坑基本集中在权限、一致性和计费三块。 权限：桶默认是私有，对外提供访问要么改桶策略要么走 CDN 回源。最常见的错是把桶设成公共读然后忘了关，图片视频被人白刷流量。正确做法是保持私有，用临时签名 URL（带过期时间）给前端，需要公开分发就挂 CDN 并做防盗链。 对象键命名：不要用带特殊字符和中文的 key，也不要以 / 开头。key 里用 / 组织目录只是命名约定，没有真实目录，按前缀删除要格外小心，删错就是删一片。 覆盖与版本：同一个 key 重复上传会直接覆盖，且没有回收站。开了多版本才能找回旧对象；没开版本的话删了就没了。这点和本地文件系统直觉不同，务必先开版本控制再做批量操作。 分片上传遗留：大文件上传中断会留下未完成的分片，这些分片占存储也计费。bucket 要配生命周期规则，自动清理超过 N 天未完成的分片。 跨域：前端直传必须配 CORS 规则，很多人卡在预检请求 OPTIONS 返回 403。AllowedMethod 要显式包含 PUT，AllowedHeader 里要放 Content-Type。 计费：外网下行流量单独计费，桶内网访问（同一区域 ECS）免费。生产环境里 ECS 访问 OBS 一定走内网 endpoint，走公网 endpoint 会产生流量费。请求次数也计费，小文件高频读的场景考虑加 CDN。 最后一条：删除桶前必须清空所有对象和未完成分片，否则一直删不掉，很多人卡在这里以为是权限问题。

换成密钥登录后报 Permission denied (publickey)，按这几条对照排查，命中率很高。 第一，私钥权限太松。本地私钥必须 600，也就是只有自己可读。chmod 600 ~/.ssh/id_rsa，如果是 644 或 664，ssh 会直接拒绝使用这个私钥，很多时候报错还不明显，加 -v 才看得到。 第二，登录用户名不对。华为云 Linux 镜像的默认用户分两种：CentOS、EulerOS、Debian 一般是 root，Ubuntu 是 ubuntu。用户名错了同样是 publickey 失败。不确定就都试一遍。 第三，公钥没真正写进目标用户的 authorized_keys。创建时绑定密钥对，只会写进默认用户的 ~/.ssh/authorized_keys；用别的用户得手动追加。同时 .ssh 目录要 700，authorized_keys 要 600，所属用户和组都要对。 第四，私钥文件被改坏。下载下来是 pem，直接 ssh -i 就能用。复制粘贴或 Windows 编辑器把换行改成 CRLF 会报 invalid format。用 ssh-keygen -y -f 私钥 验证，能输出公钥说明文件没坏。 第五，服务端配置。检查 /etc/ssh/sshd_config 里 PubkeyAuthentication 必须是 yes，PermitRootLogin 要允许 root，改完 systemctl restart sshd。 另外要区分两种失败：连接超时是安全组没放 22 端口，属于网络层；Permission denied 是认证层失败，端口是通的。先用 nc -vz 试端口，先分层再查，能少走很多弯路。 最快的定位方式：ssh -vvv user@ip，看它试了哪些认证方式、用了哪个密钥文件、服务端返回什么。