Console.ReadKey(true) 才能安全读取密码，因它不回显字符；Console.ReadLine() 会明文显示密码，极不安全。需手动处理退格、回车、转义键，跨平台支持差，生产环境应避免直接使用。
Console.ReadKey() 为什么不能直接用 Console.ReadLine() 读密码
因为 Console.ReadLine() 会把用户输入的每个字符都原样显示在控制台上，包括密码——这等于把密码明文打在屏幕上，完全不安全。而 Console.ReadKey(true) 的 true 参数表示“不回显”，它能逐个捕获按键却不打印，这才是掩码的基础。
常见错误现象：有人用 Console.ReadLine() + 手动替换字符串为星号，结果密码早就在屏幕上闪过了；还有人忘了加 true，按一个键就出来一个 *，但光标乱跳、退格失效、Ctrl+C 被吞掉。
-
Console.ReadKey(true)每次只读一个键，需自己拼接字符，处理Backspace、Enter、Escape是必须的 - 不能依赖
KeyChar判断退格——Windows 下Backspace的KeyChar是\u0000，得看Key属性 - Linux/macOS 终端对
Console.ReadKey()支持有限，某些环境会直接抛InvalidOperationException
怎么正确处理退格和回车：关键三步判断
用户敲 Backspace 时，你得删掉最后一个字符、把光标左移两个位置（一个删 *，一个留空格再回移）、再覆盖一次；敲 Enter 就该结束输入；敲 Escape 通常要清空并退出。漏掉任意一步，就会出现星号残留、光标错位或无法提交。
实操建议：
- 用
List<char></char>缓存密码字符，比拼接字符串更高效（避免重复分配） - 每次输出
*前，先用Console.Write("\b \b")清掉上一个（如果存在），再写新* - 检测
key.Key == ConsoleKey.Backspace，而不是key.KeyChar == '\b'，后者不可靠 - 回车后记得补一个
Console.WriteLine()换行，否则下一行提示会黏在星号后面
跨平台兼容性差在哪？Console.ReadKey() 的真实限制
这个 API 在 .NET 5+ 的 Windows 上表现稳定，但在 Linux/macOS 的终端里，它依赖底层 tty 设置，常会卡住、忽略修饰键，甚至直接崩溃。不是你代码写错了，是运行环境不支持。
使用场景提醒：
- 内部工具、本地调试脚本可用；生产环境面向多平台 CLI 工具，别硬扛，换
System.Security.SecureString+ 外部密码管理器（如dotnet user-secrets）更稳妥 - .NET 6+ 提供了
Console.InputEncoding和Console.OutputEncoding，但改编码对ReadKey行为无影响 - VS Code 集成终端、PowerShell ISE 等 GUI 封装终端，可能拦截
ReadKey，测试务必在原生cmd.exe或Terminal.app中进行
为什么不用 SecureString？它和星号显示是两回事
SecureString 解决的是内存中密码不被 dump 出去的问题，和屏幕是否显示星号完全无关。你可以用 ReadKey 显示星号，再把结果塞进 SecureString；也可以明文读取后手动转成 SecureString——但后者密码已经在内存里躺过一整段字符串了。
性能与风险权衡：
-
SecureString在 .NET Core 3.0+ 已标记为“不推荐使用”，官方建议用Memory<byte></byte>+CryptographicOperations.ZeroMemory手动擦除 - 真正该擦除的是最终密码字符串本身，不是星号缓存——那个本来就不含敏感内容
- 如果只是临时脚本、一次性工具，用
string接收也无妨；但凡涉及配置文件写入、网络传输、日志记录，就必须走零内存拷贝路径
最麻烦的其实是退格逻辑和光标定位的组合——不同终端对 \b 和 \r 的解释有细微差别，哪怕同一段代码，在 Windows Terminal 和 mintty 里表现都可能不一致。测的时候别只盯一个环境。
