Avalonia应用加密配置文件需借助.NET加密类而非框架内置能力，推荐AES-GCM对JSON序列化内容加解密并安全管理密钥，或Windows下用ProtectedData实现免密钥保护。
在 Avalonia 应用中加密配置文件，核心不是 Avalonia 本身提供加解密能力（它不内置加密 API），而是结合 .NET 的标准加密类（如 Aes、ProtectedData）对配置文件内容进行保护。关键在于：配置读写流程中插入加解密环节，且密钥/保护上下文需安全处理。
使用 AES 对配置 JSON 进行对称加密
适合本地存储、需要跨平台（Windows/macOS/Linux）的场景。推荐用 AES-GCM 模式（带认证，防篡改）或 AES-CBC（需手动管理 IV 和填充）。
- 将配置对象序列化为 JSON 字符串（如用
System.Text.Json） - 生成随机 256 位密钥和 128 位 IV（仅加密时生成，IV 可明文附在密文前）
- 用
AesGcm.Encrypt()加密 JSON 字节，得到密文 + 认证标签 - 将 IV、Tag、密文 Base64 编码后保存到文件（如
config.aes.json） - 解密时先 Base64 解码，拆出 IV/Tag/密文，用相同密钥调用
AesGcm.Decrypt()，再反序列化为对象
⚠️ 密钥不能硬编码。可由用户口令派生（PBKDF2 + 用户输入）、或从系统凭据库（如 Windows Credential Manager）读取。
利用 ProtectedData 实现 Windows 专属透明保护
若只面向 Windows，System.Security.Cryptography.ProtectedData 是最简方案：无需管理密钥，系统自动绑定当前用户/机器。
- 加密：
ProtectedData.Protect(bytes, optionalEntropy, DataProtectionScope.CurrentUser) - 解密：
ProtectedData.Unprotect(...) - entropy（盐值）建议固定但不公开的字符串（如应用 GUID），增强隔离性
- 加密后直接保存为二进制文件或 Base64 字符串到 JSON 中
✅ 优点是零密钥管理；❌ 缺点是无法跨用户/跨机器迁移，macOS/Linux 不支持。
配置文件结构与加载时机设计
避免在 App 启动早期（如 App.xaml.cs 构造函数）就硬解密——此时 UI 尚未就绪，错误难提示。推荐：
- 定义一个
SecureConfigService单例，延迟初始化 - 首次访问配置时（如主窗口 ViewModel 请求设置），弹出密码输入框（若用口令派生）或静默调用
ProtectedData - 解密成功后缓存明文对象（内存中），后续直接返回；敏感字段（如 API Key）可按需解密，不常驻内存
- 写入时同样走同一套加密流程，覆盖原文件
规避常见风险的细节提醒
安全失效往往源于细节疏忽：
- 不要用 ECB 模式（AES 默认不选它，但要确认）——它不隐藏数据模式
- 不要复用 IV —— 每次加密必须新生成随机 IV
- 不要把密钥存在配置文件、资源文件或程序集里 —— 改用环境变量（开发）、系统凭据（生产）、或用户交互派生
- 临时解密后的明文配置对象，避免被意外日志输出（如
ToString()泄露） - 考虑文件权限：加密后仍需设置文件 ACL（如 Linux
chmod 600，Windows 设置仅当前用户可读）
