c++标准库头文件不带.h后缀是语言规范，为保障命名空间隔离、c/c++兼容性及符号安全；iostream.h等旧式头文件与标准iostream内容不同、符号位于全局命名空间，混用会导致编译错误或odr冲突。
因为 C++ 标准明确要求标准库头文件不带 .h 后缀，这不是编译器“偷懒”，而是语言设计层面的规范——它直接关联命名空间、C/C++ 兼容性与符号隔离机制。
为什么 #include <iostream></iostream> 不能写成 #include <iostream.h></iostream.h>
iostream.h 是早期非标准 C++ 实现（如 Turbo C++、旧版 Borland）提供的头文件，所有符号（cin、cout 等）都暴露在全局命名空间；而标准 C++ 的 iostream 将全部内容封装在 std 命名空间中。两者是完全不同的文件，内容结构、符号可见性、甚至函数重载实现都可能不一致。
常见错误现象：
- 用
#include <iostream.h></iostream.h>编译通过，但换到 GCC/Clang/MSVC 就报error: 'cout' was not declared in this scope - 混用
<iostream.h></iostream.h>和<vector></vector>，导致命名空间混乱或 ODR（One Definition Rule）冲突
实操建议：
- 永远不要在新项目中使用
iostream.h、string.h（指 C++ 版）、fstream.h等带.h的旧式头文件 - 若遇到老代码含
.h头文件，第一反应不是“加using namespace std;”，而是直接替换为标准形式并补全命名空间限定
cstdio、cstring 这类带 c 前缀的头文件从哪来的
它们是 C 标准库头文件（stdio.h、string.h、math.h 等）在 C++ 中的“标准化映射”：去掉 .h，加上 c 前缀，并将所有符号导入 std 命名空间。
关键差异：
-
#include <stdio.h></stdio.h>→ 符号在全局命名空间（C 风格），C++ 中仍可使用，但不推荐 -
#include <cstdio></cstdio>→ 符号在std命名空间（如std::printf），符合 C++ 标准实践 -
string.h和<string></string>完全无关：string.h是 C 字符串函数（strcpy、strcmp），<string></string>是 C++ 的std::string类 —— 别因名字相似就误以为后者是前者的“升级版”
为什么自定义头文件还能用 .h 后缀
标准只约束“C++ 标准库头文件”的命名，不限制用户代码。你写 mylib.h 或 mylib.hpp 都可以，只要 #include "mylib.h" 路径正确、内容合法就行。
但要注意：
- 用双引号
" "包裹的是用户头文件，编译器优先在当前目录查找；用尖括号包裹的是系统/标准头文件，走编译器内置路径 - 如果你自己写了个
vector.h，又在项目里#include <vector></vector>，那实际包含的是标准库的vector，你的vector.h完全不会被加载 —— 名字撞了也不会自动覆盖 - 部分现代项目倾向用
.hpp区分“纯 C++ 头文件”，避免和 C 头文件混淆，但这属于风格约定，非强制
最容易被忽略的一点：头文件有没有 .h 后缀，本质不是“写法问题”，而是“你到底想用哪个 ABI 和符号模型”。标准库去后缀，是为了把命名空间、模板实例化、内联控制等 C++ 特性真正落地；一旦退回到 .h 形式，就等于主动放弃这些保障。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
