2026.03.15-工作周记

[Irissssaa]

工作内容

1. 异步函数可以点击跳转；

2. 停在断点处树能够自动更新；

3. vs code原生call stack面板内容已经改成逻辑调用栈；

4. 变量面板功能实现；

5. 推广网站 和 内容 搭建；

关于白名单的优化设计，思考如下：

• 真实用户调试场景分析

用户调试异步 Rust 程序时，通常是这样的：

场景 1："我的请求卡住了"
  → 用户知道是哪个 async fn 处理这个请求（比如 handle_request）
  → 想看这个函数 await 链上哪里卡了
  → trace 根 = handle_request

场景 2："某个任务执行结果不对"
  → 用户知道入口 async fn
  → 想看这条 await 链的执行路径和中间状态
  → trace 根 = 那个入口函数

场景 3："不知道问题在哪"
  → 用户在某行设了断点，程序停下来了
  → 想看"我是怎么到这里的"
  → 需要的是：当前停下位置的异步调用栈回溯

用户几乎总是从一两个他知道的函数开始的，而不是面对一个大列表去挑选。

• 白名单的定位应该是什么

白名单不应该是"用户手动选要跟踪什么"，而应该是过滤噪音：

┌─────────────────────────────────────────────────┐
│ 自动生成的 poll 函数列表（可能几十上百个）          │
│                                                   │
│  ✅ my_app::handle_request::{async_fn#0}         │  ← 用户代码
│  ✅ my_app::db_query::{async_fn#0}               │  ← 用户代码
│  ✅ my_app::send_response::{async_fn#0}          │  ← 用户代码
│  ❌ tokio::runtime::task::harness::poll           │  ← runtime 噪音
│  ❌ tokio::io::poll_read_buf                      │  ← runtime 噪音
│  ❌ hyper::proto::h1::dispatch::poll              │  ← 框架噪音
│  ...                                              │
└─────────────────────────────────────────────────┘

白名单的作用：让用户去掉下面那些 runtime/框架的噪音
                而不是让用户从零开始选

• 初步设计方案

1. 白名单：自动分类 + 简单开关

不是让用户面对一个扁平的列表打勾，而是自动分组：

白名单管理面板：
┌───────────────────────────────────────┐
│ 📦 my_app (12 个函数)         [✅ 全选] │
│   ✅ handle_request                    │
│   ✅ db_query                          │
│   ✅ send_response                     │
│                                        │
│ 📦 tokio (25 个函数)          [❌ 全不选]│
│   ❌ runtime::task::harness::poll      │
│   ❌ io::poll_read_buf                 │
│                                        │
│ 📦 hyper (8 个函数)           [❌ 全不选]│
│   ...                                  │
└───────────────────────────────────────┘

按 crate/模块 分组，默认只勾选用户自己的 crate。这样用户不需要懂每个函数是干什么的，只需要决定"我要不要跟踪这个库的内部"。

2. Trace 根：和白名单分开

Trace 根的选择应该独立于白名单，有两种入口：

方式 A：用户主动指定（现有方式）
  → 在 Webview 的下拉框中选一个 async fn 作为 trace 根

方式 B：从断点自动推断（更自然）
  → 程序在断点停下来
  → 调试器自动找到当前所在的最外层 async fn
  → 提示用户"要从这个函数开始 trace 吗？"

白名单控制的是 trace 的"深度/广度"（跟踪哪些子调用），trace 根控制的是"从哪开始"。 这两个概念要分开。

3. 总结：三层设计

层级	谁决定	用户操作
Trace 根	用户选择或自动推断	选一个 async fn，或从断点位置自动获取
白名单	自动生成 + 模块级开关	按 crate 批量开关，默认只跟踪用户 crate
底层 poll 函数	完全自动	用户不需要关心

这样用户的心智负担就很小了：

1. 在我关心的函数上设断点
2. 断点停下后点"trace"
3. 白名单默认就是对的（只跟踪我的代码），需要深入框架时再展开对应的 crate

会议内容

1. 跨特权级跟踪功能；
2. 把vscode原生的调用堆栈加入插件；
3. ebpf 动态跟踪；
4. 把现在这个调试器写入文档中；