C++中何时适合创建仅头文件实现的类？

推荐全头文件实现的场景 #

• 模板类/依赖模板的实现（如CRTP）：C++标准要求模板实例化时编译器必须可见完整的方法实现，否则会触发链接阶段的未定义符号错误。这类场景没有替代方案，必须将所有实现放在.h头文件中。
• 轻量工具类/全inline实现的小型类：对于只有数个简单成员方法（如 getter/setter、短路径计算逻辑）的类，全头文件实现可以让编译器更方便地做inline优化，降低函数调用开销，同时省去维护对应.cpp文件的成本，整体开发效率更高。
• Header-only 库开发：面向第三方分发的轻量库采用全头文件实现时，用户无需额外处理库的编译、链接配置，直接引入头文件即可使用，天然跨平台，完全避免了不同编译器、不同编译参数下的静态/动态库兼容问题。
• 编译期计算类（包含constexpr/consteval方法）：C++要求编译期可执行的方法实现必须在编译时可见，全头文件实现才能支撑编译期求值的需求，放在.cpp文件中的实现无法参与编译期计算。

不适用全头文件实现的场景 #

• 大型业务类/实现代码量较大的类：全头文件实现会导致每一个引入该头文件的翻译单元都重复编译所有方法代码，大幅提升整体编译时长，同时头文件中混杂大量实现逻辑会降低接口可读性，提高维护成本。
• 有隐藏实现需求的场景：闭源商业库、需要对外屏蔽内部实现逻辑的模块如果采用全头文件实现，会直接暴露所有源码，无法保护知识产权，同时也会将内部依赖的第三方库、内部头文件暴露给调用方，增加调用方的依赖冲突风险。
• 对二进制兼容有要求的动态库开发：如果类实现放在头文件中，一旦修改实现逻辑，所有依赖该库的上层代码都必须全量重新编译，否则会触发未定义行为；而实现放在.cpp文件中的类只要对外接口不变，修改实现后仅需重新编译动态库本身，上层代码无需任何改动，二进制兼容性更好。
• 包含非inline静态成员的类：C17之前，非constexpr的静态成员变量必须在.cpp文件中做全局定义，放在头文件中会被多个翻译单元重复定义，触发链接阶段的符号重复错误；即便使用C17的inline静态变量，包含大量静态成员的类放头文件也会提升链接阶段的符号处理开销。
• 存在类间循环依赖的场景：如果两个类存在互相调用成员方法的依赖关系，全头文件实现很容易触发头文件循环引用问题，即便使用前置声明也无法解决实现层的依赖；将实现放在.cpp文件中，即可在.cpp文件中引入对应头文件，从根源上规避循环依赖问题。

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