LLDB调试完全入门：从基础命令到实战排查技巧

做iOS开发这几年，我越来越觉得LLDB是那种“平时不怎么在意、一到关键时刻能救命”的工具。这话一点不夸张：你在Xcode里点那个“继续”按钮、在断点行上看变量、往控制台敲po self.model，底层全是LLDB在干活。LLDB的全称是Low Level Debugger，是LLVM项目里负责调试的核心模块，从苹果的Xcode，到Linux上各种IDE集成的调试器，再到很多逆向分析工具，背后都有它的身影。

这篇入门指南写给谁？给那些刚接触iOS开发、还在“只会点绿色三角”阶段的新手，也给写了好几年代码但始终停留在图形界面操作、一进命令行就慌的程序员。目标只有一个：让你在遇到断点、crash、变量看不到值这类问题时，不再靠猜，而是能主动去查、去定位、去解决。我不打算把LLDB的官方文档搬过来翻译一遍，而是把平时真正用得上的命令、场景和坑，按实际调试时的思考顺序串起来讲，每一条都是可以直接上手的。

1. 先搞明白LLDB是什么

1.1 lldb命令背后的那套系统

很多人的第一反应是：LLDB不就是Xcode底部那个黑框吗？其实不完全是。Xcode底部那个调试控制台，只是LLDB的交互入口之一。lldb本身是一个独立的命令行调试器，你可以直接在终端里启动它，用它调试一个C、C++、Objective-C或者Swift写的可执行文件。它和gdb是同一类东西，但又不一样——gdb是GNU方案里的调试器，而LLDB是LLVM这套编译器工具链中的调试组件，和clang等共享底层架构。这意味着它对Swift、Objective-C这些Apple生态的语言支持，比很多调试器要好很多，特别是Swift的高级类型信息，在LLDB里能展现出比gdb友好得多的视图。

可能你会问：我用Xcode不是已经可以调试了吗，为什么还要学命令行？因为图形界面只能覆盖最常见的那几条套路：打断点、暂停、步进、看变量。但当你碰到“这个变量为什么被改成了0”或者“这个crash到底发生在哪一行”这种问题，图形界面往往就帮不上忙了。图形界面上你能用到的每一个功能，几乎都能在LLDB里找到更精确、更可控的命令形式。我之前遇到一个特别迷惑的内存被改写问题，图形界面根本看不出什么，最后就是用watchpoint在内存位置上下断点，轻松定位到了是哪一行代码越界写的。

1.2 你其实每天都在用LLDB

可以这么说，所有用过Xcode的人，都已经在用LLDB了，只是自己没意识到。你在代码行号左边点一下，在那里弹出一个小红点，运行后在断点处暂停，然后在变量区看到当前对象的值——这背后的机制就是LLDB。你右键某个变量，选择"Print Description"，它会调用LLDB的po命令。你按下调试工具栏上的暂停键，程序收到SIGSTOP信号后停在某个位置，你在左边看到当前线程和调用栈，这些窗口上的一举一动，底层都是LLDB在响应。

那为什么还要专门学命令行？因为图形界面是一个“简化版”的LLDB，它把命令包装成了按钮和菜单，但很多高级能力没有暴露出来。比如给断点设置一个条件让它只在满足某个逻辑时才暂停，比如给一个断点挂一组自动动作，比如在暂停状态下任意修改一个对象的内存值再继续运行。这些东西在UI上要么藏得很深，要么压根没有入口。而命令行版本把这些能力全打开了。你只要记住几个核心命令，能做的事比点按钮多一个数量级。

1.3 从环境准备开始

如果你只用Xcode，那LLDB已经内置好了，不用额外安装。但如果想在终端里单练，建议你先确认自己的命令行工具链是完好的。Mac上一般执行xcode-select --install就能把命令行工具装好。装好之后，随便写个C文件试试：

cat > main.c <<EOF #include <stdio.h> int main() { printf("hello\n"); return 0; } EOF clang -g main.c -o main lldb ./main

-g参数很重要，它告诉编译器保留调试符号，没有调试符号，LLDB就看不到源码、变量名这些信息，调试体验会大打折扣。进入lldb交互环境后，你输入help就能看到所有支持的子命令，输入quit退出。这一步走通，后面的内容就可以一路玩下去了。

2. 最常用的LLDB命令：建立调试手感

2.1 先学会用help查一切

LLDB这套命令体系一开始最让人困扰的就是命令太多了。但其实它有很清晰的层级结构。最外层是help，它会列出所有一级命令，比如breakpoint、thread、frame、expression、memory、register等等。想知道某个一级命令下面还有哪些子命令，就继续加参数，比如help breakpoint会列出跟断点相关的所有操作。想再深入一层，比如help breakpoint set，就会显示breakpoint set支持的参数和示例。这套“层层help”的办法，比硬记文档高效得多。

我在带新人的时候经常看到这样的场景：遇到一个不会用的命令，立刻去搜索“LLDB XXX用法”。其实先敲一下help往往更快，它的说明和示例都写得相当清楚。而且它会把参数缩写一并列出来，比如-f对应--file，-l对应--line，这些缩写你在网上查到的代码片段里经常会碰到，用help就能把它们对应起来。

2.2 运行、暂停、步进的完整闭环

调试一个程序，核心就是“让它跑一会儿、停下来检查、再继续跑”。这几个操作在LLDB里分别是：

• run（缩写r）：启动或重新启动进程，后面可以带参数，比如run arg1 arg2。
• continue（缩写c）：从当前暂停位置继续执行，直到下一个断点或程序退出。
• step（缩写s）：单步执行，遇到函数调用会进入函数内部。
• next（缩写n）：单步执行，但把函数调用当作一步跳过。
• finish（缩写f）：一直执行到当前函数返回，然后停在返回处。

举个例子，我在调试一个排序算法时，会用n一步步走外层循环，用s钻进某个方法看看内部实现，用c快速跳到下一个断点，用f从当前函数里跳出来。这套组合拳配合断点，基本能覆盖90%的“走到哪看到哪”的调试需求。

2.3 别被缩写绕晕

LLDB的一个贴心之处，是它对很多常见命令提供了别名，而且很好记。n就是next，s就是step，c就是continue，f就是finish，bt就是thread backtrace。这些别名不是凭空造的，很多是为了兼容老gdb用户的习惯。所以你在网上看到的LLDB片段经常是一堆短命令，像br s -f xxx.swift -l 12这种看着吓人，其实拆开就是breakpoint set --file xxx.swift --line 12，完全不神秘。

还有两个高频别名要特别记：p和po。p是expression --的别名，用来求值一个表达式，打印结果和类型；po是expression -O --的别名，会对对象调用debugDescription/description/dump这些方法来打印更友好的描述。在ObjC时代，po几乎是无敌的，因为大部分对象都实现了description；到了Swift时代则要注意，后面我会专门展开讲。

2.4 手动暂停：排查卡顿的第一步

除了在断点处暂停，LLDB还支持手动让进程暂停。你正在跑一个App，突然感觉界面卡住了，这时候去Xcode顶部点那个方形的“暂停”按钮，程序就会立即停下来。这个操作本质上就是给进程发了一个SIGSTOP信号，然后LLDB接管，停在你当前正在执行的那一行。

停下来之后第一件事不是瞎看，而是输入bt看当前线程的调用栈。很多主线程卡死问题，一看bt就能发现是某个耗时的网络回调或者同步锁把主线程堵死了。我在排查一个启动卡死问题时，就是靠暂停主线程、再看bt，一两分钟就锁定了那个在启动路径上执行同步磁盘读取的代码。这种排查方式不依赖任何断点和预先设置，属于“飞行中体检”，是每个iOS开发者都应该掌握的看家本领。

3. 断点：从图形界面走向命令行

3.1 行断点、方法断点和符号断点

在Xcode图形界面上，你点行号就能打一个行断点，对应的命令是breakpoint set。

breakpoint set --file ViewController.swift --line 42 breakpoint set -f ViewController.swift -l 42

这两行是等价的，只是后者用了缩写。还有一个常见需求是给某个方法打断点，比如每次进入viewDidLoad都停一下。

breakpoint set --name viewDidLoad breakpoint set --method ViewController.viewDidLoad

区别在于：--name会用符号名做匹配，只要名字对得上就会命中；--method则更“语言化”一点，对C++、Swift这类带命名空间的方法更友好。如果你在做ObjC调试，还经常用--selector按selector来打断点，比如breakpoint set --selector viewDidLoad，因为ObjC的消息发送本质是找selector。

这些命令可能看起来没有图形界面直观，但它们能解决图形界面解决不了的问题。比如你想给“所有类里的dealloc方法”都打断点，图形界面一个一个点会疯掉，命令行一条breakpoint set -n dealloc就搞定了。

3.2 条件断点：让LLDB只在特定情况下停

实际调试中，最常见的痛点是“循环到第某个值才出错”。如果你在循环体内打断点，程序会停无数次，你得一次次点继续，点到手抽筋。这时候条件断点就派上用场了。

在LLDB里，给已有断点加条件的命令是breakpoint modify或者breakpoint set时直接带-c参数。

breakpoint set -f main.swift -l 28 -c 'i == 5'

也可以先创建一个断点，拿到ID之后再补条件。假设它ID是2：

breakpoint modify -c 'i == 5' 2

这里要特别注意，条件表达式是在调试器里求值的，不是在编译时求值，所以它可以用你当前帧里能看到的所有变量。条件可以是i >= 10 && arr.count > 0这种组合，也可以是调用某个方法，只要表达式能被LLDB正常解析。不过也别写太重的表达式，因为每执行到这一行它都会被求值，如果里面调用了毫秒级耗时的函数，程序会明显变慢。

3.3 断点自动动作：一条命令干一堆事

条件断点只能解决“停止与否”的问题，但有些场景下你根本不希望程序停，只希望在某个位置自动打印一些信息，然后继续跑。这就是断点动作的用途。

breakpoint command add 2 > frame variable > continue > DONE

上面这段的意思是：断点2每次命中后，自动执行frame variable打印当前栈帧的局部变量，然后执行continue立刻继续运行。最后一行DONE是结束输入的模式标志。如果想查看某个断点已经挂了什么动作，用breakpoint command list 2；想清掉动作，用breakpoint command delete 2。

这种打法非常适合日志型调试。我调试过一段很复杂的数据解析，中间有个状态字段频繁变化，但又不想手动一次次打断点。我把断点设在状态更新那行，让每个断点自动打印当前状态和关键变量，再自动继续，跑完一次流程等于拿到一份自动生成的现场日志。这种方式比在代码里临时加print要干净得多，因为它不需要改源码、不需要重新编译。

3.4 断点启停删，批量管理

断点一多，管理就是问题。breakpoint list（缩写br l）能列出所有断点，每条都有编号和状态。breakpoint disable 1/breakpoint enable 1/breakpoint delete 1分别对应停用、启用、删除。这里有个细节：disable不会移除断点信息，只是暂时不生效，适合临时不想停但又不想删的场景。

还有一种“一次性断点”，用-o参数创建，比如breakpoint set -o -f main.swift -l 30，它命中一次之后会自动删除。这个在图形界面上“右键断点 -> Delete Once”差不多。我经常用它来做那种“我就要在这一行看一次，看完就走”的临时观察。断点操作这件事，熟练之后你根本不会想去图形界面里一个个右键点了。

4. 查看数据：frame variable、expression和po的真相

4.1 用frame variable快速浏览当前栈帧的局部变量

进程停住之后，最自然的想法是“我现在能看到哪些变量”。最直接的命令是frame variable，它会把当前栈帧里所有局部变量和参数都列出来，包括变量名、类型、值。

frame variable frame variable self frame variable self.name

不加参数会列出全部，加参数可以只看某个对象。它还可以配合--no-args、--no-locals这种选项过滤输出。对于Swift结构体，frame variable输出往往比po更工整，因为它走的是类型系统直接描述值，而不是调用description方法。frame variable只能看当前栈帧能找到的东西，如果你想看别的栈帧，得先用frame select切换过去。

4.2 expression：正式状态下执行任何代码

如果说frame variable是“看”，那expression就是“干”。它能在调试暂停的进程里执行一段真实的表达式，返回结果，甚至可以修改内存里的值。

expression self.title = "新标题" expression self.view.alpha = 0.5 expression print("hello") expr var x = 5 expr x = x + 10

这些代码不是开发时写在工程里的，而是LLDB在你暂停的进程里临时编译出来并执行的，所以你可以用它来操控正在运行的程序。这也是LLDB一个很强大的能力：动态修改变量，调试UI跳转、网络请求这类问题时会非常方便。比如我想看某个隐藏的页面长什么样，可以在断点处直接expr self.navigationController?.pushViewController(nextVC, animated: true)，不用重新编译就能跳到那个页面去观察。

4.3 po不是万能药

po在ObjC时代几乎是调试神器，因为它能调用对象的description或者debugDescription方法，输出一个可读性很高的描述。它的全名是expression -O --，其中-O就是“object描述”的意思。但在Swift下有一个经典陷阱：某些值的类型没有实现CustomStringConvertible或者CustomDebugStringConvertible，直接po只能看到类似Some或者一堆地址数字，完全没法看。

这个时候可以试试expression -l swift --来强制用Swift语言模式求值，或者直接frame variable看原始值。另一个办法是在代码里临时给这个类型扩展一个CustomStringConvertible实现，这样LLDB在打印时也能受益。总之，po很好用，但遇到不给力的情况，不要死磕，换frame variable或者普通expression往往更有效。

4.4 Swift调试里的几个细节

Swift和ObjC在调试时有个大区别：编译器优化和类型信息对调试的影响更明显。比如你写了一个let常量，在Debug编译下应该还能看，但如果那个值被编译器内联了，frame variable可能也显示不出来。这时建议优先用expr -l swift -- let x = ...这种显式模式来写表达式，规避语言层的推导问题。

还有一个细节：Swift的字符串、数组、字典在LLDB里的展示非常依赖类型系统的支持。如果你在调试某个自定义的泛型容器时看到一堆奇怪的内部字段，别急着崩溃，那很可能是类型信息没完全加载，换个时刻再试，或者用type lookup这个命令去查看具体类型定义，能帮你理解底层存储结构。

5. 线程和调用栈：崩溃现场的正确打开方式

5.1 线程列表和切换

程序停住后，thread list会列出当前进程的所有线程，每个线程的前面会有一个编号，当前停住的线程会标记出来。thread select <编号>可以切换到指定线程。

在iOS上，主线程通常是编号1，但这条不是绝对的，Apple平台API层面你随时可以用主队列来判断。我用这个组合最多的场景是：UI没响应，停住后先thread list看看各线程状态，如果看到某个线程堆积了大量网络call，基本就能锁定卡死的来源。切换线程之后，再用frame variable看的自然就是那个线程里能看到的变量了。

5.2 backtrace与栈帧切换

thread backtrace，简写bt，输出的就是从当前执行点往上一直追溯到入口函数的调用路径。这几乎是crash排查里最高频的命令。后面可以带参数控制输出，比如：

bt bt all bt -c 10

bt all会把所有线程的调用栈都打印出来，这是分析主线程是否卡死在另一个线程等待的场景的神器。bt -c 10是只打印最上面10帧，栈很深时输出简洁很多。看到每一帧前面的数字，比如frame #0、frame #3，这些数字就是栈帧编号。用frame select 3可以切换过去，之后frame variable看到的就是那个栈帧里的局部变量。我在定位一个深层次递归导致的crash时，就是一层一层frame select上去，最终找到出错的那一行输入参数。

5.3 一个踩过的坑：只看错误日志不看栈

有一次我拿到一份crash报告，错误日志里写着“Thread 1: EXC_BAD_ACCESS”，对应的代码位置是个很正常的字典读取。单看这一行，根本不知道为什么会崩。后来在真机上复现，用bt看了完整调用栈，才发现在进入这个方法之前，一个对象的生命周期已经被提前结束，字典读取时其实是在访问已释放的内存。如果只看表面错误日志，这个问题是定位不了的。所以我在带人的时候反复强调：crash的时候，一定要先bt，再看日志。栈是骨架，日志只是皮肉。

6. 进阶技巧：image、watchpoint和memory

6.1 image lookup：按符号或地址找信息

image这组命令是用来查模块和符号信息的。最常用的三个场景：

• image lookup --name viewDidLoad：按符号名反查它在哪个模块、哪个文件。这个对确认符号是否存在很有用。
• image lookup --address 0x10400abcd：输入一个内存地址，输出它对应的方法名、文件名、行号。这种场景在拿到崩溃地址时最常用，比如日志里只有0x000000010400abcd，你就能反解出它是哪一行代码。
• image list：列出当前进程加载的所有镜像库和模块，配合-o可以看模块偏移量，是做符号还原和分析动态库加载时必备的命令。

记得有次我们包里集成的一个第三方二进制库崩了，公司内部没有源码，只有一份崩溃地址。我打开工程，在崩溃现场暂停，用image lookup -a 崩溃地址直接反解出它落在这个库的哪个偏移段，再结合反汇编和团队提供的符号表，很快锁定了是哪个API传入的非法参数。

6.2 watchpoint：让内存改动无所遁形

watchpoint是另一个我非常喜欢的调试功能，简单说就是监听某个变量或内存地址，只要它被修改，程序就停下来，并告诉你是在哪一行代码写变了它。常用命令：

watchpoint set variable self.count watchpoint set expression &self.count watchpoint list watchpoint delete 1 watchpoint modify -c '(value == 0xff)' 1

watchpoint set variable比较直观，指定变量名即可。但如果变量本身是被某个悬空指针写的，那监听这个变量的地址可能不现实，更稳妥的是watchpoint set expression &xxx，监听它真正的内存地址。条件watchpoint则能进一步过滤，比如只在值变成某个特定数字时才停。这个功能在排查“某个属性莫名其妙被改”类问题时，简直就是回放录像带，能直接定位到肇事代码行。

6.3 memory与register：直接操作底层数据

memory命令组用来读写指定地址的内存。比如：

memory read 0x16f4f0f00 memory read --size 4 --count 8 0x16f4f0f00 memory write 0x16f4f0f00 0xdeadbeef

第一个是读默认长度，第二个指定每4字节读8个值，第三个是写入一个32位整数。这类操作对理解指针、数组越界、struct内存布局特别直观。register read则能看到当前CPU寄存器快照，register write可以直接改某个寄存器的值。说起寄存器，重点不是背寄存器名称，而是理解在某个调用约定下，参数怎么传、返回值放哪里。真机上的x0、x1通常就是函数参数，碰到反汇编的时候会很有用。这些底层操作平时用得少，但一旦遇到“内存被改”“运行时异常”这类疑难杂症，它们能帮你绕过所有表象直接看真相。

7. 配置你的.lldbinit，让调试更顺手

7.1 从.lldbinit设置默认行为

LLDB每次启动时会自动读取~/.lldbinit这个文件，里面可以写上所有想在启动时执行的命令。最常见的就是定义别名：

command alias pvc po self.view command alias bt-all thread backtrace all

写完之后，下一次启动lldb时，pvc就会打印当前控制器视图的详细描述。这个文件还可以放settings set，比如settings set target.max-string-summary-length 1024，能让你一次性看到更长的字符串内容，避免长字符串被截断看不清。只要在当前工程里用到这些命令，它都会生效。

7.2 Python脚本和类型格式化

LLDB另一个大杀器是支持Python脚本。你可以用command script import xxx.py加载一个脚本，脚本里能用Python定义命令、修改输出格式、给自定义类型添加漂亮的summary。比如你有一个Person类型，默认打印一堆内部字段，你可以写一个Type Summary脚本，让它像输出name: 张三, age: 25这样展示。这个能力很强大，但对入门用户来说不一定马上用得上，建议先掌握前面的基础命令，等真正遇到“每次都要重复敲一堆命令”的痛点再去学脚本化也不迟。

7.3 小心你的别名变成坑

有一点要提醒：.lldbinit里的别名是全局生效的，如果你在一台机器上设了某个别名，换个同事的电脑或者CI环境，命令可能就不存在了。所以里面最好只放个人习惯的增强配置，而不要把某个命令的顺序或参数过度依赖在你的脚本上。另外一个容易忽视的点是~/.lldbinit的语法错误会导致LLDB启动时报警告，但一般不会阻止后续使用。这个文件虽然小，花几分钟规划一下还是值得的。

8. 常见问题与排查技巧实录

8.1 一张速查表解决日常卡壳

我把入门阶段最常遇到的问题整理成一张表，遇到同类问题直接对照着找思路。

8.2 Debug模式下看不到变量值

这个问题很常见，尤其在旧设备和复杂类型上。Debug模式下LLDB默认能显示的只是带调试信息的部分，并不是所有变量都能即时可见。如果遇到某个字段显示不出，我一般会先用frame variable --format hex看原始内存，看看地址和类型是不是合理；再不行就切到汇编视图，用寄存器去找。大多数时候是编译优化导致的，那就回到编译设置里把优化关掉，比如在Debug配置里确保Optimization Level是-Onone。这个设置对调试体验影响极大，我见过不少团队Debug编译开-Os，结果一堆断点变量看不到，浪费时间排查。

8.3 断点不命中的真实案例

去年有位同事在Xcode里给某个文件第42行打了断点，程序运行后无论如何都不停。他以为是LLDB坏了，后来我用breakpoint list看，发现断点状态显示“pending”，意思是符号还没被解析到。进一步的image lookup -n确认目标方法根本不在当前二进制里。原因是那一块的代码是动态库里的，在打了断点时动态库还没加载，需要等库加载后再重新执行一次breakpoint set，或者启用“wait for debugger”之类的机制。这个案例说明：断点不命中，先确认不是断点设置问题，再看符号是否存在，最后再考虑优化因素。排查问题要有顺序，不然很容易白折腾半天。

8.4 给新手的三个小建议

第一，把help当成随身字典，用多了自然就记住了。第二，给自己设计一套“调试三板斧”：遇到问题先bt看栈，再frame variable看变量，最后用expression验证猜想。第三，不要怕命令行，LLDB的命令体系远比想象中简单，它只是一层层的“动词+宾语”，多敲几次就肌肉记忆了。

再分享一个小技巧：调试UI问题时，我经常把一个断点设在-[UIView layoutSubviews]这个符号上，然后配合条件断点只在自己那个自定义视图的实例上暂停，可以非常高效地观察到布局阶段的所有调用和参数。真机上跑不动的时候，优先在模拟器上复现，simulator的LLDB处理性能和稳定性通常比真机好不少。记住一点，LLDB的意义不是让你变成命令行高手，而是让你在别人还在瞎猜的时候，能最快看到真相。这套东西越用越顺手，多用几次你就不想回去了。