UnauthorizedAccessException 是因路径权限不足所致，常见于写入系统保护目录；应优先选用 ApplicationData 等用户可写路径，并在 Save 前校验目录存在性、文件占用及 XML 合法性。
Save() 报 UnauthorizedAccessException：路径权限不足的典型表现
直接写入系统保护目录（如 C:\Windows、C:\Program Files）或只读文件夹时，XmlDocument.Save() 会抛出 UnauthorizedAccessException —— 这不是 XML 格式问题，是 Windows 文件系统权限拦截。.NET 不会自动提权，也不会弹窗请求管理员权限。
- 常见错误现象：
Access to the path 'C:\config.xml' is denied.或更模糊的DirectoryNotFoundException（实际是权限不足导致无法检查路径存在性） - 别急着加
try-catch吞掉异常，先确认目标路径是否可写：用File.GetAttributes(path)检查FileAttributes.ReadOnly，再用Directory.GetAccessControl()查当前用户是否有FileSystemRights.Write - 开发阶段默认运行在用户上下文，即使 VS 以管理员启动，调试进程仍受限于项目配置中的“启用用户账户控制（UAC）”行为
绕过权限限制的三种可行路径选择
与其硬刚权限配置，不如选对位置。Windows 对不同路径的写入策略差异极大，关键看「谁创建、谁拥有、谁使用」。
-
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)：用户级配置首选，路径如C:\Users\Alice\AppData\Roaming\MyApp\，无需额外权限，且随用户漫游（域环境） -
Path.Combine(Path.GetTempPath(), "myapp-config.xml")：临时文件场景适用，但注意生命周期不可控，不适用于持久化配置 - 相对路径（如
"./config.xml"）：实际写入位置取决于Process.GetCurrentProcess().StartInfo.WorkingDirectory，常被误认为“当前项目目录”，实则可能是C:\Windows\System32（尤其服务/计划任务场景）—— 务必用Path.GetFullPath()打印确认
Save() 前必须校验的三个状态
XmlDocument.Save() 不做前置路径检查，失败才报错。把校验逻辑提前，能避免静默失败或覆盖错误。
- 目标目录是否存在？用
Directory.Exists(Path.GetDirectoryName(filePath))，不存在则Directory.CreateDirectory()—— 注意：父目录可能跨盘符或网络路径，CreateDirectory会递归建，但若上级无写权限仍失败 - 目标文件是否被其他进程独占打开？
File.Open(filePath, FileMode.Open, FileAccess.Read, FileShare.None)尝试获取句柄，捕获IOException即说明被占用 - XML 内容是否合法？
xmlDoc.InnerXml可触发基础格式校验；若含未转义的&、等字符，<code>Save()会抛InvalidOperationException，和权限无关但现象相似
管理员权限不是银弹：什么时候真需要它？
仅当业务强约束路径（如必须写入 C:\inetpub\wwwroot\app\config.xml 供 IIS 读取），且部署环境可控时，才考虑提权方案。
- 桌面应用：在
app.manifest中设requestedExecutionLevel level="requireAdministrator"，但每次启动会弹 UAC 提示，普通用户易拒 - 服务应用：安装时用
sc create指定obj= "NT AUTHORITY\SYSTEM"，服务进程自带高权限，但需确保 XML 文件 ACL 显式授予服务账户写权限 - 绝对避免在代码里调用
Process.Start("cmd.exe", "/c takeown...")：绕过安全策略，极易被杀软拦截，且破坏部署一致性
最常被忽略的是：同一台机器上，用户 A 安装的应用写入了 Program Files 下的文件，用户 B 登录后根本打不开那个 XML —— 因为 ACL 默认只给安装者权限。持久化配置，永远优先选用户目录。
