securestring 是专为短期持有、立即擦除设计的内存敏感数据容器，不可序列化、不可转为普通 string，length 返回 char 数而非 unicode 字符数，makereadonly() 后不可修改，不推荐在 .net 6+ 新项目中使用。
SecureString 不是“更安全的 string”，它是专为**短期持有、立即擦除**设计的内存敏感数据容器。它不能被序列化、不能直接参与 XML/JSON 构建、不能转成普通 string —— 任何试图绕过这些限制的操作，基本等于废掉它的全部安全价值。
为什么 SecureString.Length 返回的是 char 数而不是 Unicode 字符数
SecureString.Length 只统计底层 char 元素个数，不处理代理对（surrogate pair）。这意味着像 ?（U+1F680）这种需要两个 char 表示的 Unicode 字符，Length 会返回 2，而非 1。
- 这不是 bug，是设计使然：它只暴露原始内存布局信息，不提供字符语义解析
- 实际使用中，如果你依赖长度做输入限制（比如“最多 15 个字符”），应按
char计数，而非用户感知的“字” - 不要用
Length判断是否包含 emoji 或中文——它无法反映真实视觉长度
SecureString.MakeReadOnly() 调用后还能修改吗
不能。调用 MakeReadOnly() 后，再调用 AppendChar()、RemoveAt() 或 SetAt() 都会立刻抛出 InvalidOperationException，错误信息是 “Operation is not valid due to the current state of the object.”
- 这个只读状态不可逆，也不能“取消只读”
- 必须在所有字符输入完成后、且尚未传递给下游 API 前调用，否则后续逻辑可能因意外修改而失败
- 常见误操作：在循环中边输入边调用
MakeReadOnly()，导致后续字符无法追加
如何把 SecureString 安全地传给需要 string 的 API（比如 XmlWriter）
你不能也不该这么做。任何将 SecureString 转为托管 string 的路径（例如 Marshal.PtrToStringUni(SecureStringToGlobalAllocUnicode(ss))）都会让明文长期驻留 GC 堆，失去保护意义。
- 正确做法是：用
Marshal.SecureStringToCoTaskMemUnicode(ss)获取非托管指针，传给支持IntPtr或char*的底层 API（如某些 Win32 或 COM 接口） - 若目标 API 强制要求
string（如XElement构造），说明它不适合处理敏感数据——此时应改用加密密文 +SecureString管理密钥的分离模式 - 务必配对调用
Marshal.ZeroFreeCoTaskMemUnicode(ptr)，否则内存泄漏且残留明文
SecureString 在 .NET 6+ 中还值得用吗
在新项目中，优先考虑 SecretProtection（Microsoft.Extensions.ProtectedData）或 DPAPI 封装的密钥管理方案；SecureString 仅适用于明确需要与 Win32 密码 API（如 CredWrite）交互，或兼容旧版 Windows 安全组件的场景。
-
SecureString在 .NET Core 2.0+ 已被标记为“功能完整但不再增强”，官方文档明确建议“仅用于互操作” - 它无法跨进程/跨 AppDomain 保护，也无法防止调试器内存快照（现代调试器仍可读取其底层内存块）
- 最易被忽略的一点：它不自动清零已释放内存——若未显式调用
Dispose()，或未配合ZeroFree*系列方法，残留内容可能持续存在于物理内存中数秒甚至更久
