覆盖率卡在 60% 通常是三块代码没被覆盖：异常分支、边界条件、以及难以构造输入的私有逻辑。按下面顺序攻。 一，先看报告定位，不要盲补。CodeArts 的覆盖率报告能按文件下钻到行，先按「未覆盖行数 × 业务重要性」排序。经验上 80% 的缺口集中在少数几个类里：工具类、参数校验、异常处理。 二，异常分支是最大的空洞。正常路径 AI 生成得很顺，但 catch 块几乎不会碰。做法是显式告诉它「为每个方法的每个 throw 分支写一个用例」，并给出触发条件。比如空指针、超时、下游返回非 200。 三，边界值。数值取 0、-1、最大值、最大值+1；字符串取空串、单字符、超长；集合取 empty、单元素、null 元素。让 AI 按等价类 + 边界值列表生成，而不是「随便写几个测试」。 四，外部依赖要能注入。覆盖率上不去经常是代码写死了 new 一个客户端，导致分支跑不到。先做构造注入或 setter 注入，再用 mock 构造各种返回值。CodeArts 能识别 Mockito 风格，把依赖注入点告诉它效果明显更好。 五，私有方法和静态方法。私有方法不直接测，测它的调用方；静态工具类可以直接测。实在测不到的，用反射或者在设计上重构为可测形式。 六，排除不该算的行。getter/setter、常量、main 方法、自动生成的代码，用配置排除掉，分母变小覆盖率立刻上升，这部分是合规的，不是作弊。 最后是工程化：把覆盖率门槛写进流水线，比如新增代码行覆盖率低于 70% 就卡住合并。只看总量会一直卡在 60%，只看增量才能持续往上走。

OBS 用起来简单，坑基本集中在权限、计费和一致这三块。 一，权限模型分两层，桶策略和 IAM 策略是「与」的关系。只给了 IAM 的 OBS FullAccess 但桶策略里没放行，依然 403；反过来桶策略设为公共读，IAM 没授权也访问不了。排查时先看报错里的 RequestId，再去桶策略和 IAM 两边对。 二，AK/SK 泄露是最常见的事故源。前端代码、客户端 App、GitHub 仓库里硬编码 AK 被扫描爬取，几天内就能被刷出天价流量。正确做法是用临时凭证 STS，或者用桶策略限制 Referer、IP 段。AK 一旦怀疑泄露，先禁用再新建，不要只删代码。 三，计费口径容易误判。存储费按平均存储量算，请求费按次算，外网流出流量单独计费。内网访问（同 region 的 ECS 走内网 endpoint）不产生流量费，很多人在公网 endpoint 上跑批量任务，账单直接翻倍。批量任务一定要换内网 endpoint。 四，上传方式选错。小文件用 PUT 直传，大文件必须用分片上传，否则超过 5GB 直接失败。分片上传后要记得调合并接口，未合并的分片会一直占存储并且额外计费。断点续传就是靠分片 + 记录 partNumber 实现的。 五，一致性。OBS 现在对新建对象是强一致的，但列举操作和桶级配置变更仍有短暂延迟。刚上传完立刻 list 可能看不到，别当成上传失败去重复上传。 六，跨域和防盗链。网页直传要配 CORS 规则，配了 CorsRule 还要确认 AllowedMethod 包含 PUT，很多人只配了 GET，浏览器直传一直被拦。防盗链靠 Referer 白名单，但 Referer 可伪造，只能防君子。 最后一条：删除是不可逆的，开了多版本控制才有后悔药。重要桶一定开版本控制，并配生命周期清理历史版本，不然存储会越滚越大。

生命周期规则不是实时生效的，而且它有几个前提条件，多数人踩的是这三条。 第一条，规则的匹配范围。生命周期规则按前缀匹配，前缀写错了就一条都匹配不到。`logs/` 和 `logs` 看着差不多，前者只匹配 logs/ 下的对象，后者会匹配 logs 开头的全部。在桶的对象列表里按前缀筛一次，确认目标对象真的在规则范围内。 第二条，规则的执行是异步的。OBS 的生命周期扫描是每天定时跑一次，而且是从规则创建时间开始算「年龄」，不是从上一次修改算。刚配完的规则，当天不会立刻生效，第二天才会看到存储类别变化。如果对象是最近刚上传的，年龄不足 30 天，也不会转。 第三条，也是最容易被忽略的：多版本桶和未合并分片。开了多版本控制之后，历史版本对象同样占空间但不享受当前版本的生命周期转换，需要单独配「历史版本转低频」。另外，未完成的分片上传不属于对象，生命周期规则对它们要单独配「清理未完成分片」。 还有一个陷阱：规则优先级和转换层级。从标准存储只能直接转低频或归档，不能跳级。如果规则里写的是转归档但对象已处于低频，要确认规则是否包含「从低频转归档」这一档，否则会被跳过。 排查方法很直接：控制台里点开「生命周期」列表看规则状态是否「生效中」，再用 obsutil 查某个对象当前的存储类别和最后修改时间： ```obsutil stat obs://桶名/对象名``` 两者对一遍，基本能定位是规则没匹配上，还是扫描还没跑到。

执行机空闲但任务排队，说明调度层没有把任务派下去，问题在「匹配」这一步，不在执行机本身。 按这四个方向查： 一，标签和行为匹配。流水线里每个任务都要指定「执行机类型」，实际匹配的是资源池里执行机的 label。执行机虽然显示空闲，但如果它的 label 是 linux-x86_64 而任务要求 arm64 或者指定了自定义标签，就永远匹配不上，状态一直是排队中。在流水线编排里点开那个任务，看清楚「执行环境」选的是什么。 二，资源池选错。CodeArts 有官方资源池和自定义资源池两种。任务配的是自定义资源池，但那个池子里没有执行机，或者执行机离线了只在页面上残留个名字，就会一直排队。到「资源池管理」里确认池子的在线节点数。 三，并发度上限。单个执行机默认只能跑一个任务，队列里任务多的时候，即使机器空闲也可能被同流水线的其他任务占着。看流水线的「并发策略」，以及执行机是否被别的流水线锁定。 四，执行机状态是假的空闲。页面上的「空闲」来自最后一次心跳上报，如果 agent 进程卡死但心跳还在发，就会显示空闲却接不了任务。登录执行机执行： ```systemctl status | grep -i agent``` 或者直接重启 agent 进程，让服务端重新下发。 最快的验证办法：复制一条流水线，把任务改成官方资源池、最普通的 linux 标签，再点执行。如果能跑，说明就是标签或资源池配置问题；如果还是排队，那要查项目配额——有些账号的并行任务数默认是 0 或 1，超额时会一直排队且不报错。

端到端延迟 = 采集缓冲 + 上行编码 + 服务端识别 + 结果回传 + 渲染。逐段压缩，效果比单纯买带宽明显得多。 采集端：别用默认的 100ms 一包。改成 20ms 一帧，配合 VAD 做端点检测，说话就送、静音就停，能省掉大半等待。同时开流式识别，不要等整句说完再发，边说边出中间结果，体感延迟直接砍半。 编码：Opus 优于 PCM，比特率 16kbps 单声道对识别精度几乎无损，带宽和传输时间都下来了。采样率 16k 足够，识别模型基本都按 16k 训练，硬上 48k 只是多传数据。 传输：用 WebSocket 或 HTTP/2 长连接，避免每句话重建 TLS。首包握手那几百毫秒在连续对话里会被放大成明显卡顿。就近接入，选和服务端同区域的接入点。 服务端：开中间结果（partial result），让 UI 先显示灰色文字，final 结果到了再替换。用户感知的是第一个字出现的时间，不是整句完成的时间。 客户端：音频缓冲别攒满再发，边采边推。播放侧用低延迟模式，Android 的 AudioTrack 设成 LOW_LATENCY，iOS 用 AVAudioSession 的 measurement 模式。 兜底：网络抖动时降级成更小的帧长加丢帧重传，宁可牺牲一点准确率也别让延迟累积。实测这套组合通常能把首字延迟压到 300ms 以内。

换成密钥登录后报 Permission denied (publickey)，按这几条对照，基本能命中。 第一，密钥权限太松。本地私钥文件必须 600，也就是只有自己能读。用 chmod 600 ~/.ssh/id_rsa，如果权限是 644 或者 664，ssh 会直接拒绝使用这个私钥，很多时候连报错都不明显，加 -v 才能看到。 第二，连的用户名不对。华为云 ECS 的 Linux 镜像默认用户分两种：CentOS、EulerOS、Debian 一般是 root，Ubuntu 是 ubuntu。用错用户名同样是 publickey 失败。第一次连不确定就都试一遍。 第三，公钥没真正落到目标用户的 authorized_keys 里。买机器时绑定密钥对，只会写进默认用户的 ~/.ssh/authorized_keys。如果你用别的用户，得手动把公钥追加进去，而且 .ssh 目录要 700，authorized_keys 要 600，所属用户和组都得对。 第四，安全组没放开 22 端口。这个现象是连接超时而不是 Permission denied，但很多人混在一起看。用 telnet 或 nc 试一下端口通不通，先排除网络层。 第五，私钥格式问题。华为云的密钥对下载下来是 pem，直接 ssh -i 就能用。如果被复制粘贴破坏了换行，或者中间被 Windows 编辑器改成了 CRLF，ssh 会报 invalid format。用 ssh-keygen -y -f 私钥 试一下，能输出公钥说明文件没坏。 第六，镜像本身禁用了密码或者密钥登录。检查 /etc/ssh/sshd_config 里的 PubkeyAuthentication 必须是 yes，PermitRootLogin 要允许 root 登录，改完记得 systemctl restart sshd。 排查最快的方式是 ssh -vvv user@ip，看它到底尝试了哪些认证方式、用了哪个密钥文件。

并行阶段里几个微服务往同一个制品仓库发同名包，必然互相覆盖。制品坐标是 groupId + artifactId + version，只要这三段一样，后到的就把先到的盖掉。 正规做法是让每个微服务的制品坐标唯一，三选一或者组合用。 一是 artifactId 带上服务名，比如 com.example:order-service:1.0.0 和 com.example:user-service:1.0.0。这是最标准的 maven 多模块做法。 二是仓库按服务分目录。Nexus 和 Artifactory 都支持 repository path 前缀，配置里把 upload path 设成 order-service/${version}/，物理隔离，谁也盖不到谁。 三是 version 里带构建号。用流水线内置变量拼成 1.0.0-${BUILD_NUMBER} 或者 1.0.0-${COMMIT_SHA}，每次构建都是新版本，天然不冲突。这个方案还能顺带解决回滚时找版本的问题。 如果用的是华为云 CodeArts 制品仓库，注意仓库的 snapshot 和 release 是分开的，快照版本要发到 snapshot 仓库，重复发布会被允许覆盖，正式版发 release 仓库则不允许覆盖。并行构建发快照时尤其容易撞。 另外有个容易忽略的点：并行任务里的 mvn deploy 如果没加 -DskipTests 之类的隔离参数，多个任务同时下载同一个 SNAPSHOT 依赖也可能拿到半成品，建议并行任务用独立的本地 repository 目录，参数是 -Dmaven.repo.local。

JSON 列上建了函数索引还走全表扫，基本是下面几种情况之一。 最常见的是查询表达式和索引定义不一致。索引建在 CAST(extra->>'$.type' AS CHAR(20)) 上，查询却写成 extra->>'$.type' = 'vip'，两者被优化器当成不同表达式，索引直接不认。查询里必须原样复用索引定义的表达式，包括同样的 CAST 类型和长度。 第二，字符集和排序规则不匹配。JSON 取出来是 utf8mb4，索引按一种 collation 建，比较时用了另一种，索引失效。用 SHOW INDEX 看 Collation 列确认。 第三，类型隐式转换。索引是字符串，条件里写数字，或者反过来，都会让索引不可用。JSON 里的值尤其容易踩，数字和字符串在 JSON 里是不同类型。 第四，函数索引本质是虚拟列，5.7 叫生成列，8.0 才支持直接写函数索引。如果你的版本低于 8.0.13，函数索引根本不生效，只能显式建生成列再建索引。 第五，优化器估算后主动放弃。表小或者过滤性差时，全表扫比走索引便宜，explain 里会出现 possible_keys 有值但 key 为 NULL。这种情况加 FORCE INDEX 验证一下，如果强行走索引确实更快，说明统计信息不准，ANALYZE TABLE 再试。 排查顺序：explain 看 key 和 type，show create table 确认索引表达式，再看 explain format=json 里的 used_key_parts。三步基本能定位。

Undo Log 在 InnoDB 里有两个工作：回滚和 MVCC，后者其实更常用。回滚好理解：修改前把旧值记下来，事务回滚时按 undo 逆序还原。但同一个 undo 记录还承担快照读的职责——当别的事务需要看这条记录的旧版本时，沿着 undo 链往前找，找到对自己快照可见的那个版本。这就是 RR 隔离级别下读到一致快照的实现方式，read view 加上 undo 版本链，读不加锁。所以 undo 不能随便删。什么时候真正清理？要等到没有任何活跃 read view 需要它。具体由 purge 线程负责：它按事务提交顺序推进，跳过那些仍被最老 read view 引用的位置。判断标准是最小的 trx_no 和最小的 read view 低水位，两者取小。这带来一个很实际的后果：长事务会钉住整个 undo 链。一个开了两小时的大事务，让 purge 无法越过它，两小时内所有 undo 都留着，undo 表空间持续膨胀，ibdata 或 undo 文件能涨到几十 G。监控看 information_schema.innodb_trx 里最老的 trx_started，超过几分钟就该报警。几个相关参数值得了解：innodb_undo_tablespaces 决定 undo 独立表空间个数，8.0 之后默认可以自动扩展；innodb_purge_threads 控制清理并发，写密集场景适当调大；innodb_max_undo_log_size 配合 truncate 能让 undo 表空间回收，但只有完全空闲的 undo 段才能被截断。实践建议：把长事务当故障处理，业务上做批量操作时分批提交，避免一次改几十万行。这是控制 undo 膨胀最有效的手段，比调参数管用得多。

按从近到远四层查，先判断是连不上还是连得慢。第一层看客户端异常栈。连接超时（connect timeout）和读超时（read timeout）是两回事：前者是三次握手没完成，指向网络、连接数、监听队列；后者是连上了但命令没回，指向慢命令或阻塞。异常信息里能区分就别混着查。第二层看服务端连接数。redis-cli info clients 看 connected_clients 是否接近 maxclients，info stats 看 rejected_connections 是否在涨。超了就是连接池配置过大或没复用，短连接每请求建一次是最常见的元凶。同时看 tcp-backlog，队列满了新连接会被内核丢弃，客户端看到的就是超时。第三层看是否被阻塞。单线程模型下，一个大 key 的 HGETALL、KEYS 全库扫描、LUA 里做重活，都会让所有请求排队。slowlog get 20 能看到超过阈值的命令，latency monitor 能抓瞬时尖刺。持久化也会造成阻塞：fork 时内存翻倍、AOF 重写期间 IO 打满，都会让延迟抬起来，看 latest_fork_usec 和 aof_rewrite 的时间点是否和超时对得上。第四层看网络和资源。同机房还是跨可用区、有没有走公网、安全组是否放通；宿主机 CPU 是否被邻居抢占，网卡的 conntrack 是否满。容器环境下还要看 cgroup 的 CPU 限额，Redis 被限流时表现为周期性卡顿。最后给个排查顺序：先看客户端区分超时类型，再看 info clients 和 slowlog，最后抓一次 tcpdump 看握手有没有完成。这三步能覆盖八成问题。