新编写C++代码时是否还有合理理由使用extern链接说明符？

关于无公开头文件、仅通过工厂函数暴露类的写法的优劣 #

这种写法并不是反模式，恰恰是C++里**实现隐藏/不透明指针（Opaque Pointer）**的常见实践，和常规的头文件+源文件拆分的写法相比，它的优势非常突出：

• 彻底隔绝实现细节：调用方完全看不到Foo的内部结构、成员定义、甚至它依赖的头文件，大幅降低编译期依赖，整个项目的编译速度会有明显提升。更重要的是只要你暴露的外部接口（比如工厂函数、后续新增的Foo操作函数）不变，你随便修改Foo的内部实现，所有调用方的翻译单元完全不需要重新编译，ABI兼容性极强，做对外发布的动态/静态库的时候这个特性尤为重要。
• 减少符号泄露：Foo本身的类型符号完全不会对外暴露，只有你主动导出的接口函数会对外可见，大幅降低命名冲突的概率，也避免内部实现被外部滥用。

当然这种写法也有适用边界：如果是内部小模块、接口迭代非常频繁的场景，每次加Foo的操作接口都要同步加导出函数、调整extern声明，反而会降低开发效率，这时候用常规的头文件拆分写法更合适。

关于新代码中使用链接说明符用途的extern的理由 #

你提到的直接在.cpp里写extern声明函数的用法确实不推荐，可维护性很差，正常场景下extern一般配合头文件使用，它的不可替代的使用场景包括：

• 跨翻译单元共享全局变量：如果有一个全局的实例（比如全局配置、全局资源管理器）需要在多个翻译单元访问，必须在公共头文件里用extern声明这个变量，然后在唯一的一个.cpp里完成定义，否则每个引用头文件的翻译单元都会生成一个独立的变量实例，链接时会报重复定义错误。
• 实现C/C混编：如果你写的C代码要调用C实现的函数，或者要提供C语言可以调用的接口，必须用extern "C"来修饰对应函数的声明，关闭C++的名字修饰机制，否则链接时会因为符号名不匹配失败，这个是混编场景下的刚需。
• 极端场景下减少编译依赖：如果某个翻译单元只需要调用另一个模块的单个函数，没有其他依赖，直接加extern声明比引入一整个模块的头文件编译速度更快，不过这种属于极致编译优化的特殊场景，一般不推荐在生产代码里这么写，不利于后续维护。
• 临时调试场景：你临时需要调用另一个翻译单元的内部函数做测试，又不想修改公共头文件影响其他代码，可以临时加extern声明，调试完成后删掉即可，不用改动公共代码结构。

内容的提问来源于stack exchange，提问作者andreee