
## 承接上一篇

上一篇里我给 **WorkBuddy** 提了份反馈，做了两件事：**把卡顿的现象记下来**（输入框 100% 的渲染事件都要等 1 秒以上，p90 是 9 秒，最惨一次 52.5 分钟），**然后把反馈交了**（那 5 条诉求）。

这一篇讲交完反馈之后的事：**我不甘心，去把它翻了个底朝天。**

先说结论：**凶手抓到了三个。但我自己在半路上先摔了一跤，而且摔得挺难看。**

所以，从摔跤讲起。

---

## 第一幕：我很自信地写了份报告，然后被当场打脸

我翻日志的时候，看到这么一行：

```
blocks:total(avg=2486.1,max=2487) ... calls=20 dirty=20
```

翻译成人话：**页面里有 2400 多个渲染块，这一次 20 个"脏标记"全亮了。**

我当时的推理链是这样的：

> 块数涨到 2400 ⇒ 每次全都标脏 ⇒ 增量复用肯定失效了 ⇒ 所以单次渲染要好几秒。

逻辑通顺、证据在手，我写了份报告，结论是"**增量复用未生效**"。

**然后我同事（一个 AI 工位）把完整的那行日志甩给我看：**

```
blocks:total(avg=2486.1,max=2487) reused(avgOnDirty=2507.0) new(avgOnDirty=1.0)
                                   ↑ 2508 块里，复用了 2507 块
```

**复用率 99.95%。**

而我把那句话读成"没有复用"。

### 我是怎么瞎的

我写了个提取正则：

```python
blocks:total\(avg=([\d.]+)
```

**它只抓前半段。**

后半段那个 `reused(...)` —— 在**我的世界里根本不存在**。不是我看了没看懂，是**我的工具把它裁掉了**，然后我拿着半行数据，下了一个跟事实相反的结论。

这事最吓人的地方在于：**这个错结论看起来特别有据可依。** 它带着行号、带着数字、带着"证据链"。如果没被拦住，我就把它发给官方了 —— 让他们去修一个**实测完全正常**的东西。

> 教训一：**当你的提取工具比数据窄，你会得到一份"很有说服力的错结论"。**

---

## 第二幕：凶手不在"计算"里，在"计算之间"

被打脸之后我重新翻，发现日志里其实一直有**两类耗时**，量纲差了**三千多倍**：

| 类别 | 实测 |
|---|---|
| 它**自己报的"我算了多久"** | **0.50 毫秒 / 0.57 毫秒 / 1.39 毫秒** |
| `渲染了 N 次，耗时 X ms` | **2,003 毫秒 / 9,024 毫秒** |

同一个时刻，两个数都是真的。区别在于：

- `0.57 毫秒` 回答的是：**这段计算花了多少 CPU？**
- `2003 毫秒` 回答的是：**从它被触发到它完成，过去了多久？**

后者里**绝大部分是"等"** —— 等主线程空出来、等前一个任务让路。

**算得只要 0.57 毫秒，却等了 2003 毫秒。** 那这 2002 毫秒，谁占着？

### 去找"它自己记的账"

这里有个关键动作：**别自己推断，去找应用自己打的归因。**

它在日志里其实写了，只是藏在另一个地方（长这样）：

```
[perf] [loop-lag] STALL macro=63158ms ... top=ipc.push.total=107|<某个频道>=104|<某个频道>.first.sampleExhausted=104
```

`top=` 后面就是**它自己算的"谁占了主线程"排行榜**。我把全部这类行聚合了一下：

| 凶手 | 累计次数 |
|---|---|
| **`ipc.push.wb-event.total`** | **66,854** |
| **`…wb:conversation:requestUpdate`** | **52,557** |
| **`…requestUpdate.first.sampleExhausted`** | **52,518** |
| **`hasTRS.miss`** | 8,412 |

**主线程停顿 97 次，最长 63 秒。而其中单次停顿里，那个频道被推了 104～142 次。**

> 教训二：**`耗时 X ms` 是"等了多久"，不是"算了多久"。** 要判断计算量，去找那个自报计算耗时的字段 —— 两个数能差几千倍。

---

## 第三幕：两个"几乎相等"的数字，暴露了一个循环

上面表格里有两行，我盯着看了很久：

```
那个频道的推送次数                        = 52,557
那个频道 + .first.sampleExhausted        = 52,518
```

**差 39。** 万分之七。

两个独立计数的量，**几乎一模一样** —— 这基本只有一种解释：**它们成对出现。**

把名字连起来读：

> **「`requestUpdate` → `sampleExhausted`（没有新数据）→ 再请求」**

**每次请求都拿不到东西，于是立刻再请求一次。**

这不叫请求，这叫**复读机**。而且它是**自激的** —— 不需要外部刺激就能一直转下去。

> 教训三：**两个本该不同量级的计数几乎相等 ⇒ 先假设那里有个循环。**

---

## 加时赛：还有更过分的

同一批日志里，又翻出来两个：

### 一、单次调用挂了 44 秒

```
[perf] [sample-rate] wb.invoke.slow.wb:conversations:changeManifests  {"dur":44223, ...}
```

`44223` 毫秒。而同一刻它记的停顿是 `macro=44239ms` —— **44223 和 44239，几乎是同一个数。**

⇒ 这次卡顿，十有八九就是这一次调用造成的。

**注意这个和前面那个"频道推送 100 多次"是两码事**：一个是**高频骚扰**，一个是**单次霸占**。得分开修。

### 二、有个属性的"类型"在两次渲染之间变了

```
props 采样  tool_call.result   上次=str(长度1)  这次=arr(长度1)      ← 类型变了
            tool_call.args     上次=对象(4键)  这次=对象(3键)
            tool_call.status   上次=str(7)     这次=str(8)
```

同批的读数：**32 个块没命中，31 个是因为"属性"没命中。**

一个属性的**类型**从字符串变成数组 —— 类型一变，引用必变，比较必然落空，**连带**把依赖它的几十个块全部拖下水。

**这条在我看来是整个日志里最"可修且收益明确"的一个点**：只要让那个属性形态稳定（要么永远是字符串，要么永远是数组），这 31 个 miss 应该当场消失。

---

## 该报的 bug 一条不少

吐槽归吐槽，下面这五条是认真写的（已经整理成反馈给官方了）：

1. **对 `wb:conversation:requestUpdate` 做合并/节流** —— 同一个 tick 里推 104～177 次，显然过量。
2. **查 `sampleExhausted` 为什么会触发重新请求** —— 如果它的语义是"这次没新数据"，那**正确行为应该是停手，而不是立刻再问一遍**。
3. **查 `wb:conversations:changeManifests` 为什么单次要 44 秒** —— 这和第 1 条是两类不同的问题。
4. **查 `tool_call.result` 的类型为什么会在 `str` 和 `arr` 之间漂移** —— 稳定它能消掉那批 31 个 miss。
5. **`hasTRS.miss`** 记了 8,412 次，看着和上面几条有关，希望一起看看。

---

## 顺手留个方法，你也可以自己查

如果你也遇到"说不清哪里慢"的卡顿，这几条大概能省你半天：

1. **先分清两类耗时。** `耗时 X ms` / `took X ms` 这种多半是**墙钟**，不是算力。去找 `elapsedMs` / `cpuTime` 这类**自报计算耗时**的字段。两者能差几千倍。
2. **优先找"自带归因"的日志。** 形如 `top=` / `reason=` / `breakdown=` 的字段，是应用**自己记的账**，比你在旁边猜因果强一个量级。
3. **写提取正则之前，先把一条完整记录原样打出来看。** 正则只抓前半段，后半段对你就"不存在" —— 这就是我第一幕翻车的全部原因。
4. **两个独立计数几乎相等 ⇒ 假设那里有循环。**
5. **"取不到字段"和"字段是空值"必须分开处理。** 取不到就报错停下，别当成空接着算 —— 否则你会得出一片"全是空"的假象，然后据此下结论。
6. **报结论时，写清楚你测了哪一面、没测哪一面。** 我第一版全程在测"已经打开之后"，而抱怨的是"**切过去**"的打开过程 —— **我压根没测过用户说的那一面。**

---

## 边界（这部分我坚持留着）

- 上面的归因计数是**应用自己记的**，**不等于完整因果链**。
- 我**没有做**进程级的 CPU profile ⇒ **不能排除**还有没被那套埋点统计到的占用者。
- 所有数字来自**一台机器、一个会话**，**不能外推**成普遍结论。
- 我**没有验证**"会话文件大小"和卡顿的因果关系 —— 我第一版那个"块数导致卡顿"的说法已经被证伪了，而新说法我同样**没有验证**。

---

*协作说明：本文由我在真实使用中复现并记录；根因与成文由 AI 协助完成，我负责校验与发布。我非工程背景，技术表述如有错误，欢迎指出——我会回去用工具链重新验证后更正。*

*本文由 **OfferKuai（Offer快）团队**提交 —— 创始人：**Zhaofeng（Yaming）**。*


上一篇里我给 WorkBuddy 提了份反馈，做了两件事：把卡顿的现象记下来（输入框 100% 的渲染事件都要等 1 秒以上，p90 是 9 秒，最惨一次 52.5 分钟），然后把反馈交了（那 5 条诉求）。

我把Workbuddy的日志翻了 3 万行，找到了卡顿的三个"凶手"

开发工具

日志抓出三个卡顿元凶：复用率99.95%却被误判失效、0.57ms计算等2003ms主线程、两个几乎相等计数暴露自激循环。附五条修复建议及自检方法，教你区分墙钟与CPU耗时、找自带归因日志、识别循环陷阱。含44秒单次调用与属性类型漂移实证。

代码解释

WorkBuddy 

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我把Workbuddy的日志翻了 3 万行，找到了卡顿的三个"凶手"-腾讯云开发者社区-腾讯云

我把Workbuddy的日志翻了 3 万行，找到了卡顿的三个"凶手"

我把Workbuddy的日志翻了 3 万行，找到了卡顿的三个"凶手"

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐