15、模块化编程中的配置管理：配置文件解析、编译时配置与运行时配置、条件编译 #ifdef 的使用

配置管理这事儿，说大不大，说小不小。我早年做项目时，就吃过配置混乱的亏——同一个代码，在不同板子上跑，行为不一样，查了半天发现是宏定义没统一。从那以后，我对配置管理就特别上心。

今天咱们聊聊模块化编程里的配置管理。说白了，就是怎么让你的代码灵活适应不同场景，又不会搞得一团糟。

15.1 配置管理的三种层次

我个人习惯把配置分成三个层次：编译时配置、运行时配置、配置文件解析。它们各有各的适用场景，咱们一个一个说。

15.1.1 编译时配置

编译时配置，就是用 #define 和 #ifdef 在编译阶段决定代码行为。这种方式效率最高，因为配置在编译时就固定了，运行时没有任何额外开销。

我举个例子。你写一个串口驱动，可能支持多种波特率：

// config.h
#define UART_BAUDRATE_115200
// #define UART_BAUDRATE_9600

// uart.c
#ifdef UART_BAUDRATE_115200
  #define UART_BAUD_REG 0x1A
#elif defined(UART_BAUDRATE_9600)
  #define UART_BAUD_REG 0x34
#else
  #error "Please define a baudrate!"
#endif

你看，这里只编译一份代码，但实际生成的机器码只包含你选的那个分支。没有 if-else 判断，没有运行时开销。这就是编译时配置的优势。

15.1.2 运行时配置

运行时配置，就是程序跑起来之后，通过变量或参数来改变行为。比如你写一个传感器驱动，采样频率可能需要在运行时动态调整：

// sensor.h
typedef struct {
    uint32_t sample_rate_hz;
    uint8_t  gain;
    bool     enable_filter;
} sensor_config_t;

// sensor.c
static sensor_config_t g_config = {
    .sample_rate_hz = 100,
    .gain           = 1,
    .enable_filter  = true
};

void sensor_set_sample_rate(uint32_t hz) {
    if (hz > 1000) {
        // 我曾经遇到过有人把采样率设到 10kHz，结果 CPU 直接跑满
        // 所以这里加了个上限保护
        hz = 1000;
    }
    g_config.sample_rate_hz = hz;
}

运行时配置的好处是灵活，不用重新编译。但代价是多了变量存储和判断开销。在资源紧张的 MCU 上，你得权衡一下。

15.1.3 配置文件解析

配置文件解析，就是从外部文件（比如 .ini、.json、.cfg）读取配置。这种方式最灵活，但实现起来也最复杂。

我见过一个项目，把配置写在 SD 卡的一个文本文件里。产品出厂后，现场工程师改个参数，插卡重启就行，不用动固件。嗯，这就是配置文件解析的价值。

一个简单的键值对解析器大概长这样：

// parser.c
bool config_parse_line(const char* line, char* key, char* value) {
    // 跳过空行和注释
    if (line[0] == '#' || line[0] == '\0') {
        return false;
    }
    
    // 查找 '=' 分隔符
    const char* eq = strchr(line, '=');
    if (!eq) {
        return false;  // 格式错误
    }
    
    // 提取 key 和 value
    size_t key_len = eq - line;
    strncpy(key, line, key_len);
    key[key_len] = '\0';
    strcpy(value, eq + 1);
    
    // 去掉首尾空格（代码略）
    return true;
}

15.2 条件编译 #ifdef 的正确用法

#ifdef 是个好东西，但用不好就是灾难。我见过一个项目，一个 .c 文件里嵌套了七八层 #ifdef，读起来跟迷宫一样。

咱们说说几个原则。

15.2.1 用 #ifdef 做平台适配

这是最常见的用法。同一份代码，跑在不同芯片上：

// hal_timer.c
#ifdef STM32F4
  #include "stm32f4xx_hal.h"
  void timer_init(void) {
      // STM32 的定时器初始化
  }
#elif defined(ESP32)
  #include "esp_timer.h"
  void timer_init(void) {
      // ESP32 的定时器初始化
  }
#else
  #error "Unsupported platform!"
#endif

你看，这里用 #ifdef 把平台相关的代码隔离开。每个平台只编译自己的那部分，互不干扰。

15.2.2 用 #ifdef 做功能开关

有时候，某些功能只在调试阶段需要，或者只在特定硬件版本上需要：

// debug.c
void debug_log(const char* msg) {
#ifdef DEBUG_ENABLE
    // 调试日志输出
    uart_send_string(msg);
#else
    // 空函数，编译器会优化掉
    (void)msg;
#endif
}

嗯，这里要注意：#ifdef 和 #if 是有区别的。#ifdef 只检查宏是否被定义，而 #if 可以检查宏的值。我个人习惯用 #if，因为可以更精确控制：

#define DEBUG_LEVEL 2

#if DEBUG_LEVEL >= 1
  // 基本调试信息
#endif

#if DEBUG_LEVEL >= 2
  // 详细调试信息
#endif

15.2.3 避免滥用 #ifdef

我见过最糟糕的代码，一个函数里到处是 #ifdef，导致代码逻辑支离破碎。你想想看，读代码的人要在脑子里同时维护多个版本，多累啊。

我的建议是：

• 能用函数指针替代的，就别用 #ifdef
• 能用单独文件替代的，就别在同一个文件里堆 #ifdef
• 如果实在要用，尽量把 #ifdef 控制在函数级别，别在函数内部到处插

15.3 三种配置方式的对比

配置方式	灵活性	运行时开销	适用场景
编译时配置	低（需重新编译）	无	硬件参数、平台选择、功能开关
运行时配置	中（重启生效）	少量内存+判断	用户可调参数、运行模式切换
配置文件解析	高（热插拔）	较大（解析开销）	产品参数、现场调试、多环境适配

15.4 一个完整的配置管理示例

咱们把三种方式结合起来，做一个温度传感器的配置管理：

// config.h —— 编译时配置
#define SENSOR_TYPE_DS18B20
// #define SENSOR_TYPE_NTC

#define MAX_SAMPLE_RATE_HZ  100
#define DEFAULT_SAMPLE_RATE 10

// sensor_config.c —— 运行时配置
static struct {
    uint32_t sample_rate;
    bool     enable_alarm;
} s_runtime_cfg = {
    .sample_rate   = DEFAULT_SAMPLE_RATE,
    .enable_alarm  = true
};

void sensor_config_set_rate(uint32_t hz) {
    if (hz > MAX_SAMPLE_RATE_HZ) {
        hz = MAX_SAMPLE_RATE_HZ;
    }
    s_runtime_cfg.sample_rate = hz;
}

// sensor_config_parser.c —— 配置文件解析
bool sensor_config_load(const char* filename) {
    // 打开文件，逐行解析
    // 找到 "sample_rate=50" 就调用 sensor_config_set_rate(50)
    // 找到 "enable_alarm=false" 就设置 s_runtime_cfg.enable_alarm = false
    return true;
}

你看，编译时配置决定了用哪种传感器，运行时配置决定了采样率，配置文件解析则允许外部修改参数。三层配合，既灵活又高效。

15.5 本章知识体系

下面这张图，帮你理清配置管理的整体脉络：

嗯，配置管理这块，说白了就是「把变化隔离好」。编译时配置管死的东西（硬件、平台），运行时配置管活的东西（参数、模式），配置文件管外部的东西（现场、用户）。三者各司其职，代码自然清爽。

---