Random.Shared生成随机字符串最稳，适用于日志ID等非安全场景；禁用于验证码和密码；需预分配StringBuilder容量、查表取字符、避免new Random()及敏感值内存残留。
直接用 Random.Shared 拼字符最稳，不重复、不卡顿、不踩种子坑——但验证码和密码不能这么干。
用 Random.Shared 快速生成普通随机字符串
适用于日志 ID、临时缓存键、非安全场景的标识符。.NET 6+ 可直接用，线程安全，不用自己管单例。
- 别再每次 new
Random()：短时间高频调用（比如循环里）大概率产出相同序列，因为系统时钟分辨率不够 - 字符集建议用
char[]而不是string[]：避免反复装箱和内存分配，new Random().Next(0, chars.Length)查表更快 - 长度超过 1024 时，不要拼接字符串：用
StringBuilder预分配容量，否则 GC 压力明显上升
示例：
private static readonly char[] _chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789".ToCharArray();
public static string GenerateToken(int length)
{
var sb = new StringBuilder(length);
for (int i = 0; i < length; i++)
sb.Append(_chars[Random.Shared.Next(_chars.Length)]);
return sb.ToString();
}
验证码必须避开 Random 类
验证码本质是“人可读、机器难猜”，但更关键的是：不能被预测。用 Random 或 Random.Shared 生成的序列，在请求头、时间戳、进程启动时间已知的前提下，可能被回溯还原。
- 必须用
RandomNumberGenerator：它调用 OS 底层熵源（如 Windows 的BCryptGenRandom），输出不可预测 - 别手写 base64 编码逻辑：直接用
Convert.ToBase64String()+ 截取，但要注意 Base64 字符含+、/、=，网页传输易出错；建议用 URL-safe 变体或自定义字符集 - 避免混淆字母
O和数字0、小写l和大写I：验证码字符集应显式剔除它们，比如用"23456789ABCDEFGHJKLMNPQRSTUVWXYZ"
NetxtString 扩展方法的陷阱
网上流传的 NetxtString 扩展（基于 NextDouble() + ASCII 偏移）看似简洁，实际有三个硬伤：
- 分布不均：
NextDouble()返回[0.0, 1.0)，乘以 26 后取整，首尾字符（如'a'和'z'）概率略低，中间字符偏高 - 无法控制大小写混合比例：传
lowerCase=true就全小写，但验证码常需“至少一个大写+一个数字”，这种需求它不支持 - 没处理 Unicode：若将来要加中文或 emoji，
(char)(...)强转会丢数据，而RandomNumberGenerator原生支持字节流，扩展性更好
生成密码时，长度和字符类型必须可配置
用户注册用的密码生成器，核心不是“随机”，而是“满足策略”：比如“至少 12 位，含大小写字母、数字、特殊符号各至少一个”。硬拼随机再校验重试，效率低且可能死循环。
- 先按策略强制塞入必需字符：从各子集各取 1 个，加入结果池
- 剩余长度用全集随机填充：避免某类字符扎堆或缺失
- 最后用
RandomNumberGenerator打乱顺序：不能用OrderBy(x => Guid.NewGuid())，GUID 不是密码学安全源 - 特殊符号列表别写死：不同系统对“合法特殊字符”定义不同（比如数据库字段限制、前端正则过滤），应作为参数传入
真正容易被忽略的点：生成后不做 string.Intern()，也不存静态引用——密码字符串一旦进内存，就得考虑是否被 dump 出去；敏感值建议用 SecureString（.NET Framework）或及时 Array.Clear() 字节数组（.NET Core+）。
