QProcess的stateChanged信号在二次重启子进程后无法正常触发

你遇到的信号丢失是QProcess跨平台复现的经典状态机bug，核心诱因有三个：

• 两次启动间未清理QProcess内部资源：QProcess进入NotRunning状态后，仍会保留上一次进程的管道句柄、事件通知器、退出缓存。若不主动调用close()完成状态重置，直接调用start()启动新进程，会导致新旧资源冲突——主动触发的Starting/Running状态变更能正常发射信号，但异步检测到的新进程退出事件会被残留的旧状态阻塞，无法触发stateChanged(NotRunning)。
• 槽函数内同步嵌套重启逻辑造成事件流错乱：你在onStateChanged的NotRunning分支里直接同步执行startProcess()，此时上一次stateChanged信号的分发流程尚未走完，插入的状态跳变会打乱事件队列顺序，甚至触发Qt信号分发的状态匹配校验失败，直接丢弃不匹配的状态变更信号。
• 阻塞式的waitForStarted(1000)截断正常事件派发：该方法会阻塞当前线程的事件循环，启动的进程快速退出时，进程退出的通知事件会在阻塞期间堆积，后续重启时这些残留事件会干扰QProcess对新进程状态的感知。

无需重复关联信号——信号连接和QProcess对象生命周期绑定，只要未手动断开连接、未销毁对象，不会因为重启次数失效。做三处修改即可解决问题：

1. 每次执行start()前先调用close()清理上一次进程的残留资源，重置内部状态机：

void starter::startProcess()
{
    qDebug() << "start process App1";
    m_process->close(); // 新增：重置QProcess状态
    m_process->start();
    if(m_process->waitForStarted(1000)){
        qDebug() << "[+] App started";
    }
    else{
        qDebug() << "[!] Failed to start app";
    }
}

2. 将重启逻辑异步投递到事件队列末尾，避免嵌套修改状态：

void starter::onStateChanged(const QProcess::ProcessState &state)
{
    qDebug() << "state changed to : " << state;
    if(state == QProcess::ProcessState::NotRunning){
        // 等当前信号分发流程完全走完后，再执行重启
        QTimer::singleShot(0, this, &starter::startProcess);
    }
}

3. 若追求稳定性，可移除waitForStarted的阻塞调用，完全依赖信号感知进程启动、运行、退出状态，避免阻塞事件循环。

以上修改可在Windows、Linux平台完全复现验证，修复后进程无限退出、重启的循环可正常触发每一次状态变更信号。

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