最可靠重启方式是手动启动新进程再退出旧进程：用Process.Start传入当前程序完整路径，加Thread.Sleep(100)，用Environment.Exit(0)退出，并正确传递参数、工作目录及使用Mutex防多开。
用 Process.Start 启动新实例再退出旧进程最可靠
直接调用 application.restart() 看似方便，但它只在 winforms 应用中有效，且依赖于应用程序消息循环——控制台、wpf 或后台服务里会抛出 notsupportedexception。真正跨场景通用的做法是手动启动新进程，再主动退出当前进程。
实操建议：
- 用
Process.Start传入当前程序的完整路径（Process.GetCurrentProcess().MainModule.FileName），避免只传名字导致找不到 exe - 退出前加
Thread.Sleep(100)防止新进程还没起来旧进程就释放了句柄（尤其在快速重启或资源紧张时） - 退出必须用
Environment.Exit(0)，不用Application.Exit()（WPF/Console 下无效）或Process.GetCurrentProcess().Kill()（不触发AppDomain.Unloading等清理逻辑）
注意命令行参数和工作目录的继承
如果原进程是带参数启动的（比如 MyApp.exe --mode=server --config=path.json），新进程默认不会自动继承这些参数，直接重启后配置就丢了。
实操建议：
- 用
Environment.GetCommandLineArgs()获取全部参数（第一个是 exe 路径，要跳过） - 拼接时用
string.Join(" ", args.Skip(1).Select(a => a.Contains(" ") ? $"\"{a}\"" : a))处理含空格的参数 - 显式设置
startInfo.WorkingDirectory = Environment.CurrentDirectory，否则新进程可能在系统临时目录下启动，读不到相对路径配置文件
Windows 下防多开需配合互斥体（Mutex）检查
自动重启时若没做去重，容易出现两个实例同时运行——尤其是用户双击图标或脚本重复触发时。单纯靠判断进程名不可靠（同名进程太多）。
实操建议：
- 在 Main 入口开头创建命名
Mutex，如new Mutex(true, "MyApp_Restart_Singleton_2024") - 重启前用
Mutex.TryOpenExisting检查是否已有同名实例在跑，有则直接退出旧进程，不启动新实例 - 不要把 Mutex 创建放在重启逻辑之后——否则旧进程退出前新进程已拿到锁，导致“重启失败”假象
调试时别让重启掩盖异常
开发阶段频繁重启容易掩盖真实崩溃点：比如某次异常后触发重启，你以为程序“恢复了”，其实只是错误被跳过了。
实操建议：
- 只在明确需要重启的业务逻辑里调用（如配置热重载、模块更新完成），不要包裹在全局异常处理器里
- 记录重启原因到日志，例如写入
EventLog或本地文件，包含Environment.StackTrace和DateTime.Now - 调试时临时注释掉重启代码，或加条件
#if DEBUG ... #endif，否则断点永远停不住
重启本身很简单，难的是让重启不丢状态、不破约束、不骗自己。尤其要注意参数传递的完整性、Mutex 的生命周期、以及调试期和生产期行为差异。
