Windows下程序崩溃无法自重启，必须依赖外部守护：主程序用SetErrorMode(SEM_NOGPFAULTERRORBOX|SEM_FAILCRITICALERRORS)禁用错误框，由父进程调用CreateProcess启动并waitpid监听退出，崩溃后立即拉起新实例。
Windows下用CreateProcess + SetErrorMode实现崩溃后重启
程序崩溃时无法靠自身代码捕获，必须依赖操作系统层面的异常拦截。Windows提供SetErrorMode配合结构化异常处理（SEH），让进程在未处理异常（如访问空指针、除零）触发时，不弹错误框而是直接退出——这是自动重启的前提。
关键点在于：崩溃进程本身无法“重启自己”，必须由父进程或外部守护者拉起新实例。最轻量的做法是让主程序启动时先fork一个守护子进程，或反过来——主程序由一个极简的启动器（launcher.exe）调用。
-
SetErrorMode(SEM_NOGPFAULTERRORBOX | SEM_FAILCRITICALERRORS)必须在main开头尽早调用，否则系统仍会弹出“程序已停止工作”对话框，阻塞退出 - 不要依赖
std::set_terminate或signal(SIGSEGV, ...)——C++异常和POSIX信号对Windows SEH崩溃（如AV、stack overflow）基本无效 - 启动器需用
CreateProcess而非system()，后者无法可靠获取子进程退出状态，且shell环境不可控
Linux用fork + exec + waitpid监听子进程退出
Linux没有原生“崩溃重启”机制，但可通过父子进程模型实现等效效果：父进程（守护者）用fork()创建子进程运行主程序，再用waitpid()阻塞等待；一旦子进程因信号（SIGSEGV、SIGABRT等）终止，父进程立刻fork()+exec()拉起新实例。
注意waitpid()返回的status要检查WIFSIGNALED(status)和WTERMSIG(status)，避免把正常exit(0)误判为崩溃。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 父进程需忽略
SIGCHLD（或设置handler），否则可能收不到子进程终止通知 - 主程序二进制路径必须用绝对路径传给
exec族函数，相对路径在守护进程工作目录下很可能找不到 - 若主程序需要命令行参数，父进程需显式构造
argv数组并传递，不能只传argv[0]
跨平台方案慎用systemd或launchd
真正生产环境不推荐手写守护逻辑。Linux上用systemd的Restart=always和StartLimitIntervalSec更健壮；macOS用launchd配置KeepAlive和CrashRecovery。这些方案能处理OOM killer杀进程、权限问题、资源泄漏导致的多次崩溃抑制等边界情况。
手写重启逻辑容易陷入“崩溃→重启→再崩溃→无限fork”的雪崩，而systemd默认5次失败后暂停重启，并记录日志到journalctl -u your-service。
- systemd服务文件中
RestartSec=1控制重启间隔，避免瞬时循环；RestartPreventExitStatus=0可排除正常退出的干扰 - launchd的
AbandonProcess=true等价于Restart=always，但需注意其默认不重定向stdout/stderr，调试时务必配StandardOutPath - 不要在systemd服务里用
Type=forking——现代C++程序应设Type=simple并前台运行
重启前必须解决的核心问题
自动重启只是掩盖症状，不是修复缺陷。每次崩溃都意味着状态不一致、资源未释放或内存越界，盲目重启可能加剧问题：比如文件被重复写入、socket端口被占满、共享内存损坏。
真正该做的，是在重启前做最小化清理和诊断：
- 崩溃时用
backtrace()（Linux）或MiniDumpWriteDump()（Windows）生成堆栈快照，写入临时文件供后续分析 - 主程序启动时检查上次退出是否异常（例如通过锁文件+时间戳判断），若是则跳过自动加载用户配置，进入安全模式
- 避免在重启逻辑里做复杂操作——守护进程代码越简单越好，连日志都建议只写到
stderr或/dev/null，防止fprintf内部malloc失败二次崩溃
没人会因为程序能自动重启就忽略core dump，该看gdb还是得看。
