推荐使用 Startup 文件夹而非 Registry.CurrentUser 实现 C# 程序开机自启，因其纯文件操作、绕过组策略拦截、无需提权且更安全；Registry.CurrentUser 仅适用于简单场景，需注意路径引号、值类型和延迟生效；计划任务适合高可靠性需求。
不需要管理员权限，就能让 C# 程序开机自启——Registry.CurrentUser 和 %APPDATA%MicrosoftWindowsStart MenuProgramsStartup 这两种方式足够稳定、够用，且避开 UAC 提权和企业策略拦截风险。别一上来就碰 HKEY_LOCAL_MACHINE，90% 的桌面工具根本用不上它。
怎么用 Registry.CurrentUser 安全写入 Run 键
这是最轻量、最直接的方式，只影响当前用户，无需提权，但要注意几个关键点：
-
Registry.SetValue的四个参数里，valueName是你自定义的键名（比如"MyAppLauncher"），不是路径；value才是带引号的完整路径字符串，例如""C:\My App\launcher.exe"" - 必须显式指定
RegistryValueKind.String，否则可能被识别为Binary，系统无法执行 - 路径含空格时双引号不能省——不是加一层，而是两层：外层是 C# 字符串转义，内层是 Windows 解析所需，最终注册表里看到的是
"C:My Applauncher.exe" - 写入后不会立即生效，要等下次用户登录；调试时可手动运行
explorer shell:startup验证是否已触发
为什么 Startup 文件夹比注册表更推荐
因为它是纯文件操作，不碰注册表，绕过所有组策略对 Run 键的禁用，也极少被 Windows Defender 拦截：
- 目标路径是
Environment.GetFolderPath(Environment.SpecialFolder.Startup)，返回类似C:UsersAliceAppDataRoamingMicrosoftWindowsStart MenuProgramsStartup - 必须用
IWshRuntimeLibrary.WshShell创建 .lnk 快捷方式，不能直接复制 exe —— 否则会报错或静默失败 - 快捷方式可设
WindowStyle（如最小化启动）、WorkingDirectory、甚至带命令行参数，注册表做不到这点 - 删除时直接
File.Delete(lnkPath)即可，不用查注册表是否存在，逻辑更干净
常见错误：写入了却没启动，或者启动报错
现象背后往往有明确原因，不是“代码没生效”，而是环境或路径细节没对上：
-
UnauthorizedAccessException：误用了Registry.LocalMachine且没以管理员身份运行程序 - 重启后无反应：路径写成相对路径（如
"bindebugpp.exe"），或没加引号导致空格截断（注册表里只存了C:My） - 启动时报“找不到依赖项”：快捷方式的工作目录没设对，或 .NET 运行时未预装——建议把 exe 放在
%LOCALAPPDATA%下，避免权限问题 - 企业环境中失效：组策略禁用了
Run键，但 Startup 文件夹通常仍可用；计划任务（schtasks /create /sc onlogon）是更鲁棒的备选
要不要用计划任务替代注册表或 Startup
当你的程序需要“登录即运行 + 延迟几秒 + 失败自动重试”时，计划任务才是正解，而且普通用户也能创建用户级任务：
- 用
schtasks /create /tn "MyAppOnLogon" /tr "C:path opp.exe" /sc onlogon /ru "%USERDOMAIN%%USERNAME%"命令即可 - C# 中调用
TaskService（需引用TaskSchedulerNuGet 包）能精细控制触发条件、重复间隔、失败策略 - 相比注册表和 Startup，计划任务能处理“用户尚未加载配置文件”的早期登录阶段，更适合后台服务型应用
- 唯一缺点是首次创建时部分杀软会弹窗提示——但这是用户可见的、可控的信任授权，比静默注册表修改更合规
真正难的不是写哪一行代码，而是判断该用哪种机制：普通工具选 Startup 文件夹；需要参数或最小化启动，用快捷方式；要求高可靠性或延迟执行，上计划任务；除非你做安装器或系统组件，否则别碰 LocalMachine 注册表。
