case顺序不影响匹配结果但影响执行路径，尤其在缺少break时会导致fall-through；default位置决定其在fall-through链中的实际执行时机。
不会影响匹配结果，但会影响执行路径——尤其当缺少 break 时。
case 顺序不影响“哪个 case 被选中”
匹配阶段只做一件事：把 switch 表达式的值，从上到下依次和每个 case 后的常量比较，找到第一个相等的就进入。这个“第一个”由书写顺序决定，但只要所有 case 值互不重复，且每个分支末尾都有 break，那么无论怎么调换顺序，输入相同值总进同一个分支、执行同一段代码。
常见错误现象：有人误以为“case 1 写在后面就优先级低”，其实不是优先级问题，是匹配流程本身是线性扫描。
case 顺序影响 fall-through 执行流
一旦某个 case 没写 break，控制流会穿透（fall-through）到下一个 case 的语句，不管那个 case 的值是否匹配。这时顺序就直接决定执行范围。
- 原始顺序：
case 1:→case 2:→case 3:，若case 1缺break，输入 1 会执行全部三段 - 调换后：
case 2:→case 1:→case 3:，同样缺break，输入 1 就只执行case 1和case 3，跳过了case 2
这种行为在状态机合并、枚举范围分组（如 case 'a': case 'b': case 'c':）时是有意为之，但顺序一乱，逻辑就错。
default 的位置也受顺序影响
default 不是“兜底入口”，而是“没匹配到任何 case 时的入口标号”。它在代码中的物理位置决定了 fall-through 路径：
- 如果
default写在中间且没break，比如case 2:→default:→case 3:，那输入 2 会执行case 2后一路落到case 3 - 即使
default在最后，只要前面某个case缺break，也会穿过去执行它
所以不要依赖“default 总在最后才执行”，要看它在源码里排第几、前后有没有 break。
编译器优化可能隐式依赖顺序
现代编译器（如 GCC、Clang）对密集整数 case 可能生成跳转表（jump table），此时顺序不影响性能；但对稀疏或带大间隔的值（如 case 1:, case 1000:, case 999999:），可能退化为二分查找或链式比较——这时顺序虽不改逻辑，但会影响实际比较次数。不过这种细节一般无需手动调序优化，除非 profiling 明确指出是热点。
真正容易被忽略的是：case 值必须是编译期常量，且不能重复；顺序本身不是语法要求，但它是 fall-through 行为的执行骨架——写的时候不觉得，出 bug 时才发现，原来那几行漏掉的 break 和上下文顺序绑死了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
