CLion的Evaluate Expression仅支持调试中当前栈帧的C/C++表达式求值，受调试器限制；常见错误源于调试信息缺失、优化导致符号丢失、自定义类型解析失败、副作用函数未启用执行权限等。
CLion 的 Evaluate Expression 功能不是“运行任意 Lua 或 Python 代码”的沙盒，它只能在调试会话中、当前栈帧上下文中求值 C/C++ 表达式（含宏、变量、函数调用），且受调试器后端（GDB/LLDB）能力严格限制。
为什么 Evaluate Expression 显示 “error: summary string parsing error” 或直接失败
常见原因不是表达式写错，而是调试信息缺失或类型解析异常：
- 编译时未启用调试符号（
-g）或启用了优化（-O2及以上），导致变量被优化掉或类型信息不全 - 字符串变量底层是自定义结构体（如 FreeRTOS 的
char*指向堆内存），GDB 默认无法安全展开，需手动添加-fno-limit参数或改用print *(char[64])ptr强制读取 - 调用的函数有副作用（比如修改全局状态），GDB 默认禁止执行，需勾选
Enable code execution才允许（但会改变程序行为） - 表达式涉及模板实例化或内联函数，LLDB 支持较好，GDB 在某些版本中会报
no symbol table
如何在调试中安全求值指针、结构体和数组
直接输入 my_struct 可能只显示地址，要看到内容得明确指定解引用方式：
- 对指针：写成
*my_ptr（查看所指对象）或my_ptr[0]（查看首元素） - 对数组：用
arr@10查看前 10 个元素（GDB 语法），LLDB 中等效为expr -- (int[10])arr - 对结构体字段：支持链式访问，如
task_handle->pxTopOfStack，但前提是该字段在调试信息中可见 - 对宏定义：仅当编译时用
-g3且宏在当前作用域有效时才可求值；否则会提示undefined symbol
什么时候不该依赖 Evaluate Expression 而该用 Watches
Evaluate Expression 是一次性的、手动触发的，而 Watches 是持续监听的，适用场景完全不同：
- 需要观察变量随步进动态变化 → 用
Watches窗格添加counter或list->next->val - 临时验证一个复杂条件是否成立（如
(a & 0xFF) == 0x55 && b > threshold）→ 用Evaluate Expression快速试算 - 想调用一个无副作用的调试辅助函数（如
uxTaskGetNumberOfTasks()）→ 必须在Evaluate Expression中勾选Enable code execution，且确保函数未被编译器内联 - 尝试打印大数组或递归结构体 → 容易卡死或触发 GDB 内存保护，应改用
printf日志或内存视图（Memory View）
最常被忽略的一点：表达式求值结果依赖于当前线程和栈帧。切换线程或帧后，之前能求值的变量可能变成 <optimized out></optimized> 或 Cannot access memory —— 不是功能坏了，是上下文变了。
