8.2 调试

8.2 调试

Julia 调试两套武器：断点式（Debugger.jl / VS Code）适合追逻辑错误；内省式（@descend、@code_warntype、@btime）适合追类型与性能问题。逻辑错用前者，"结果对但慢/怪"用后者，别用错工具。

断点调试：VS Code 里三步走

1. 在行号左侧点击，设红点断点；
2. 按 F5 以调试模式运行脚本；
3. 命中断点后，用面板逐行执行（F10）、步入（F11）、查看变量。

也可以在代码里直接埋断点：

using VSCodeServer   # VS Code 环境下
# 或使用通用包
] add Debugger
using Debugger

function buggy(xs)
    s = 0
    for x in xs
        s += x / (x - 3)      # x=3 时除零
    end
    s
end

@enter buggy(1:5)             # 进入命令行断点会话
​

@enter 会停在函数第一行，提供逐行（n）、步入（s）、继续（c）、打印变量（直接输变量名）等命令。

无断点排错三件套

很多时候不需要断点，三个宏就能看清一切：

# 1. 打印执行位置与值
@show xs[3]

# 2. 看类型推断（黄色 = 类型不稳定）
@code_warntype buggy(1:5)

# 3. 看每步耗时与分配
@btime buggy(1:5)
​

深潜：@descend 与 MethodError 的破案法

报 MethodError: no method matching ...(::Int64, ::String) 时，套路是：

# 1. 查看这个函数有哪些方法签名
methods(那个函数)

# 2. 看调用时实际传入的类型元组
typeof((1, "a"))

# 3. 顺着调用栈用 Cthulhu 逐层查看
] add Cthulhu
using Cthulhu
@descend 那个函数(1, "a")
​

@descend 展示"这个调用最终命中哪个方法、编译器如何特化"，是 Julia 独有的调试深度——性能问题的终极定位工具。

问题类型与工具选择

⚠️ 常见坑：断点调试器会大幅拖慢执行（逐行解释），别用它测性能；反过来，性能工具（@btime）也不会告诉你逻辑哪里错。先分类问题，再选武器。

💡 关键直觉：Julia 的报错栈是从宏展开后的代码生成的，行号偶尔"漂移"。栈里从上往下找第一个属于你自己代码的帧，通常那就是案发现场。

实战复盘：一个 MethodError 的完整破案

拿来一个真实场景把工具串起来用。背景：调用同事的包算加权平均，报 MethodError: no method matching *(::String, ::Float64)。第一步读报错栈，从上往下找第一个属于自己代码的帧，定位到自己的这行：sum(w .* xs) / sum(w)。第二步分析类型：String 从哪来？在断点或 @show 处打印 typeof(xs)，发现是 Vector{Any}，里面混着从 CSV 读入未转类型的字符串。第三步验证根因——CSV 读入时列类型被猜成了 Any：

xs_raw = ["1.2", 3.4, 5.6]           # 复现：混合类型
parse.(Float64, string.(xs_raw))     # 统一转 Float64 后问题消失
​

第四步修复并预防：读入时显式声明列类型（4.3 讲过），再给关键函数签名加约束 weighted_mean(xs::Vector{Float64}, w)，让同类错误从此在入口就被拦下，而不是在深处炸出一个费解的乘法错误。复盘这条链路，四步分别用了"读栈、看类型、复现、加约束"四种手法——这就是 2.1 类型知识与本章工具的合流：工具帮你看清类型，类型知识告诉你这意味着什么。

调试策略的优先级

经验丰富的开发者不是工具用得多，而是动手次数少。优先级排序：第一，让错误自己说话——读完整报错信息再行动，一半的错误在报错里就写明了原因；第二，二分定位——在可疑区间的中点打一个 @show，一次实验排除一半代码；第三，最小复现——把问题剥离成十几行的独立脚本，很多"环境问题"在这一步现出原形；第四才轮到断点逐行追。跳级使用重工具（一上来就断点单步）是新手最大的时间黑洞，因为断点一次只能看一条执行路径，而二分法每一步都在砍掉一半搜索空间。

数值 bug 的专项排查

科学计算有一类 bug 不报错、只给错数，工具箱要再加三件。其一，相对误差二分：拿一个可信的小算例（手算或文献值），把程序输出与真值的差异逐步缩小范围到某个函数，与 8.2 的代码二分法同理但对象是数值而非执行路径。其二，精度对照：把 Float64 换成 BigFloat 重跑一遍，结果显著变化则提示数值不稳定（灾难性消元、病态条件数），这类问题不是代码错而是算法敏度问题，要靠换算法或重排公式解决。其三，不变量监控：在循环里插入守恒量、非负性、单调性这类"必须恒真"的断言，@assert 一行，违反即报——数值漂移积累到结果可见往往已过千步，中途的不变量检查能把暴露点提前到第一步出错处。三件套的本质都是给"静默的错误"制造响亮的信号，科学计算的调试难度正在于没有报错可读，必须自己造报警器。

本节要点回顾

• 断点三件：VS Code 红点、@enter、逐行/步入/继续；
• 内省三件：@show、@code_warntype、@btime；
• MethodError 破案：methods 对签名，@descend 看派发；
• 调试性能问题别用断点，两者是平行工具箱。

最后一个习惯建议：给修过的每个 bug 留一行笔记——症状、根因、修法各一句，存进项目的备忘文件。这本"病例记录"在同种问题复发时价值千金，也是团队新人最好的培训材料。