我来分享一套用函数指针实现FSM的优化方案，既满足你的要求，又兼顾可读性、可扩展性和嵌入式场景的实用性。先聊聊核心优化思路，再上可编译的完整代码，最后拆解优化要点：

核心优化思路 #

• 状态与行为强绑定：用函数指针直接关联状态枚举和对应的状态处理函数，彻底替代冗余的if/else分支，代码更整洁易维护
• 状态切换统一管控：通过SetState API封装状态切换的所有公共逻辑（合法性检查、状态变更提示），避免重复代码
• 输入逻辑解耦：把模拟输入（原代码的scanf）单独封装，后续替换成CAN消息解析或全局变量读取时，完全不影响状态机核心逻辑
• 扩展性友好：新增状态时只需添加枚举值、实现状态函数、更新状态表三步，无需改动核心执行逻辑

可编译完整代码 #

#include <stdio.h>
#include <stdlib.h>

// 状态枚举定义
typedef enum {
    STATE_IDLE,
    STATE_DRIVING,
    STATE_PARKING,
    STATE_ERROR,
    STATE_MAX // 用于边界检查，避免非法状态
} DriveModeEnum;

// 前向声明状态处理函数：每个函数返回下一个要切换的状态
DriveModeEnum IdleStateHandler(void);
DriveModeEnum DrivingStateHandler(void);
DriveModeEnum ParkingStateHandler(void);
DriveModeEnum ErrorStateHandler(void);

// 状态表：将状态枚举、状态名称、处理函数三者绑定
typedef struct {
    DriveModeEnum state;
    const char* stateName;
    DriveModeEnum (*handler)(void);
} StateTable;

// 初始化状态表
StateTable stateTable[] = {
    {STATE_IDLE, "idle", IdleStateHandler},
    {STATE_DRIVING, "driving", DrivingStateHandler},
    {STATE_PARKING, "parking", ParkingStateHandler},
    {STATE_ERROR, "error", ErrorStateHandler}
};

// 当前状态：封装为静态变量，仅通过接口访问（符合嵌入式系统封装原则）
static DriveModeEnum currentState = STATE_IDLE;

// 模拟输入获取模块：替代原scanf，后续可直接替换为CAN消息/全局变量读取
static DriveModeEnum GetInputCommand(void) {
    int input;
    printf("\nEnter command (0:Idle, 1:Drive, 2:Parking, 3:Error): ");
    scanf("%d", &input);
    
    // 输入合法性检查，非法输入返回当前状态，避免无效切换
    if (input >= 0 && input < STATE_MAX) {
        return (DriveModeEnum)input;
    } else {
        printf("Invalid command, keeping current state\n");
        return currentState;
    }
}

// 状态切换API：统一处理状态切换逻辑
void SetState(DriveModeEnum newState) {
    // 先检查状态合法性
    if (newState >= STATE_MAX || newState < 0) {
        printf("Invalid state request, ignoring\n");
        return;
    }
    
    // 仅当状态实际变化时执行切换和提示
    if (newState != currentState) {
        currentState = newState;
        printf("Current State is %s\n", stateTable[currentState].stateName);
    }
}

// -------------------------- 各状态处理函数实现 --------------------------
DriveModeEnum IdleStateHandler(void) {
    // 这里可以添加Idle状态的业务逻辑，比如检测钥匙插入、电源初始化等
    printf("In Idle state: Waiting for driver command...\n");
    return GetInputCommand();
}

DriveModeEnum DrivingStateHandler(void) {
    // 这里可以添加Driving状态的业务逻辑，比如读取车速、处理油门/刹车信号等
    printf("In Driving state: Monitoring vehicle dynamics...\n");
    return GetInputCommand();
}

DriveModeEnum ParkingStateHandler(void) {
    // 这里可以添加Parking状态的业务逻辑，比如检测手刹状态、锁止车轮等
    printf("In Parking state: Vehicle secured and stationary...\n");
    return GetInputCommand();
}

DriveModeEnum ErrorStateHandler(void) {
    // 这里可以添加Error状态的业务逻辑，比如读取故障码、触发声光告警等
    printf("In Error state: Fault detected, please inspect system...\n");
    return GetInputCommand();
}

// 主循环：状态机核心执行逻辑
int main(void) {
    printf("FSM Demo Initialized\n");
    
    while (1) {
        // 1. 获取当前状态对应的处理函数，执行后得到下一个状态
        DriveModeEnum nextState = stateTable[currentState].handler();
        // 2. 调用统一API切换状态
        SetState(nextState);
    }
    
    return EXIT_SUCCESS;
}

关键优化点拆解 #

1. 状态表的价值：把状态相关的所有信息（枚举、名称、处理函数）集中管理，彻底消除了传统FSM中大量的if/else判断，新增状态时只需要在状态表中添加一行，维护成本极低。
2. SetState的封装：所有状态切换必须通过这个API，保证了合法性检查、状态变更提示等逻辑的一致性，后续如果需要添加日志、状态切换钩子（比如状态切换前的资源释放），只需修改这一个函数。
3. 输入逻辑分离：GetInputCommand单独负责输入的获取和校验，原代码中的scanf被封装在这里，后续如果要适配真实嵌入式场景的CAN消息或全局变量，只需要替换这个函数的实现，完全不影响状态机的核心逻辑。
4. 安全性设计：对输入值和状态切换请求都做了边界检查，避免非法状态导致系统崩溃，符合嵌入式系统的稳定性要求。
5. 单一职责原则：每个状态处理函数只负责自身状态的业务逻辑，并返回下一个状态，逻辑清晰，调试和扩展都很方便。

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