g++编译后符号名看似乱码是因C++名字修饰（name mangling）机制：为支持重载，编译器将函数名、参数类型、作用域等编码为唯一符号，如_Z3fooi；不同编译器规则不兼容，故跨编译器链接易失败。
为什么 g++ 编译后符号名看起来像乱码？
因为 C++ 允许函数重载，而目标文件（如 .o）和链接器只认 C 风格的扁平符号名。编译器必须把函数名、参数类型、命名空间、类作用域等信息“编码”进一个唯一字符串，这就是名字修饰（name mangling）。你看到的 _Z3fooi 或 _ZNK4Base5printEv 不是 bug，是标准行为。
不同编译器用不同规则：GCC 用 Itanium C++ ABI 的 mangling 方案，MSVC 完全不兼容；Clang 默认跟 GCC 一致。所以跨编译器链接静态库几乎必然失败——不是代码问题，是符号对不上。
- 用
nm -C查看可读符号（demangle），但注意它只是猜测，不能反向还原原始声明 -
c++filt _Z3fooi可手动解码，输出通常是foo(int) - 如果头文件里声明了
extern "C"，该函数就不会被 mangling——这是 C++ 调用 C 库的底层机制
extern "C" 怎么用才不踩坑？
加 extern "C" 是告诉编译器：“别 mangling 这个东西，按 C 规则导出”。但它只影响链接符号名，不影响语法或语义。常见错误是只在定义处加，忘了声明处也得加；或者套在类定义里，结果整个类都被当 C 函数处理（报错）。
- 头文件中正确写法：
extern "C" { void my_c_api(int x); } - 定义文件里也要匹配，不能只在 .cpp 里写
extern "C" void my_c_api(int x) { ... }而头文件没声明 - 不能用于重载函数：C 链接不支持同名多签，编译器会直接报错
multiple definition of 'foo' - 模板函数不能用
extern "C"——模板实例化发生在编译期，没有固定符号名
函数重载时，哪些差异会被 mangling 编码进去？
修饰名必须能唯一区分所有重载版本。编译器会编码：函数名、参数类型（含 const/volatile/引用/指针）、返回类型（仅限某些情况，如 operator->）、const 成员函数的 cv-qualifier、是否为 noexcept（C++17 起）、模板实参等。但不会编码默认参数值或 inline 属性。
立即学习“C++免费学习笔记（深入）”；
- 这两个函数会被 mangling 成不同符号：
void f(int);
void f(double);
- 但
void g(int = 0)和void g(int)声明在同一作用域下是重复定义，编译阶段就报错，根本到不了 mangling 阶段 - 成员函数的修饰名还包含类名、嵌套深度、模板参数，比如
std::vector<int>::size()的符号远比size长得多
调试时怎么快速定位 mangling 相关链接错误？
典型错误是 undefined reference to 'xxx'，而你明明写了定义。大概率是声明与定义的签名不一致（比如一个参数是 const std::string&，另一个是 std::string），或者头文件没被包含导致隐式声明（C++ 默认 int 返回，mangling 出来完全不对）。
- 用
nm -C your_file.o | grep your_func_name看目标文件里实际生成的符号是什么 - 检查编译命令是否用了
-fno-rtti或-fvisibility=hidden：前者可能影响异常相关符号，后者会让符号默认不可见 - 如果用了模板，确保显式实例化（
template void foo<int>();）或把实现放在头文件里——否则链接器根本看不到实例化后的 mangling 符号
最麻烦的是跨编译器或混用不同 STL 实现（比如 libstdc++ 和 libc++），它们对同一标准库函数的 mangling 规则可能有细微差别，这时连 std::string 的构造函数都可能链接失败。这种问题没法靠改代码绕过，只能统一工具链。
