c++oding="utf-8" ?>
__cxa_demangle 用于将原始修饰名（如 _Z1fv）转换为可读声明（如 void f()），而非反向获取修饰名；其正确调用需传入有效修饰名、非空 status 指针，并用 free() 释放返回内存。
为什么 __cxa_demangle 返回的不是原始修饰名而是可读名
很多人以为调用 __cxa_demangle 是为了“还原”出像 _Z1fv 这样的原始修饰名（mangled name），其实完全相反：它把修饰名转成人类可读的声明形式，比如 void f()。原始修饰名本身是编译器生成后就固定存在的字符串，不需要“获取”——你得先有它，才能传给 __cxa_demangle 做反解。
所以真正在找“原始修饰名”的场景，通常是：从符号表、dladdr、backtrace_symbols 或调试信息里拿到一个已 demangle 的名字，想倒推回去；或者在运行时想查某个函数地址对应的原始修饰名（比如用于符号过滤、hook 注入或 ABI 兼容性检查）。
如何从函数地址拿到原始修饰名（Linux / ELF）
没有标准 C++ 接口能直接从函数指针反查修饰名。必须依赖平台工具链和动态链接器行为：
-
dladdr只返回符号名（已 demangle 过的，或未被 strip 时的原始修饰名，取决于系统配置和 libc 版本）；它不保证返回 mangled 名 - 更可靠的方式是：用
addr2line -C -f -e your_binary 0xADDR（-C启用 demangle，但加--no-demangle才能得到原始修饰名） - 若需纯运行时，可读取
/proc/self/maps定位模块，再用libelf+libdw解析 .dynsym 或 .symtab，从中提取st_name对应的字符串表项——那才是原始修饰名 - 注意：
g++默认启用-frecord-gcc-switches和-g时，.comment 段可能含编译命令，但不存符号名
__cxa_demangle 的正确用法和三个关键陷阱
这是唯一标准 ABI 提供的 demangle 接口，头文件为
- 第一个参数必须是原始修饰名（如
"_Z1fv"），不能是"f"或"void f()"，否则返回nullptr - 第二个参数（
output_buffer）传nullptr时，函数会 malloc 一块内存并返回；调用者必须用free()释放，**不能用delete或std::free以外的释放方式** - 第三个参数（
length）是输出缓冲区长度，仅当第二个参数非空时才有效；第四个参数（status）必须传非空指针，否则行为未定义 —— 常见错误是忽略它，导致崩溃或静默失败 - 返回值为
char*，内容是 C 字符串，不是std::string；且若status == 0才表示成功，其他值如-1（无效 mangled name）、-2（内存不足）、-3（内部错误）都需检查
示例片段：
int status;
char* demangled = __cxa_demangle("_Z1fv", nullptr, nullptr, &status);
if (status == 0 && demangled) {
printf("demangled: %s\n", demangled);
free(demangled); // 必须用 free
}
跨平台获取原始修饰名为什么几乎不可行
Windows（MSVC）用的是完全不同的一套 name mangling 规则（如 ?func@@YAXXZ），且无公开稳定的 runtime demangle 接口；UnDecorateSymbolName 只能做反向（demangle），不能从可读名生成 mangled 名。macOS（Itanium ABI 兼容）虽也支持 __cxa_demangle，但 dladdr 在 dyld 中对符号名的处理逻辑与 Linux 不同，常返回空或截断名。
真正可靠的跨平台方案只有预编译时固化：用 __PRETTY_FUNCTION__ 或 __FUNCTION__ 获取声明级字符串，再通过宏 + 编译器内置函数（如 __builtin_dump_struct 不可用）或外部工具（c++filt -p）离线生成映射表。运行时靠 ABI 接口“反查原始修饰名”，本质上是个伪需求——原始修饰名只在链接和加载阶段有意义，一旦进入运行时，符号系统已抽象为地址+名称对，而名称本身是否 mangled，取决于你怎么暴露它。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
