enum class + switch 是最轻量可控的状态机实现，核心是用枚举抽象离散互斥状态，循环中显式分支处理并更新状态，需覆盖所有枚举值、防 fall-through、封装复杂逻辑为函数。
用 enum 定义状态，switch 驱动流转
最轻量、最可控的状态机实现方式就是靠 enum + switch。核心是把每个状态抽象成一个命名常量，再在循环中根据当前状态做分支处理，并显式更新状态变量。
关键点在于：状态必须是离散、互斥、可穷举的；每次处理完一个状态后，必须明确赋值给下一个状态（哪怕维持原状），不能依赖隐式跳转。
-
enum class比裸enum更安全，避免命名污染和隐式转换 - 状态变量类型必须与
enum严格一致，比如State current = State::IDLE; -
switch必须覆盖所有枚举值，或加default:处理未定义状态（建议抛异常或断言）
enum class State { IDLE, RUNNING, PAUSED, STOPPED };
State current = State::IDLE;
while (running) {
switch (current) {
case State::IDLE:
if (start_requested()) current = State::RUNNING;
break;
case State::RUNNING:
do_work();
if (pause_requested()) current = State::PAUSED;
else if (stop_requested()) current = State::STOPPED;
break;
case State::PAUSED:
if (resume_requested()) current = State::RUNNING;
break;
case State::STOPPED:
reset_resources();
current = State::IDLE;
break;
default:
throw std::runtime_error("invalid state: " + std::to_string(static_cast<int>(current)));
}
}
避免 switch 中遗漏 break 导致状态“穿透”
这是实际编码中最常踩的坑：少写一个 break，程序会顺序执行后续 case 分支，造成状态逻辑错乱——比如本该停在 PAUSED，却意外触发了 STOPPED 的清理逻辑。
编译器不一定报错，尤其当多个 case 共享逻辑时，容易误以为是故意“fall-through”。C++17 起可用 [[fallthrough]] 显式标注，但绝大多数状态流转场景都不该穿透。
立即学习“C++免费学习笔记（深入）”；
- 每个
case块末尾都应有break、return或显式状态变更 - 启用编译器警告：
-Wimplicit-fallthrough（GCC/Clang）能捕获潜在穿透 - 用
enum class+switch时，default:不仅防崩溃，还能暴露漏处理的状态
状态迁移逻辑别全塞进 switch，提取成独立函数
当某个状态的处理逻辑变长（比如要校验输入、调用多个子系统、涉及异步等待），硬塞在 case 里会让主循环臃肿难读，也破坏单一职责。
更合理的做法是把每个状态的“进入动作”“持续行为”“退出条件”封装成小函数，switch 只负责分发和状态跃迁。
- 函数命名体现意图，例如
on_enter_running()、update_paused()、should_transition_to_stopped() - 状态变更仍由主循环控制，不放在子函数内部（避免隐藏控制流）
- 若需跨状态共享数据，用结构体或类成员承载，而非全局变量
struct Machine {
State state = State::IDLE;
int progress = 0;
void step() {
switch (state) {
case State::IDLE: on_idle(); break;
case State::RUNNING: on_running(); break;
case State::PAUSED: on_paused(); break;
case State::STOPPED: on_stopped(); break;
}
}
private:
void on_running() {
progress++;
if (progress >= 100) state = State::STOPPED;
}
void on_stopped() {
progress = 0;
state = State::IDLE;
}
};
什么时候不该用 enum+switch？
这种写法适合状态数少（
- 状态之间存在复杂依赖或条件组合（比如 “只有在 A 且非 B 时才能从 X 到 Y”）→ 需要状态迁移表或策略模式
- 需要记录历史状态、支持回退或撤销 → 手动维护状态栈成本高，更适合用状态模式 + 虚函数
- 状态数动态变化，或由配置驱动 →
enum编译期固定，此时用字符串映射或整数 ID + 查表更灵活 - 多个对象共用同一组状态逻辑 → 重复写
switch易出错，应抽取为模板或基类
真正难的不是写对一个 switch，而是想清楚哪些状态必须显式建模、哪些边界条件必须拦截、哪些迁移应该禁止——这些设计决策不会被语法检查捕获，得靠反复推演和测试覆盖。
