为何在Startup.cs添加services.AddDataProtection()可解决XmlException与CryptographicException

ASP.NET Core 内置的 Data Protection 组件负责处理全框架的敏感数据加解密逻辑，常用场景包括认证Cookie加密、防伪令牌生成、路由敏感参数加密等，你访问Edit页面时框架自动生成防伪令牌、或者加密路由ID都会调用这个组件的能力。
默认情况下如果你没有显式配置 Data Protection，它会自动匹配运行环境选择密钥存储位置：

• IIS 进程内托管时存储到 IIS 配置存储区
• Kestrel 直接运行时，如果当前进程用户的用户配置文件可加载，密钥会存到 %LOCALAPPDATA%\ASP.NET\DataProtection-Keys 目录
• 如果当前运行环境不支持用户配置文件加载（比如站点用低权限虚拟账户运行、部署在Docker容器、进程没有对应目录的写入权限），组件会自动降级为内存存储密钥，进程重启、站点回收后密钥就会彻底丢失，多实例部署时也会出现实例间密钥不互通的问题。

你在 ConfigureServices 中添加的 services.AddDataProtection().PersistKeysToFileSystem(/* 你的目录路径 */) 配置，本质是强制覆盖了组件的默认存储逻辑：

1. 不管运行环境的用户配置文件是否可用，都直接把密钥以XML格式持久化到你指定的本地目录，不会降级为内存存储，密钥不会随进程重启丢失
2. 只要你给配置的目录开放了进程的读写权限，组件就能正常生成、读取格式完整的密钥文件，不会出现密钥文件写入失败、内容为空的问题。

你遇到的两个异常是Data Protection失效的典型连锁报错：

1. 首先出现的 CryptographicException: 尝试加密数据时出错 是直接信号：说明框架在调用加密能力时，没有获取到可用的有效密钥，加密流程直接中断。
2. 后续的 XmlException: 十六进制值0x00为无效字符，位于第1行第1位 是根因体现：Data Protection 组件加载密钥的时候，读取到的密钥XML文件内容为空/损坏，文件第一行第一位就是空字符（0x00），XML解析器无法解析非法格式的密钥文件，就会抛出这个异常。

默认未配置密钥持久化的场景下，只要出现运行环境权限不足、密钥目录写入失败的情况，就会生成空的密钥文件，或者直接使用内存密钥，站点重启后再次读密钥就会触发这两类报错。

内容的提问来源于stack exchange，提问作者Joe Schmitt