lldb与gdb命令不一一对应，lldb强调表达式驱动、需用breakpoint set而非break，step/next/continue等命令结构不同，po/p行为区别于gdb的print，且无display等价命令，寄存器和内存操作语法也迥异。
LLDB 和 GDB 命令不是一一对应的，直接套用会卡住；核心差异在于 LLDB 更强调“表达式驱动”，而 GDB 更偏向“命令驱动”。
常见断点与执行类命令映射
断点设置、单步、继续这些基础操作最容易混淆，尤其在 Xcode 中默认用 LLDB 却习惯性敲 gdb 命令时：
-
break main（GDB）→breakpoint set --name main或简写br s -n main；LLDB 不接受不带参数的break，必须明确指定位置 -
next（GDB）→thread step-over或so；step（GDB）→thread step-in或si；注意step在 LLDB 中是无效命令 -
continue（GDB）→process continue或c；但c在 LLDB 中不能省略为cont或run，后者仅用于首次启动 -
finish（GDB）→thread step-out或so；LLDB 没有同名命令，容易误以为缺失
变量查看与表达式求值差异
LLDB 的 po 和 p 行为和 GDB 的 print 逻辑不同，尤其对 Objective-C/Swift 对象或 STL 容器：
-
po obj（LLDB）只对可识别的 Objective-C/Swift 对象调用description，对 C++ 对象可能报错；p obj才是通用类型打印，类似 GDB 的print - GDB 的
display（自动刷新变量）在 LLDB 中没有等价命令；需手动重复p或用expression+ 断点命令模拟 -
expression -- (int)arc4random()（LLDB）可运行任意上下文表达式，GDB 的expr功能类似，但 LLDB 不要求结尾分号，加了反而报错
寄存器与内存调试命令不兼容
寄存器读写、内存 dump 这类底层操作，命令结构完全不同，硬记缩写容易翻车：
-
info registers（GDB）→register read（LLDB）；register write pc 0x1000才能改 PC，不是set $pc = 0x1000 -
x/4wx $sp（GDB 内存查看）→memory read -f x -c 4 $sp；LLDB 必须显式指定格式（-f x）、长度（-c 4），缺一不可 -
image lookup --address 0x100003f80（LLDB）是 GDB 没有的关键能力，能反查符号和行号，崩溃后第一件事就该跑它
别依赖 help 列表，优先查官方映射表
LLDB 的 help 只列命令骨架，不说明语义差异；GDB 老用户容易按旧习惯输入 bt 发现没反应——其实 LLDB 是 thread backtrace，但更常用的是右侧调试导航栏直接看。
- 权威映射表始终以 https://www.php.cn/link/7cc67bd2ac2852fd3c9196308b7c1fd1 为准，不是社区整理的二手列表
- Xcode 控制台里敲
help breakpoint看到的是子命令集合，但help breakpoint set才给出真正可用的参数选项 - 所有 LLDB 命令都支持 Tab 补全，
br s -n <tab></tab>会提示当前符号，比死记命令更可靠
最常被忽略的是：LLDB 的命令解析器默认不启用 Python 脚本支持，po 对 Swift 类型失效、STL 容器显示为地址而非内容，往往不是命令写错，而是初始化文件（~/.lldbinit）里没加载对应 formatter。
