ESP32(PlatformIO)下C++类对象指针注入与内部实例化问题

问题背景 #

原来的代码走依赖注入逻辑：先在main.cpp里实例化ACls对象aa，再把它的指针传给BCls的构造函数创建bb，运行完全正常。现在想修改BCls，让它支持无参构造——当没有传入ACls指针时，自行在内部实例化一个并赋值给_a。结果编译通过了，但一运行就触发TG1WDT_SYS_RESET看门狗复位。

为啥会崩？ #

ESP32上出现这种看门狗复位，大概率是两个原因：

• 栈溢出：ESP32的任务栈（尤其是主任务栈）默认空间有限（一般8KB左右），如果ACls是在BCls的栈内存中创建（比如作为成员对象而非动态分配），或者ACls构造过程占用大量栈资源，直接会把栈撑爆，触发看门狗。
• 初始化顺序错误：如果BCls是全局对象，或者在setup()之前就完成实例化，此时ESP32的硬件外设（比如SD卡依赖的SPI、GPIO）还未完成初始化，ACls（比如SdCls）的构造函数强行操作外设会引发异常，进而触发看门狗复位。

怎么修？ #

1. 改用堆内存存储内部实例 #

把_a改为指向堆内存的指针，无参构造时用new创建ACls实例，避免占用有限的栈空间：

class BCls {
private:
    Acls* _a;
    bool _ownAcls; // 标记是否为自行创建的实例，用于后续内存释放
public:
    // 带参构造：保留原有依赖注入逻辑
    BCls(Acls* a) : _a(a), _ownAcls(false) {}

    // 无参构造：自行创建ACls实例
    BCls() : _ownAcls(true) {
        // 注意：如果ACls构造依赖硬件，不要在这里创建，移到setup阶段！
        _a = new Acls();
    }

    // 析构函数：清理自行创建的实例
    ~BCls() {
        if (_ownAcls && _a != nullptr) {
            delete _a;
            _a = nullptr;
        }
    }

    // 禁用拷贝构造和赋值运算符，避免内存管理混乱
    BCls(const BCls&) = delete;
    BCls& operator=(const BCls&) = delete;
};

2. 延迟初始化，不在构造中硬执行 #

如果ACls的初始化依赖硬件外设，不要在BCls的构造函数里创建实例，而是放到setup()或者第一次使用时再初始化：

class BCls {
private:
    Acls* _a;
    bool _ownAcls;
public:
    // 带默认参数，兼容两种构造方式
    BCls(Acls* a = nullptr) : _a(a), _ownAcls(false) {}

    // 单独的初始化函数，在setup()中调用
    void begin() {
        if (_a == nullptr) {
            _ownAcls = true;
            _a = new Acls();
            // 若ACls自身有初始化函数（比如begin()），此时再调用
            _a->begin();
        }
    }

    ~BCls() {
        if (_ownAcls && _a != nullptr) {
            delete _a;
            _a = nullptr;
        }
    }
};

对应的main.cpp调用方式：

BCls bb; // 先无参构造，暂不创建ACls
void setup() {
    // 先完成ESP32外设（如SPI、GPIO）的初始化
    // ...
    bb.begin(); // 此时再创建并初始化ACls
}

3. 检查ACls的构造逻辑 #

确认ACls的构造函数中没有长时间阻塞的操作——ESP32的看门狗会监控任务响应，若构造时等待外设响应的时间超过看门狗超时阈值，也会触发复位。这种情况要把耗时操作移到单独的初始化函数中，不要放在构造里。

4. 临时增大栈空间（不推荐长期使用） #

如果确认是栈溢出导致，可以在platformio.ini中调大主任务栈空间：

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
build_flags = 
    -DCONFIG_MAIN_TASK_STACK_SIZE=16384 ; 将主任务栈调整为16KB

这只是临时救急方案，优先从代码结构上优化，不要依赖大栈空间。

排查问题的小技巧 #

• 开启栈溢出检测：在platformio.ini中添加build_flags = -DCONFIG_STACK_OVERFLOW_CHECK=y，编译运行后会输出栈溢出的具体信息，帮助定位问题。
• 打印剩余内存：在关键位置调用xPortGetFreeHeapSize()（剩余堆内存）和uxTaskGetStackHighWaterMark(NULL)（栈剩余峰值），确认是否因内存不足导致崩溃。

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