gdb中step无法进入自定义函数主因是编译优化（如-O2）导致内联或调试信息丢失，需用-g -O0编译，并避免inline声明；VS Code/CLion中F11失效多因调试配置错误或内联策略，应检查launch.json、启用Force Step Into或设精确断点。
gdb 里用 step 进入自定义函数，但得确保符号没被优化掉
默认编译的可执行文件如果用了 -O2 或更高优化级，step 很可能直接跳过你的函数体，甚至显示“no source found”。这是因为编译器把函数内联了，或者丢掉了调试信息。
- 编译时必须加
-g（生成调试符号），且避免高阶优化：g++ -g -O0 main.cpp - 如果函数被声明为
inline或在头文件里定义，step可能不生效——gdb 看不到独立的函数帧；可临时改用stepi（单步指令）或加__attribute__((noinline))强制不内联 - 确认函数确实被调用了：在函数入口设断点（
break MyClass::doSomething），再run，比盲目step更可靠
VS Code + CMake 项目中按 F11 不进函数？检查 launch.json 的 miDebuggerPath 和 externalConsole
F11（Step Into）失效常见于调试器没正确关联到源码，尤其是跨目录或子项目时。不是代码问题，是调试配置链路断了。
- 确保
launch.json中program指向的是带-g编译出的可执行文件，而不是 build 目录外的旧版本 -
miDebuggerPath必须指向真实 gdb/lldb，比如/usr/bin/gdb；Windows 上若用 WSL，不能填 Windows 路径 -
externalConsole设为true后，F11 有时会卡在控制台输入等待状态——关掉它，让输出走 debug console - 如果函数在动态库（.so/.dll）里，需确认
sourceFileMap正确映射了构建路径和源码路径，否则 VS Code 找不到 .cpp 行号
Clion 调试时 step into 跳过了函数体，可能是内联或模板实例化问题
Clion 底层用的是 GDB/LLDB，但它对 C++ 模板和内联的处理更激进，默认倾向“跳过实现，只停声明”。这不是 bug，是它的默认策略。
- 右键点击函数调用 → 选
Force Step Into（快捷键通常是 Shift+F7），它会忽略内联提示，强行进入 - 模板函数要进具体实例：比如
process<int>()，直接step into可能停在泛型定义处；先在实例化行打断点，再用Force Step Into - 检查 Settings → Build → Compiler → “Enable inlining” 是否勾选——如果勾了，编译时就内联了，调试器根本看不到函数边界
函数有多个重载时，step 进错版本？用 info functions 确认实际调用签名
gdb 的 step 是基于运行时实际跳转地址决定的，但重载函数名相同，容易误判进了哪个。尤其当参数类型隐式转换后，实际调用的可能不是你眼中的那个函数。
立即学习“C++免费学习笔记（深入）”；
- 停在调用行后，执行
info functions your_function_name，列出所有匹配符号及其完整签名 - 用
disassemble看当前 call 指令的目标地址，再info symbol 0x...反查对应函数名 - 更稳妥的做法：在疑似目标函数第一行设断点（如
break namespace::MyClass::method(int)），用括号明确参数类型，避免歧义
step 就变成“随机跳”。与其反复试，不如先 readelf -S ./a.out | grep debug 确认调试段存在，再动手。 
