using声明只引入单个名字，不会污染作用域；using指令引入整个命名空间，风险高但省事；头文件中禁用任何using；c++17支持逗号分隔多个using声明。
using声明只引入单个名字，不会污染作用域
当你写 using std::cout;，编译器只把 cout 这一个标识符拉进当前作用域，其他如 std::cin、std::vector 依然需要加 std:: 前缀。这能避免意外覆盖或重名冲突。
常见错误现象：在头文件里写 using std::string;，被多个源文件包含后，可能导致不同模块对 string 的解析不一致——尤其当某个模块自己定义了同名类型时。
- 适用场景：函数内部频繁使用某几个标准库符号（比如
std::cout、std::endl），又不想每次打前缀 - 参数差异：不接受通配，必须显式写出完整限定名，例如
using A::fetch;，不能写成using A::f*; - 性能影响：无运行时开销，仅影响名称查找阶段；但若在全局作用域滥用，会延长 ADL（Argument-Dependent Lookup）的搜索路径
using指令引入整个命名空间，风险高但写法省事
using namespace std; 会让 std 中所有已声明的名字（截至该行位置）都进入当前作用域。注意是“已声明”，不是“已定义”——它只看到此前 #include 过的头文件里暴露出来的名字。
典型问题：两个库都定义了 Timer 类，你写了 using namespace libA; 和 using namespace libB;，再调用 Timer t; 就直接报错：ambiguous。
- 使用场景：小型 demo 或单文件测试代码，图快可以接受；大型项目中应完全避免出现在头文件或全局作用域
- 兼容性影响：C++20 起部分标准库实现开始延迟暴露某些名字（如
std::literals下的字符串字面量操作符），using namespace std;可能无法访问它们，除非显式 include 对应头 - 容易踩的坑：在
#include前写using namespace std;，会导致后续头文件中新增的std名字不可见
头文件里绝对不要用任何using声明或指令
头文件被包含的顺序不可控，一个 using namespace json11; 放在头里，可能让下游用户的所有 json 相关变量名突然冲突，而他们根本不知道源头在哪。
更隐蔽的问题是模板实例化：如果头文件里有 using std::swap;，又在模板中调用 swap(x, y)，ADL 可能选错重载版本，导致链接失败或行为异常。
- 正确做法：头文件中一律用完全限定名，比如
std::vector<int></int>、A::Config::load() - 例外情况：类内部的
using Base::func;是安全的，它只影响派生类作用域，且明确用于解决基类重载被隐藏的问题 - 构建系统验证：可以用
clang -E展开头文件，检查是否意外引入了未预期的名字
C++17起支持逗号分隔多个using声明
以前要引入三个符号得写三行：using std::cout;、using std::cin;、using std::endl;。C++17 允许合并为一行：using std::cout, std::cin, std::endl;。
这不是语法糖那么简单——它保证了这三个名字在同一时刻被注入作用域，避免中间插入其他声明导致查找顺序变化。不过仍不等价于 using namespace std;，因为没引入任何未列出的名字。
- 注意点：逗号分隔只适用于 using 声明，不适用于 using 指令；
using namespace A, B;是非法的 - 编译器兼容：GCC 7+、Clang 4+、MSVC 2017 15.3+ 支持；老项目升级前需确认工具链
- 可读性权衡：短列表（≤3个）适合合并，长列表反而降低扫描效率，不如保持多行清晰
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
