服务运行账户必须使用专用低权限用户，禁止localsystem或administrator；文件操作依赖账户实际权限，需显式授权目标路径并避免静默异常；禁用交互式api，预建目录并固化ntfs权限。
服务运行账户必须是专用低权限用户，不能用 LocalSystem 或 Administrator
Windows 服务默认以 LocalSystem 运行时拥有近乎管理员级的文件访问能力，这直接违背最小权限原则。哪怕只读一个日志目录，也不该赋予它修改 C:Windows 或其他服务无关路径的权限。
实操建议：
- 新建专用本地用户（如
svc-filewatcher），不加入任何特权组（Administrators、Power Users等） - 在服务属性 → “登录”选项卡中显式指定该用户，并填入密码（服务账户密码需定期轮换）
- 若服务需网络访问（如写共享目录），改用域账户并限制其仅对目标 UNC 路径有
Read/Write权限，而非给Everyone开放
DirectoryInfo 和 FileStream 构造时默认继承进程权限，不自动降权
C# 的 DirectoryInfo、FileStream、File.WriteAllText 等 API 不会因为你“想最小权限”就自动过滤掉高权限。它们完全依赖当前线程的 Windows 访问令牌 —— 也就是服务登录账户的实际权限。
常见错误现象：
- 开发机上用自己账号测试正常，部署到服务后抛出
UnauthorizedAccessException（账户没被授予目标目录的Traverse或ReadData） - 误以为
FileOptions.NoBuffering或FileAccess.Read能绕过 NTFS 权限检查 —— 实际上这些参数只影响 I/O 行为，不改变 ACL 判定逻辑
实操建议：
- 用
cacls或icacls显式检查目标路径权限：icacls "C:AppData" /user svc-filewatcher - 只授予必要权限：对日志目录加
Modify，对配置目录只加ReadAndExecute，绝不用FullControl - 避免使用
Directory.CreateDirectory自动递归建目录 —— 它会尝试在父路径上写 ACL，而低权限账户通常无权修改父目录的WRITE_DAC
App.config 中 fileStream 的 useLegacyEncoding=false 不影响权限，但影响日志写入失败静默
这个配置项常被误认为和安全相关，其实它只控制 StreamWriter 是否使用系统默认编码（如 GBK），与文件访问权限完全无关。但它会间接导致权限问题更难排查。
使用场景：
- 服务以低权限账户运行，尝试用
File.CreateText("C:Logspp.log")写日志 - 若
C:Logs目录未提前授权给该账户，CreateText抛UnauthorizedAccessException - 但如果日志框架捕获异常后静默吞掉（尤其设置了
useLegacyEncoding="false"后某些旧版 NLog 行为异常），你根本看不到错误，只发现日志缺失
实操建议：
- 所有文件操作必须包裹
try/catch (UnauthorizedAccessException)并记录原始错误信息 - 启动服务前，用
runas /user:svc-filewatcher cmd.exe手动模拟账户权限，测试能否type或echo test > test.txt目标路径 - 避免在服务启动阶段动态创建父目录；把
C:AppData、C:AppLogs等路径预建好，并用icacls固化权限
Windows 服务无法绕过 UAC，但可以利用“服务隔离”特性规避交互式权限提升陷阱
有人试图让服务调用 Process.Start("notepad.exe") 并提权写系统目录 —— 这在 Vista+ 上必然失败。服务会话（Session 0）与用户桌面（Session 1+）完全隔离，且 UAC 对服务账户默认禁用提权弹窗。
性能 / 兼容性影响：
- 不要在服务中调用需要交互或桌面会话的 API（如
ShellExecute、OpenFileDialog），它们要么失败要么挂起 - 如果真需触发用户侧动作（如通知用户配置变更），应通过命名管道或事件日志通信，由独立的用户模式代理程序处理，而非服务直写
HKEY_CURRENT_USER - NTFS 权限检查本身开销极小，但频繁检查不存在的路径（如每秒
File.Exists(@"\servershareconfig.json")）会因 SMB 超时拖慢服务响应
真正容易被忽略的是：服务账户对 C:WindowsTemp 默认只有 Read 权限，不是 Write。很多第三方库（如某些 XML 解析器）会在临时目录解压资源，结果静默失败。得手动给 svc-filewatcher 加 Write 权限到你指定的专用临时目录，而不是复用系统 Temp。
