ProtectedData.Protect 是当前用户无密码场景的唯一合理选择，因其绑定Windows登录会话凭据而非用户密码，自动管理内存与UTF-8编码，且.NET Core 3.1+原生支持。
直接用 ProtectedData.Protect，别碰 CryptProtectData P/Invoke —— 除非你明确需要 CRYPTPROTECT_SYSTEM 标志或复用旧版熵逻辑。
为什么 ProtectedData 是当前用户无密码场景的唯一合理选择
DPAPI 本身不依赖用户密码是否设置，它绑定的是 Windows 登录会话凭据（LSA 管理的密钥材料）。哪怕用户账户没设密码，DataProtectionScope.CurrentUser 依然有效——这是 Windows 的设计行为，不是妥协。
-
ProtectedData自动处理内存生命周期，不会因漏掉Marshal.FreeHGlobal导致句柄泄漏 - 它默认使用 UTF-8 编码路径和熵处理逻辑，避免手动转换时出现
Encoding.Default引发的乱码解密失败 - .NET Core 3.1+ 在 Windows 上完全支持，无需额外 NuGet 包；
Microsoft.AspNetCore.DataProtection是另一套机制，不等于 DPAPI
ProtectedData.Protect 加密配置项时的三个硬约束
加密后存进 appsettings.json 或 MyApp.exe.config 前，必须满足：
- 传入的
userData必须是byte[]，不能直接传字符串——否则隐式调用ToString()得到的是类型名，不是内容 -
optionalEntropy若非空，必须在加解密两端完全一致；调试时建议用固定值如Encoding.UTF8.GetBytes("MyAppV3")，而非null或随机字节数组 - 作用域必须匹配：开发时用
DataProtectionScope.CurrentUser，部署后若以 Windows 服务运行，确认该服务登录身份（如NT SERVICE\MyService）是否拥有对应用户的 DPAPI 凭据访问权限
为什么解密总抛 CryptographicException: Key not valid for use in specified state
这不是密钥损坏，而是上下文错配。典型触发点：
- 在开发机用自己账户加密，部署到服务器后由
ApplicationPoolIdentity或LocalSystem身份尝试解密 - Windows 服务配置为 “本地系统” 账户，但代码里用了
DataProtectionScope.CurrentUser（此时实际绑定的是 SYSTEM 用户上下文，而非你登录的用户） - 用户重置密码后未同步凭据缓存（极少见，但发生时需重新加密）
验证方式：写个最小测试程序，在目标运行环境下直接调用 ProtectedData.Unprotect，传入已知加密数据，看是否立即失败——能排除代码逻辑问题，聚焦环境配置。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
Base64 存 JSON 时最容易被忽略的编码陷阱
加密后的 byte[] 转 string 必须走 Convert.ToBase64String，解密前必须用 Convert.FromBase64String 还原；任何中间环节插入 Encoding.UTF8.GetString 或 JSON 反序列化自动转义，都会破坏原始字节流。
示例错误写法：
string jsonValue = JsonSerializer.Serialize(new { Secret = Encoding.UTF8.GetString(encryptedBytes) }); // ❌ 错！这是把二进制当文本解释
正确做法：
string jsonValue = JsonSerializer.Serialize(new { Secret = Convert.ToBase64String(encryptedBytes) }); // ✅
读取时也必须反向严格还原，不能依赖 JSON 库自动处理编码差异。
