企业官网建设流程全解析

1. 先把问题拆成三块：进程身份、会话边界、文件关联

Windows 后台服务想以“默认打开文件的方式”打开一个文件，表面看只是调个 API 的事，实际上一脚踩进三个独立的机制里：服务进程的身份不是用户、服务所在的会话没有可见桌面、“默认打开方式”本身是一次 Shell 与注册表文件关联的解析。这三块任何一块没处理对，现象都是同一个——代码返回成功，屏幕上一片安静。所以动手之前，我建议先把这三块拆清楚，比直接抄一段ShellExecute代码有用得多。

这个需求的典型场景其实很朴素：某个采集服务收到一份报表，想让当前登录的用户看到它；某个打印服务生成 PDF 后希望用户直接预览；某个守护程序检测到配置文件异常，想在用户桌面弹出编辑器。共同点是“干活的是系统身份的服务，看结果的是登录的用户”。把这三块机制理顺之后，你就知道为什么有人写了三十行代码就通了，有人折腾三天还在怀疑人生。

1.1 服务的进程身份天生不是“用户”

服务默认以 LocalSystem 身份运行，令牌里没有用户的环境变量、没有用户映射的网络驱动器、HKEY_CURRENT_USER指向的是 SYSTEM 的配置单元，连“我的文档”这种路径都会解析到系统账户目录下。这一点最直接的后果是：即便你在服务里成功调用了 Shell 接口，它去查文件关联时读的是 SYSTEM 的注册表视图，而大量按用户安装的软件（尤其是那些只写HKCU\Software\Classes的编辑器、看图工具）在 SYSTEM 视图里根本不存在，最终表现就是“系统找不到指定的文件”或者弹出一个莫名其妙的“打开方式”选择框。

所以“以用户身份跑”不是可选优化，而是这个需求的前置条件。后面所有的技术方案，本质都是在解决同一个问题：怎么把服务的 SYSTEM 身份，换成目标用户的身份，并且让新进程落在正确的会话里。理解这一点，你在选型时就不会被各种“一行代码打开文件”的示例带偏。

1.2 会话隔离：0 号会话没有可见桌面

从 Vista 开始，服务被固定在 Session 0，用户登录后拿到的是 Session 1 或更高的编号，两者之间有一堵硬隔离的墙。服务进程可以直接创建窗口、可以直接调用 Shell 接口，但这个窗口画在 0 号会话的隐藏桌面上，没有人能看见。很多人第一次遇到“代码没报错但屏幕上什么都没有”，就是卡在这里。

判断方法很简单：打开任务管理器，切到“详细信息”页，看“会话”那一列。你的服务进程是 0，explorer.exe是 1（或 2、3……远程连接时会变）。同一个进程想跨会话创建子进程是会失败的，或者创建出来仍然留在 0 号会话。必须显式地做两件事：把令牌的会话 ID 改到目标会话，创建进程时把桌面名指定为winsta0\default。这两步少一步，进程要么起不来，要么起来了但用户看不见。

1.3 默认打开文件靠的是 Shell 与文件关联，不是 CreateProcess

这是第三个容易混淆的点。CreateProcess只认可执行文件，你传一个.pdf给它，它会诚实地返回“不是有效的 Win32 应用程序”。真正实现“双击效果”的是 Shell 层：它去查.pdf对应的 ProgID，再查 ProgID 下的shell\open\command，然后把命令行拼出来执行。ShellExecute/ShellExecuteEx就是这个过程的封装。

这就带来一个重要的推论：文件关联的解析必须发生在用户身份下，因为查关联时 Shell 会读HKCU\Software\Classes和HKCR的合并视图，用户装的软件才会被找到。也就是说，正确姿势不是在服务里调 Shell 接口，而是在用户会话里起一个小的“启动器”进程，由它去调 Shell 接口。这条链路上每一环都有它存在的理由，不是多此一举。

2. 三条路线怎么选：直接切令牌、任务计划、用户侧代理

实现这个需求有不止一种打法，我把实际项目中用过、验证过的三条路线摆出来。它们没有绝对优劣，取决于你的服务权限、部署环境和对可靠性的要求。我个人的建议是：能选路线三就别省那点工作量，因为前两条路线在真实环境里的边界情况会比你预想的多。

2.1 路线一：WTSQueryUserToken 加 CreateProcessAsUser

这是最“正统”的做法，全程在自己的代码里完成，不依赖外部组件。核心链路是：枚举会话找到活动的那一个，用WTSQueryUserToken拿到该会话的用户令牌，复制成主令牌，把会话 ID 改过去，关联网环境块，最后CreateProcessAsUser拉起一个启动器进程。启动器里再调ShellExecuteEx完成打开动作。

优点是完全可控、没有外部依赖、延迟低；缺点是对权限有硬要求——WTSQueryUserToken需要调用者是 LocalSystem 并且持有SeTcbPrivilege。如果你的服务跑在LocalService或某个自定义账户下，这条路直接堵死。另外它只解决“起进程”，不解决“用户还没登录怎么办”，时序问题得自己做。

2.2 路线二：借任务计划程序在用户会话里起进程

任务计划程序天然理解“用户会话”这个概念，创建一个登录类型为“交互式令牌”、触发器为“按需”的任务，指定运行账户为目标用户，然后从服务里调用Run就行。实现方式可以是命令行调schtasks，也可以走TaskScheduler的 COM 接口。它的好处是绕开了SeTcbPrivilege的限制，普通服务账户也能用，而且任务计划服务本身就常驻，稳定性不错。

代价是链路变长、可观测性变差。schtasks /run返回成功只代表“任务已提交”，不代表文件真的打开了；排查问题时你要跨两个日志体系去看。另外首次创建任务时如果不小心设成了“只在用户登录时运行”但账户写错，会静默失败。这条路适合那种“服务权限受限、且能接受异步提交”的场景。

2.3 路线三：常驻用户侧代理加命名管道

这是我现在的首选。思路是把责任拆开：用户登录时自启一个轻量代理进程（计划任务“登录时触发”、启动项、或者干脆做成一个托盘小工具），代理常驻在用户会话里，通过命名管道监听服务端发来的“打开某个文件”的请求，收到就调 Shell 接口，然后把成功与否回传给服务。

好处非常实在：启动器天然在用户会话、用户身份、用户桌面下，不需要任何特权令牌操作；能拿到真实的返回码和错误信息；还能做频率限制、弹窗确认、路径白名单这些安全策略；服务重启、代理重启互不影响，断线重连就完事。缺点是部署多一个进程，用户能看到它。我的经验是，只要产品能接受一个常驻小进程，这条路在长期维护上的收益远超那点部署成本。

3. 核心细节：令牌、环境块与桌面

选好路线之后，真正的技术细节集中在路线一的链路上——即使你最终选路线三，理解这些细节也能帮你判断代理进程为什么起不来。这一章把几个关键动作拆开讲，每个都说清楚“为什么必须这么做”，而不是“照着写就行”。

3.1 令牌要复制成主令牌，并显式改掉会话 ID

WTSQueryUserToken返回的是一个模拟令牌，而CreateProcessAsUser需要的是主令牌。类型不对，调用会失败并返回一个看起来很莫名的错误码。所以中间必须过一次DuplicateTokenEx，把模拟级别设为SecurityImpersonation，类型设为TokenPrimary。

复制完之后还有关键一步：SetTokenInformation把TokenSessionId改成目标会话的 ID。这一步很多人会漏，原因是“我明明传了 sessionId 给 WTSQueryUserToken”。但那个参数只是告诉系统“去哪个会话找用户”，返回的令牌本身并不会自动带上会话归属。不改会话 ID 直接创建进程，进程会落在调用者（服务）所在的 0 号会话，白忙一场。

一个容易忽略的细节：SetTokenInformation传TokenSessionId同样需要SeTcbPrivilege。以 SYSTEM 运行的服务默认持有该特权，所以通常不用手动调整；如果你把它放在一个自定义账户下运行，就得先用AdjustTokenPrivileges显式启用SE_TCB_NAME，否则这一步会以ERROR_PRIVILEGE_NOT_HELD失败。

3.2 环境块、工作目录与 winsta0\default

创建进程时如果不带环境块，新进程会继承调用者的环境变量，也就是 SYSTEM 的那一套。用户桌面上的程序很可能依赖%APPDATA%、%USERPROFILE%、%TEMP%这类变量，拿着 SYSTEM 的值去跑，轻则配置读不到，重则直接崩溃。正确做法是调CreateEnvironmentBlock用目标用户令牌生成环境块，创建时带上CREATE_UNICODE_ENVIRONMENT标志，用完DestroyEnvironmentBlock释放。

桌面参数是第二个必填项。STARTUPINFO的lpDesktop要设成winsta0\default，否则进程会落到一个不可见的默认桌面上，用户依然看不到。这个字符串看起来像魔法值，其实是“窗口站名\桌面名”的固定写法，winsta0是交互式窗口站，default是用户正常登录后的桌面。

还有个小细节常被忽略：lpApplicationName传空、命令行传完整路径时，注意可执行文件路径本身要加引号。路径里有空格是常态（C:\Program Files\...），不加引号 Windows 会按空格切分参数，行为就不可预测了。

3.3 启动器里必须用 ShellExecuteEx 并加 SEE_MASK_NOASYNC

进入启动器进程，这才是真正执行“默认打开”的地方。这里必须用ShellExecuteEx而不是ShellExecute，原因是前者的SHELLEXECUTEINFO结构体让你能控制标志位，尤其是SEE_MASK_NOASYNC。这个标志的含义是“不要异步执行、不要依赖 DDE 协商”，对没有消息循环的进程（比如控制台程序、服务拉起的短生命周期进程）是必须的，否则可能卡住或者静默失败。

lpVerb填open，lpFile填文件的绝对路径，lpDirectory填文件所在目录。这个lpDirectory不是摆设——有些老程序的关联命令会写相对路径，不设工作目录就会在当前目录下找不到东西。nShow用SW_SHOWNORMAL就够了。

另外记得在启动器入口调CoInitializeEx，因为 Shell 内部会用 COM。公寓模型用COINIT_APARTMENTTHREADED配合COINIT_DISABLE_OLE1DDE，用完CoUninitialize。不初始化 COM 时，某些文件类型（尤其是走 Shell 扩展预览的）会失败，错误码还很难看懂。

3.4 关于 SEE_MASK_FLAG_NO_UI 的取舍

我上面的示例里用了SEE_MASK_FLAG_NO_UI，它会抑制 Shell 自己弹的错误对话框。这个选择要看场景：面向内部工具的，我建议去掉这个标志，让用户看到“这个文件没有关联程序”的原始提示，至少知道发生了什么；面向批量处理的，保留它，避免一堆模态框卡住流程。

还有个替代思路值得知道：不用 Shell API，直接通过explorer.exe中转，把文件路径作为参数传给explorer.exe，效果等同于在资源管理器地址栏里敲路径。这一招在某些极端环境（Shell 扩展被注入得很乱的机器）上比ShellExecuteEx更皮实。缺点是拿不到任何有意义的返回结果——explorer.exe第二次被调用时会立刻退出，那个进程的退出码毫无参考价值。所以它只适合“我只要试试看”的场景，不适合需要知道成功与否的业务逻辑。

4. 动手实现：一套可以直接抄的启动器

理论说完，进入可以落地的部分。下面这套代码我在几个项目里都跑过，先在控制台模式下调试通过再套服务的壳，是更省时间的做法。代码分三段：服务侧找会话并拉进程、启动器 C++ 版、以及 .NET 项目的 P/Invoke 版本。参数和常量我都标了含义，方便你按自己的场景改。

4.1 服务侧：找活动会话、取令牌、拉起启动器

先解决“找哪个会话”的问题。单机物理控制台用WTSGetActiveConsoleSessionId就够，但它对远程连接的场景不友好——远程会话也是活动会话，控制台会话可能处于断开状态。稳妥的做法是枚举所有会话，挑状态为WTSActive的那一个。

#include <windows.h> #include <wtsapi32.h> #include <userenv.h> #include <string> #pragma comment(lib, "wtsapi32.lib") #pragma comment(lib, "userenv.lib") // 返回活动会话 ID；找不到就退回控制台会话 DWORD FindActiveSessionId() { PWTS_SESSION_INFOW pInfo = nullptr; DWORD count = 0; if (!WTSEnumerateSessionsW(WTS_CURRENT_SERVER_HANDLE, 0, 1, &pInfo, &count)) return WTSGetActiveConsoleSessionId(); DWORD found = 0xFFFFFFFF; for (DWORD i = 0; i < count; ++i) { // 多个活动会话时取第一个，业务上可按需优先选控制台 if (pInfo[i].State == WTSActive) { found = pInfo[i].SessionId; break; } } WTSFreeMemory(pInfo); return (found == 0xFFFFFFFF) ? WTSGetActiveConsoleSessionId() : found; }

拿到会话 ID 之后，走“取令牌—换主令牌—改会话—建环境块—拉进程”这条链。注意每一步的错误码都要记日志，这个需求排查问题几乎全靠日志，光看“失败”两个字是没法定位的。

// 在指定会话中以该用户身份启动 exe，参数原样透传 bool LaunchInSession(DWORD sessionId, const std::wstring& exe, const std::wstring& args, DWORD* exitCodeOut) { HANDLE hUser = nullptr; // 需要 LocalSystem 且持有 SeTcbPrivilege if (!WTSQueryUserToken(sessionId, &hUser)) return false; HANDLE hPrimary = nullptr; if (!DuplicateTokenEx(hUser, MAXIMUM_ALLOWED, nullptr, SecurityImpersonation, TokenPrimary, &hPrimary)) { CloseHandle(hUser); return false; } CloseHandle(hUser); // 令牌归属改到目标会话，漏了这步进程会落在会话 0 if (!SetTokenInformation(hPrimary, TokenSessionId, &sessionId, sizeof(sessionId))) { CloseHandle(hPrimary); return false; } LPVOID pEnv = nullptr; CreateEnvironmentBlock(&pEnv, hPrimary, FALSE); std::wstring cmd = L"\"" + exe + L"\" " + args; STARTUPINFOW si = {}; si.cb = sizeof(si); si.lpDesktop = const_cast<LPWSTR>(L"winsta0\\default"); // 要点一 PROCESS_INFORMATION pi = {}; BOOL ok = CreateProcessAsUserW(hPrimary, nullptr, &cmd[0], nullptr, nullptr, FALSE, CREATE_UNICODE_ENVIRONMENT, pEnv, nullptr, &si, &pi); if (pEnv) DestroyEnvironmentBlock(pEnv); CloseHandle(hPrimary); if (!ok) return false; // 短等待拿到启动器的退出码，超时就让它自己跑 DWORD wr = WaitForSingleObject(pi.hProcess, 5000); if (exitCodeOut) { *exitCodeOut = 0; if (wr == WAIT_OBJECT_0) GetExitCodeProcess(pi.hProcess, exitCodeOut); } CloseHandle(pi.hThread); CloseHandle(pi.hProcess); return true; }

调用时传绝对路径，参数里带上目标文件：

DWORD sid = FindActiveSessionId(); std::wstring args = L"--file \"" + filePath + L"\""; DWORD code = 0; if (!LaunchInSession(sid, L"C:\\Tools\\opener.exe", args, &code)) { // 记录 GetLastError()，这里是排查的主战场 }

4.2 启动器：C++ 版，三十行搞定打开动作

启动器尽量做小做纯，只干一件事：解析参数，调 Shell，返回结果。不要在里面加业务逻辑，更不要在里面读配置文件——它跑在用户上下文里，依赖越少越稳。

#include <windows.h> #include <shellapi.h> #include <string> int WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int) { int argc = 0; LPWSTR* argv = CommandLineToArgvW(GetCommandLineW(), &argc); if (!argv || argc < 3) return 2; // 期望 --file <path> std::wstring file = argv[2]; LocalFree(argv); if (FAILED(CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE))) return 3; std::wstring dir = file; size_t pos = dir.find_last_of(L"\\/"); dir = (pos == std::wstring::npos) ? L"" : dir.substr(0, pos); SHELLEXECUTEINFOW sei = {}; sei.cbSize = sizeof(sei); // NOASYNC 是无消息循环进程的关键；NO_UI 按场景取舍 sei.fMask = SEE_MASK_NOASYNC | SEE_MASK_FLAG_NO_UI; sei.lpVerb = L"open"; sei.lpFile = file.c_str(); sei.lpDirectory= dir.empty() ? nullptr : dir.c_str(); sei.nShow = SW_SHOWNORMAL; BOOL ok = ShellExecuteExW(&sei); DWORD err = ok ? 0 : GetLastError(); CoUninitialize(); return ok ? 0 : (int)err; }

这个启动器编译成Win32或x64都行，跟服务保持一致省心。注意它没有控制台窗口（用了wWinMain），用户不会看到一个黑框一闪而过，体验上干净很多。

4.3 启动器：C# 与 .NET 项目的 P/Invoke 版本

如果服务是 .NET 写的，不必为启动器单独搞一套 C++，P/Invoke 完全够用。关键是把STARTUPINFO和PROCESS_INFORMATION结构体定义对，字段顺序错了会得到一堆无从下手的错误码。

[DllImport("Wtsapi32.dll", SetLastError = true)] static extern bool WTSQueryUserToken(uint sessionId, out IntPtr token); [DllImport("advapi32.dll", SetLastError = true)] static extern bool DuplicateTokenEx(IntPtr existing, uint access, IntPtr attrs, int level, int type, out IntPtr newToken); [DllImport("advapi32.dll", SetLastError = true)] static extern bool SetTokenInformation(IntPtr token, int infoClass, ref uint info, int infoLen); [DllImport("userenv.dll", SetLastError = true)] static extern bool CreateEnvironmentBlock(out IntPtr env, IntPtr token, bool inherit); [DllImport("userenv.dll")] static extern bool DestroyEnvironmentBlock(IntPtr env); [DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)] static extern bool CreateProcessAsUser(IntPtr token, string app, string cmd, IntPtr pa, IntPtr ta, bool inherit, uint flags, IntPtr env, string dir, ref STARTUPINFO si, out PROCESS_INFORMATION pi);

常量对应关系：MAXIMUM_ALLOWED = 0x02000000，SecurityImpersonation = 2，TokenPrimary = 1，TokenSessionId = 12，CREATE_UNICODE_ENVIRONMENT = 0x00000400。STARTUPINFO里的lpDesktop设成"winsta0\\default"，注意在 C# 里是两个反斜杠，转义少写一个是这条链路上最常见的低级错误。

另外提醒一句：在 .NET 里用Process.Start打开文件时，UseShellExecute的默认值在 .NET Framework 下是true，在 .NET Core / .NET 5+ 下变成了false。同一个方法在两套运行时上行为不同，升级框架后“打不开文件”多数是这个原因，显式写UseShellExecute = true就没歧义了。当然，这一切的前提是这段代码跑在用户进程里，跑在服务里设成什么都是白搭。

4.4 自测方法与日志埋点

调试这个需求别一上来就装服务，用控制台程序以管理员身份跑，能覆盖 90% 的问题。真的装成服务之后，调试手段会骤减，改一次代码就要重启服务，效率极低。我习惯的验证顺序是：先控制台验证令牌链路通不通，再验证启动器能不能被拉起，最后才验证 Shell 打开是否成功。三段分开测，出问题一眼就知道在哪一段。

日志一定要打全：会话 ID、令牌句柄是否为空、SetTokenInformation的错误码、启动器的退出码。启动器的退出码本身就是ShellExecuteEx失败时的GetLastError()，把它翻译成文本记进日志，比事后猜强一百倍。常见的几个值我心里有数：2 是文件没找到，5 是拒绝访问（通常是路径权限问题），31 是“连接到系统的设备没有发挥作用”（基本就是会话或桌面参数错了），1155 是“没有应用程序与此操作的指定文件有关联”。

5. 稳定性与安全：上线前必须补的功课

代码跑通只是开始，这套机制在生产环境里的脆弱点比一般功能多，因为它跨了身份、跨了会话、还依赖注册表里一堆你控制不了的文件关联配置。这一章列的是我踩过之后加进 checklist 的东西，缺了它们，某天早上你会收到“昨天还好好的，今天全打不开了”的反馈。

5.1 登录时序、重复触发与并发控制

服务通常比用户登录起得早。开机后服务已经在跑，用户还没输密码，这时候WTSEnumerateSessions找不到任何WTSActive状态的会话，WTSQueryUserToken也会失败。处理方式有两种：一是把任务排队，等服务监听到会话变为活动状态再执行；二是直接丢弃并记录日志。选哪种取决于业务语义——报表预览这类可以丢弃，配置修复通知这类最好排队。

监听会话变化可以用WTSRegisterSessionNotification注册窗口接收WTS_SESSION_LOGON消息，服务里创建一个隐藏窗口接收即可。嫌麻烦就轮询，十秒一次，成本可以忽略，实现简单不易出错。

并发控制同样重要。用户可能同时触发多次，每次都拉起一个启动器进程。文件被反复打开还算温和的，如果打开的是一个耗资源的编辑器，机器直接卡死。做法很简单：按文件路径加个短时效的互斥标记（内存字典足够），同一路径在若干秒内只放行一次。这个限制在代理方案里更容易做，也是我偏向路线三的原因之一。

5.2 路径与参数的安全边界

这是最需要警惕的地方。启动器接收的路径如果是外部输入（比如文件内容、网络报文），就存在被构造的风险。ShellExecuteEx本身不会把参数当命令执行，但它会走文件关联，而文件关联指向哪个程序，取决于用户注册表里被写入了什么。恶意程序把自己注册成.pdf的默认打开程序，这个链路天然就成了它被执行的通路。

我的做法是三层防护：第一，路径先规范化再校验，用GetFullPathName展开成绝对路径，检查是否落在允许的目录白名单内；第二，拒绝\\?\前缀和 UNC 网络路径，前者 Shell 本身就不支持，后者会引入网络延迟和凭据问题；第三，绝不用cmd /c start这类间接调用，一旦进入命令行解析，引号、特殊字符、注入面全部打开，且很难收干净。

还有一条容易被忽略：不要以管理员身份去打开文件。启动器跑在用户令牌下，打开文档时继承的是用户权限，这是对的。如果你的实现不小心让它带上了高完整性级别，用户编辑自己桌面上的文件都可能被拒绝，或者反过来产生意料之外的权限提升路径。

5.3 常见故障速查表

下面这张表是我这些年遇到的现象与成因对照，遇到问题时先按现象查，比从代码第一行读起快得多。

6. 踩坑记录与替代思路

这一节不讲方法论，讲我实际撞过的墙。有些坑看文档是看不出来的，只能靠翻错误码和反复试。

6.1 几个印象比较深的坑

第一个坑是“明明传了 sessionId 还是不行”。当时我理所当然地认为WTSQueryUserToken返回的令牌已经绑定了会话，直接拿去CreateProcessAsUser，进程起来了，任务管理器里能看到，会话列写着 0。折腾了半天才意识到必须补SetTokenInformation(TokenSessionId)。这个问题的迷惑性在于“没有报错”，一切返回值都是成功的，只有结果不对。

第二个坑是ShellExecuteEx偶发挂起。表现是启动器进程一直在，文件就是不打开，也不退出。根因是没加SEE_MASK_NOASYNC，Shell 在等 DDE 协商，而这个进程没有消息循环去处理。加上标志位之后问题消失。这个坑的可怕之处在于它不是必现的，机器上装的软件不同，触发概率不同，容易误判成“偶发环境问题”。

第三个坑和环境变量有关。有次用户反馈“打开后软件报无法读取配置”，查下来是启动的编辑器把配置路径解析到了C:\Windows\System32\config\systemprofile，因为进程继承了 SYSTEM 的环境块。补上CreateEnvironmentBlock之后，%APPDATA%才指向用户目录。这类问题的特点是“文件打开了，但软件行为诡异”，比打不开更难查。

第四个坑是路径编码。控制台输出、日志写入、命令行拼接，三个环节里只要有一个用了 ANSI 版本，中文路径就会变成问号。从服务到启动器全链路统一用宽字符版本（W后缀的 API），这是最省心的做法，别在中间做无谓的转换。

6.2 什么情况下不建议自己写这套东西

有些场景我会直接劝退：如果你的需求是“每次开机自动打开某个文件”，那用启动项或计划任务的“登录时触发”就够了，压根不需要服务；如果需求是“周期性打开给用户看”，计划任务本身就是更好的载体；如果打开动作需要用户确认或交互，那更应该放在用户侧，服务强行弹窗在观感和安全上都不合适。

真正需要服务介入的，是那种“服务端有状态、有业务判断，只有特定条件下才通知用户查看”的场景。这时候我推荐把服务做成纯粹的事件源，把“打开文件”这个动作交给用户侧代理，通过命名管道传一个结构化的请求（文件路径 + 请求 ID + 期望动作），代理执行后回传结果。服务端只负责重试和记录，代理只负责执行和回报，职责清晰到几乎不会互相牵连。管道名要带用户 SID 做隔离，消息体加上长度校验和超时，这两点做到位，稳定性基本就有保障了。

最后分享一个我自己总结的判断标准：如果一段代码需要你同时懂令牌、会话、桌面、文件关联这四样东西才能维护，那它就不该出现在业务代码里。把这四样东西关进一个两百行以内的小进程里，让它对外只暴露“给我一个文件路径，我告诉你成功或失败”，这是我在多个项目里验证过、最省心的做法。后面真要扩展，比如加个“打开前先弹确认”“同一文件五分钟内只开一次”，都在这一个小进程里改，业务代码一行都不用动。