能，需通过 P/Invoke 调用 advapi32.dll 中的 CredWriteW/CredReadW，限定 net6.0-windows+ 且仅限 Windows 平台，密码须用 SecureString 处理并严格匹配 TargetName。
Windows 凭据管理器 API 能否直接用于 .NET 6+？
能，但不是靠 CredentialManagement 这个老式 NuGet 包（它基于 COM 封装，.NET Core/.NET 5+ 上默认不支持 COM 互操作，尤其在 Linux/macOS 部署时会直接失败）。真正可靠的方式是调用 Windows 原生 CredWriteW / CredReadW 等 Win32 API，通过 P/Invoke 实现——这在 .NET 6+ 的 Windows 平台上完全可行且稳定。
关键点：必须限定运行平台为 Windows，且目标框架需为 net6.0-windows 或更高（如 net8.0-windows），否则编译报错或运行时找不到 DLL。
-
CredWriteW和CredReadW在advapi32.dll中，无需额外引用 COM 组件 - 凭据类型建议固定用
CRED_TYPE_GENERIC，避免与 Windows 登录凭据混淆 - 调用前务必检查
Environment.OSVersion.Platform == PlatformID.Win32NT
如何用 P/Invoke 安全写入密码到凭据管理器？
写入时核心是构造 CREDENTIAL 结构体，并确保密码以 SecureString 形式传入后转为 UTF-16 字符串再指针传递——不能直接用普通 string，否则明文内存残留风险高。
示例关键步骤：
- 使用
Marshal.SecureStringToGlobalAllocUnicode()将SecureString转为非托管内存指针 -
CREDENTIAL的UserName和CredentialBlob字段都需指向该指针（后者才是密码本体） - 写入成功后立即调用
Marshal.ZeroFreeGlobalAllocUnicode()清零并释放内存 -
Persist字段设为CRED_PERSIST_LOCAL_MACHINE或CRED_PERSIST_ENTERPRISE，避免用CRED_PERSIST_SESSION（重启即丢）
错误常见于忘记清零内存，或把密码误塞进 UserName 字段导致凭据不可读。
Windows 命令行编码与兼容规范。涵盖 GBK/UTF-8 编码、PowerShell/pwsh 互操作、Python/Node.js、Git 配置及代码生成规则。适用于 Windows 10/11 + MSYS2/Git Bash 环境下的所有命令行操作。
检索密码时为什么总是返回 null 或解密失败？
最常踩的坑是字段匹配不一致：写入时用的 TargetName（例如 "MyApp:ApiToken"），读取时必须**完全一致**，包括大小写和冒号。Windows 凭据管理器对 TargetName 是精确字符串匹配，不支持通配或模糊查询。
- 读取返回的
CREDENTIAL中，密码实际在CredentialBlob字段，类型是IntPtr，长度由CredentialBlobSize给出 - 需用
Marshal.Copy()拷贝字节数组，再用Encoding.Unicode.GetString()解码——不能用UTF8，否则乱码 - 如果读取返回
ERROR_NOT_FOUND (0x80090030)，说明TargetName不对，或凭据被手动删过 - 若解码后为空字符串，大概率是写入时
CredentialBlobSize设错了（应为字节数，不是字符数）
能否跨用户或跨机器共享凭据？
不能。Windows 凭据管理器凭据默认绑定当前用户 SID 和机器加密密钥（DPAPI），换用户登录或换机器就无法解密。即使设成 CRED_PERSIST_ENTERPRISE，也仅在域环境下、同一 Active Directory 域内、且启用企业密钥策略时才可能迁移——普通开发场景中基本等同于“本地独占”。
这意味着：
- 服务账号运行的后台程序（如 Windows Service）若以
LocalSystem身份运行，它看到的是系统级凭据库，和当前登录用户完全隔离 - 不要试图用凭据管理器替代配置中心或密钥管理服务（如 Azure Key Vault）
- 调试时用当前用户账户运行程序；部署到服务时，提前用对应账户写入凭据，或改用服务主体认证
最易被忽略的一点：凭据管理器不提供审计日志接口，谁读过、何时读过、读了几次——你完全不知道。
