老式 enum 会污染命名空间，因其枚举值直接注入外层作用域，导致命名冲突、隐式转换、无法前向声明及底层类型不可控；enum class 通过作用域隔离、显式类型和底层类型指定解决这些问题。
为什么老式 enum 会污染命名空间
老式 enum 的枚举值直接注入到外层作用域，比如定义了 enum Color { Red, Green, Blue };，那 Red 就和函数名、变量名同级——同一作用域里再写 int Red = 10; 就冲突。更隐蔽的是，不同 enum 之间还可能重名覆盖：enum Status { Success, Failed }; 和 enum Result { Success, Error }; 一并引入就编译不过。
常见错误现象：error: reference to 'Success' is ambiguous，或者调用函数时传入 Red 却意外匹配到另一个 enum 的同名值。
- 所有枚举值默认是
int类型，无法指定底层类型（C++11 前） - 不能前向声明（forward declare），头文件依赖容易变重
- 隐式转换到整数：
if (c == 0)能通过，但语义模糊，且易被误用
用 enum class 替代传统 enum 的实操要点
enum class 是 C++11 引入的强类型枚举，它把枚举值锁在作用域内，也切断了隐式整数转换。这是目前最稳妥的写法。
使用场景：新项目、重构旧 enum、需要明确类型安全或跨模块复用的枚举。
立即学习“C++免费学习笔记（深入）”；
- 必须用作用域解析符访问值：
Color::Red，不能再直接写Red - 可显式指定底层类型：
enum class FileMode : uint8_t { Read, Write, Append };，控制内存占用和序列化行为 - 支持前向声明：
enum class ErrorCode; // 可以放在头文件开头，减少 include 依赖 - 不支持隐式转 int，要比较数值需显式转换：
static_cast<int>(FileMode::Write)</int>
示例：
enum class HttpStatus : uint16_t {
Ok = 200,
NotFound = 404,
ServerError = 500
};
<p>void handle(HttpStatus code) {
if (code == HttpStatus::Ok) { /<em> ... </em>/ } // ✅ 正确
// if (code == 200) { /<em> ... </em>/ } // ❌ 编译失败，类型不匹配
}什么时候还得用传统 enum（以及怎么兜底）
不是所有地方都能无脑换 enum class。C 风格 API、某些模板元编程、或需要和 C 头文件交互时，传统 enum 仍有存在必要。
容易踩的坑：混用两种风格导致类型不兼容，比如函数参数是 enum Status，却传入 StatusClass::Success。
- 若必须导出给 C 使用，只能用传统
enum，且确保底层类型与 C 端一致（如加typedef enum { ... } Status;） - 宏定义枚举值（如
#define STATUS_OK 0）仍常见于嵌入式或驱动层，此时enum class无法替代 - 模板推导中，传统 enum 值可能被当作非类型模板参数（
template<int n> struct X {};</int>），而enum class需要显式提供类型
兼容性与跨标准注意事项
C++11 是 enum class 的起点，但不同编译器对底层类型和前向声明的支持略有差异。GCC 4.6+、Clang 3.1+、MSVC 2012+ 基本都支持完整特性。
性能影响几乎为零：enum class 在运行时和传统 enum 完全等价，只是编译期多了类型检查。
- 不要用
enum struct—— 它和enum class行为一致，但可读性差，容易让人误以为是结构体 - 避免给
enum class加using namespace导出值，比如using namespace Color;，这等于主动破坏作用域隔离 - 如果枚举值需要作为字符串打印，别手写一堆
if (x == Color::Red) return "Red"，考虑用宏或反射库生成，否则维护成本高
真正麻烦的从来不是语法选择，而是团队里有人坚持用老式 enum 写新代码，又没配 clang-tidy 或 cpplint 拦截 —— 这种混合状态比纯老式更难 debug。
