一些想法：
一种可能的合法用途是创建具有外部链接的元件，或者希望在不污染外部名称空间的情况下使用功能。 (但是，这似乎是iffy，因为头文件可以使用模糊的前缀名称，如mylib123__foobar和#define foobar mylib123__foobar。)
有些功能只能通过头文件提供，不需要用户链接库/对象文件。 可见，这是提供“库”的真正动机，该库几乎只提供数据结构和琐碎的代码来处理它们。 实际上，与库相比，如果数据结构不透明，意味着直接从APP应用程序访问，则将一起使用的功能放在同一个头文件中可以大大降低更改/修改数据时的破坏风险结构。
这个函数可能只是外部函数的包装器。 包装器的行为可能取决于对编译单元中编译时选项的调用。 例如：
静态反馈(intx ) )。
{
return real _ foobar (compile time _ parameter，x )；
}
你可能会说你只是使用宏，如果foobar需要用函数指针调用期望的用途呢？
有了这个…
事实上，在头文件中放置静态功能的主要原因通常是基于10多年前的概念，即通过允许编译器的内联函数或某些内容来提高性能。 大多数人没有做任何测量。 由于现代编译器可以将整个程序作为一个单元进行编译，如果有问题，理论上这将导致更多的优化可能性。 另外，这是有问题的优化的开始，所以我真的怀疑把标题放在性能上。
这个批评特别适用于头文件中OP的“大”静态函数的示例。 除非常量参数值允许编译器删除代码或某些内容的90%，否则内联很少能受益。 (有关这种极端情况的现实世界示例，请参见libavcodec中使用的疯狂内联函数/宏定义：-。)