我会尝试回答你的问题，虽然这是一个老问题，而且看起来不是很重要（它确实不是很重要本身），并且得到了很好的答案已经。我想回答这个问题的原因是，当语言基于现有语言时，它与标准演变和语言设计的基本问题有关：什么时候应该以不兼容的方式弃用、删除或更改语言特性？ em>
在 C++ 中，可以在翻译单元中使用 static 关键字来影响符号（变量或函数声明）的可见性。
实际上是链接。
在 n3092 中，这已被弃用：
弃用表示：
-
意图在未来移除某些功能；这并不意味着不推荐使用的功能将在下一个标准版本中删除，或者它们必须“很快”删除，或者根本不删除。未弃用的功能可能会在下一个标准版本中删除。
- 正式尝试不鼓励使用它。
后一点很重要。虽然从来没有正式承诺你的程序不会被破坏，有时是默默地，按照下一个标准，委员会应该尽量避免破坏“合理”的代码。弃用应该告诉程序员依赖某些特性是不合理的。
它确实强调了，为了与 C 的兼容性（以及将 C 程序编译为 C++ 的能力），弃用是令人讨厌的。但是，将 C 程序直接编译为 C++ 可能已经是一种令人沮丧的体验，因此我不确定是否值得考虑。
保留 C/C++ 通用子集非常重要，尤其是对于头文件。当然，static 全局声明是带有内部链接的符号声明，这在头文件中不是很有用。
但问题不仅仅是与 C 的兼容性，而是与现有 C++ 的兼容性：有大量现有的有效 C++ 程序使用 static 全局声明。这段代码不仅在形式上合法，而且是合理的，因为它按照预期的使用方式使用了定义明确的语言特性。
仅仅因为现在有一种“更好的方式”（根据某些人的说法）来做某事并不会使以旧方式编写的程序“糟糕”或“不合理”。在 C 和 C++ 社区中都很好地理解在全局范围内声明对象和函数时使用 static 关键字的能力，并且最常正确使用。
以类似的方式，我不会仅仅因为“C 风格的转换很糟糕”而将 C 风格的转换为 double 更改为 static_cast<double>，因为 static_cast<double> 增加了零信息和零安全性。
每当发明一种新的做某事的方法时，所有程序员都会急于重写他们现有的定义良好的工作代码，这种想法简直太疯狂了。 如果你想删除所有继承的 C 丑陋和问题，你不改变 C++，你发明了一种新的编程语言。 一半删除 static 的使用几乎不会让 C++ 减少 C-ugly .
代码更改需要一个理由，“旧的就是坏的”绝不是代码更改的理由。
重大的语言更改需要非常充分的理由。让语言稍微简单一点绝不是做出重大改变的理由。
static 不好的原因非常薄弱，甚至不清楚为什么不同时弃用对象和函数声明 - 对它们进行不同的处理几乎不会使 C++ 更简单或更正交。
所以，真的，这是一个悲伤的故事。不是因为它产生的实际后果：它的实际后果完全为零。但因为这表明 ISO 委员会明显缺乏常识。