应直接使用X509Certificate2.LoadFromBytes加载证书：.cer无需密码，.pfx需传密码并指定X509KeyStorageFlags（如MachineKeySet|PersistKeySet），PEM需先Base64解码；HasPrivateKey为true不保证可用，须调用GetRSAPrivateKey()验证非null并及时Dispose()。
直接用 X509Certificate2，别碰老的 X509Certificate——它不支持私钥访问、不能处理 PEM、在 .NET Core/.NET 5+ 上连 GetRSAPrivateKey() 都没有，硬切只会卡在签名失败或平台异常上。
为什么 X509Certificate2.LoadFromBytes 是最安全的加载入口
从 HTTP 响应、数据库 BLOB 或内存流拿到证书原始数据时，写临时文件再读是典型反模式：权限泄漏、竞态、清理遗漏。.NET 的 LoadFromBytes 直接接管字节解析，自动识别 DER、PEM、PKCS#12 格式，且全程可控。
-
.cer（公钥）：调用X509Certificate2.LoadFromBytes(byte[] data)即可，无需密码 -
.pfx（含私钥）：必须传密码，且强烈建议显式指定X509KeyStorageFlags，例如X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet - PEM 字符串：先去掉
-----BEGIN CERTIFICATE-----和换行，再Convert.FromBase64String()，最后喂给LoadFromBytes；直接传 PEM 字符串会抛CryptographicException
HasPrivateKey == true 不代表你能用私钥
这个布尔值只说明证书结构里“有”私钥字段，不代表当前进程能成功提取密钥对象。Linux/macOS 下若漏设 X509KeyStorageFlags，HasPrivateKey 可能返回 true，但 GetRSAPrivateKey() 返回 null 或抛 PlatformNotSupportedException。
- 验证是否真能用：必须调用
cert.GetRSAPrivateKey()并检查返回值非null - 老式
PrivateKey属性返回RSACryptoServiceProvider，跨平台不可用，已标记为 obsolete - 签名场景下，如果
GetRSAPrivateKey()失败，优先检查 PFX 加载时是否传了正确密码、X509KeyStorageFlags是否包含PersistKeySet（尤其在容器或无用户上下文环境）
StoreLocation.CurrentUser vs MachineKeySet：权限和生命周期陷阱
证书存进 Windows 证书存储后，访问行为受 X509KeyStorageFlags 和运行账户双重约束。常见错误是本地开发用 CurrentUser 正常，部署到 IIS 或 Windows Service 就报“拒绝访问”或私钥不可用。
-
X509KeyStorageFlags.UserKeySet（默认）：私钥存入当前用户配置，Service 账户无法访问 -
X509KeyStorageFlags.MachineKeySet：私钥存入机器级存储，需管理员权限安装，但适合服务场景 -
PersistKeySet必须配合使用，否则私钥仅内存存在，GetRSAPrivateKey()多次调用可能返回不同实例甚至失败 - 在 Docker 容器中，
MachineKeySet通常无效，应改用内存加载 +PersistKeySet组合，避免依赖系统存储
真正麻烦的不是加载证书，而是加载后密钥对象的生命周期管理——GetRSAPrivateKey() 返回的对象需要手动 Dispose()，否则在高并发签名场景下容易触发句柄泄漏。这点文档极少提，但生产环境 CPU 突增往往就源于此。
