remote gdb 调试 so

print 加日志能修九成的 bug，剩下一成需要真正的调试器：断点、单步、看内存。鸿蒙 native 侧的远程调试（gdb 模式）这篇入门。

▍环境准备
调试链路：设备上的调试服务（随应用或随开发工具就位）——网络连接（设备与开发机同网或经端口转发）——开发机上的调试器前端。应用侧准备：带调试符号的 so（调试构建或符号包配对——符号准备篇的产出）、可调试的构建配置（编译带调试信息与最小优化，优化全开的单步会跳行乱序）。

▍连接与附加
两种形态：启动调试（从应用启动就断住，适合初始化问题——启动黑屏、加载失败的现场）；附加调试（ attach 到运行中的进程，适合运行时问题——操作触发、状态异常）。附加要快：先起进程再附加的窗口期，初始化早的问题抓不住——那就用启动调试形态。

▍基本动作
断点（按函数名或文件行，框架库的符号也能断——有符号就能断）、条件断点（命中条件才停，高频路径的必备）、观察点（内存或变量变化即停，抓数据被谁改的）、单步与调用栈查看（多线程时切换线程看各自的栈）。移动场景的节奏：断点停住时应用界面冻结，系统可能判定无响应——长停在主线程的操作要快，或改在后台线程断。

▍实战技巧
崩溃现场复原：崩溃栈的地址配合调试器符号化（core 或崩溃报告场景）。库加载断点：动态加载的库，断点要在库加载后下（加载失败就断在加载函数）。多进程（隔离架构）：调试器分别附加主进程与子进程，或专注一侧。真机 vs 模拟器：行为差异注意（模拟器缺的驱动行为在调试期发现不了）。

▍限制与替代
不能断的路径：系统回调内部、内核态。替代武器：日志（永远的第一选择）、跟踪（性能类）、崩溃报告（时序类）。调试器是重武器，用在对的地方：状态难以从外部观测的内部逻辑、数据流追踪、死锁现场。

▍建议
调试环境配置脚本化（连接命令、符号路径、常用断点脚本存成文件），每次现场不用从头搭。

更多真实移植案例，欢迎到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录。