这问题问得很接地气！我在32位MCU的嵌入式开发里经常碰到这种写法，咱们从逻辑、代码简洁性和编译器优化三个维度拆解下：

核心逻辑匹配优势 #

你贴的这段BLE广播模式选择代码，逻辑本质是按优先级从高到低检查模式启用条件，命中第一个符合条件的模式就立即返回结果，用return刚好完美贴合这个需求：

• 避免冗余的break：不需要在每个满足条件的分支末尾写break，减少了重复代码，也避免了不小心漏写break导致的意外fallthrough（当然你的代码里是故意fallthrough，这种情况下return反而让“不满足就继续往下检查”的逻辑更直观）。
• 逻辑一目了然：每个return直接告诉读者“这个条件满足，函数就返回这个结果，不用再往下走了”，比先赋值给变量再break最后统一return的写法，意图更直接。

嵌入式MCU下的代码生成优势 #

针对32位MCU的编译器（比如ARMCC、GCC），这种写法确实能生成更精简、更快的代码：

• 减少跳转指令：return会直接生成跳转到函数返回入口的指令，而break需要先跳转到switch结构的结束位置，再继续执行后续代码（如果有的话）。在你的代码里，switch之后就是函数结束，所以return省去了额外的跳转步骤，减少了指令数，节省了Flash空间也提升了执行速度。
• 更优的编译优化：编译器看到return后，会知道当前函数的执行路径在此终止，因此可以跳过对后续变量的保存、无用代码路径的处理等操作，进一步压缩代码体积。

对比用Break的写法 #

举个例子，要是换成break的写法，你得多做这些额外操作：

uint8_t selected_mode = BLE_ADV_MODE_IDLE;
switch (adv_mode) {
case BLE_ADV_MODE_DIRECTED_HIGH_DUTY:
    if ((p_advertising->adv_modes_config.ble_adv_directed_high_duty_enabled) && 
        (!p_advertising->adv_modes_config.ble_adv_extended_enabled) && 
        (peer_addr_is_valid)) {
        selected_mode = BLE_ADV_MODE_DIRECTED_HIGH_DUTY;
        break;
    }
    // Fallthrough.
// ...其他case分支类似
}
return selected_mode;

相比你的原代码，多了变量定义、赋值操作，编译器还要处理变量的存储和读取，不仅代码更啰嗦，还会增加一点点运行开销。

注意事项 #

当然这种写法不是万能的：

• 只适合switch之后没有其他函数逻辑的场景，如果switch结束后还要执行清理、资源释放等操作，就必须用break。
• 团队协作时，最好像你代码里那样加// Fallthrough.注释，让其他开发者明确知道这里是故意不中断，继续往下检查。

内容的提问来源于stack exchange，提问作者jackly