gdb中需显式指定作用域才能打印static变量：全局static用file::var，局部static用func::var；否则报“no symbol”错误，且不可依赖当前上下文自动解析。
静态变量在GDB里不能直接用变量名打印
因为static变量具有内部链接（internal linkage），即使同名也只在定义它的翻译单元（文件）或作用域内可见，GDB默认无法无歧义地定位。直接输入p var_name很可能报错No symbol "var_name" in current context，尤其当多个源文件都有同名static变量时。
必须显式指定作用域：文件名或函数名加::
查看方式取决于静态变量的定义位置：
- 如果是
static全局变量（定义在函数外、文件作用域），用file_name::var_name，比如p utils.c::counter - 如果是
static局部变量（定义在函数内），用function_name::var_name，比如p parse_json::buffer_size - 如果当前已停在该函数内，且无重名冲突，有时
p var_name也能成功——但这不可靠，不建议依赖
static变量生命周期长，但作用域检查仍严格
虽然static变量从程序启动就存在、到结束才销毁，GDB仍按符号作用域解析，不会自动“跨文件搜索”。常见误操作包括：
- 在错误的栈帧中尝试访问
function_name::var_name（比如函数还没执行到定义该static变量的代码块） - 拼错文件名（注意大小写、扩展名，如
main.cpp不能写成main.c） - 未用
-g编译，导致调试信息缺失：gcc -g -O0是安全组合
用info variables辅助定位
当不确定静态变量确切名称或位置时，可用：
-
info variables ^counter—— 列出所有以counter开头的变量（支持正则） -
info variables -t static—— 显示所有标记为static的变量（部分GDB版本支持） -
info functions ^parse_—— 先确认函数名，再结合function::var构造完整路径
真正麻烦的不是语法，而是你得先知道它在哪定义——GDB不会替你猜上下文。
