编译器警告应始终开启，Java 14+ switch表达式强制穷尽，Go/Rust枚举匹配默认检查，C/C++/JS需依赖工具；default须明确处理而非兜底，优先用enum/type收窄输入，case末尾须显式终止，嵌套中慎用default。
编译器警告能开就开，别信“我肯定不会漏”
Java 14+ 的 switch 表达式（带箭头语法）默认要求穷尽所有可能分支，没写 default 直接编译失败；但传统语句式 switch 仍不强制。Go 和 Rust 则在枚举匹配时默认检查穷尽性，漏掉会报错。C/C++/JavaScript 等语言完全不检查——这时候靠人盯不如靠工具。
实操建议：
- Java：启用
-Xlint:fallthrough和-Xlint:switch，部分 IDE（如 IntelliJ）还能配置 “Missing default in switch” 检查项并设为 warning 或 error - Go：用
go vet或staticcheck插件，对非枚举整型switch也能提示潜在遗漏 - CI 阶段加入
eslint-plugin-security（JS）或sonarqube规则，拦截 CWE-478 类缺陷
把 default 当成必填字段来设计，而不是“以防万一”
很多人写 default 是为了“兜底”，结果写成 log.Warn("should not happen") 就完事。这等于给漏洞盖了层薄纱——它不报错，但也不处理。
真正有效的 default 要分场景定行为：
- 处理外部输入（如 HTTP status 字符串、JSON 字段）→ 记录完整上下文 + 返回
400 Bad Request或抛IllegalArgumentException - 状态机内部流转（如订单状态
"created"/"shipped"）→throw new IllegalStateException("Unexpected state: " + state)，让问题在测试/预发暴露 - 未来可扩展的协议字段 → 在
default中调用handleUnknownField()并上报监控指标，而非静默忽略
用类型系统提前堵住“未知值”入口
很多 default 漏洞其实源于上游没做输入约束。比如 Java 里用 String 接口返回的状态码，而不是 enum Status；Go 里用 int 代替自定义 type Status int 并配 const 常量。
类型越早收窄，switch 分支就越可控：
- Java：用
enum替代字符串常量，配合values()+ 单元测试校验所有值是否被case覆盖 - Go：定义
type Status int+const (Pending Status = iota; Approved; Rejected)，再加一个IsValid() bool方法，在switch前先断言 - 即使语言不支持穷尽检查（如 JS），也该在函数入口用
assert(status in KNOWN_STATUSES)做运行时防护
default 放哪儿不重要，但执行路径必须唯一
有人以为 default 必须写在最后，其实它放在任何位置都行；但真正危险的是：某个 case 忘了 break，程序掉进 default，你以为是兜底，其实是穿透。
两个关键动作要固化成肌肉记忆：
- 所有
case块末尾，除非明确需要 fall-through（极少见），否则必须写break、return或throw -
default分支里禁止空实现，哪怕只写throw new UnsupportedOperationException()，也比留白强
最易被忽略的一点：当 switch 嵌套在循环或异常处理块中时，default 里的 continue 或 break outerLoop 容易引发控制流歧义——这种地方宁可用 if-else 重写，别硬撑 switch。
