名称修饰是编译器给函数“贴唯一身份证”的过程
它不是语法糖，也不是运行时机制，而是编译阶段的符号编码行为：C++ 编译器把 void print(int)、void print(double) 这类同名但签名不同的函数，分别转成底层链接器能区分的唯一符号，比如 _Z5printi 和 _Z5printd。链接器只认符号名，不认 C++ 语义，没这步编码，它根本分不清哪个 print 是你要调用的那个。
为什么不用修饰就链接失败？看真实报错场景
典型错误：undefined reference to 'foo' 或更隐蔽的 undefined reference to '_Z3fooi' —— 其实是你在 C++ 里调用了 C 函数，但没告诉编译器“别修饰”。C 编译器生成的是 foo，而 C++ 默认找的是 _Z3fooi，两者对不上号。
- 跨语言混编（C++ 调 C 库）：必须用
extern "C"包裹声明 - 动态库导出函数被 C++ 程序调用：若没加
extern "C"，头文件里声明的函数名和 so/dll 里实际导出的符号名不一致 - 静态库由 GCC 编译，主程序用 MSVC 链接：
_Z3fooivs?foo@@YAXH@Z，符号规则完全不同，直接拒链
怎么查、怎么看、怎么反解修饰名？
调试链接问题时，别猜，直接看符号表：
nm -C libmylib.a | grep print c++filt _Z5printd
nm -C 表示“带反解显示”，c++filt 则把修饰名还原回可读函数签名。注意：nm 不加 -C 显示的是原始修饰名，加了才友好；Windows 下对应工具是 dumpbin /symbols。
立即学习“C++免费学习笔记（深入）”；
- Linux/macOS：优先用
nm -C+c++filt - Windows（MSVC）：用
dumpbin /exports mydll.dll或dumpbin /symbols objfile.obj - Clang/GCC 目标文件中若含模板实例，修饰名会很长（含命名空间、模板参数等），
c++filt仍可准确还原
哪些操作会意外破坏符号一致性？
名字修饰看着是编译器自动干的活，但几个常见动作会让它“失准”：
- 在头文件里漏写
extern "C"包裹 C 函数声明，且该头文件被 C 和 C++ 文件共同包含 - 导出内联函数或模板函数到动态库：它们可能未实例化，或实例化符号名随编译器版本变化（如 GCC 12 和 13 对
std::vector的修饰略有差异） - 类成员函数加
const或修改访问控制（public→private）：修饰名立即改变，旧二进制无法链接新库 - 使用不同 ABI 的标准库（如 libc++ vs libstdc++）：即使同一 GCC 版本，链接时也可能因 STL 类型修饰差异报错
