最可靠方式是用 Regex.IsMatch 配合多组正向先行断言，如 @"^(?=.[a-z])(?=.[A-Z])(?=.d)(?=.[!@#$%&*]).{8,}$"，并提前 Trim() 处理空格和不可见字符。
用 Regex.IsMatch 判断密码是否含大小写字母、数字和特殊字符
直接看结论：C# 里最常用也最可控的方式，就是用 Regex.IsMatch 配合多组正向先行断言（(?=.*[a-z]) 这类）。它不依赖外部库，逻辑清晰，且能精确控制“必须包含”的条件。
常见错误是只写一个笼统的表达式，比如 "^[a-zA-Z0-9!@#$%]{8,}$" —— 这只能保证字符范围合法、长度够，但无法确保大小写、数字、符号**全都出现过**。用户输 8 个大写字母也能过。
- 正确写法要拆开验证：用
(?=.*[a-z])确保至少一个小写字母，(?=.*[A-Z])确保至少一个大写，(?=.*\d)确保至少一个数字，(?=.*[!@#$%&*])确保至少一个指定符号 - 开头加
^、结尾加$，避免匹配到子串（比如"abc123"里混进一个"123"就误判） - 注意转义：C# 字符串里反斜杠要双写，所以
\d才表示“数字”，\W会匹配太多（包括空格、下划线），不推荐用于“特殊字符”判断
示例：
bool isValid = Regex.IsMatch(password, @"^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%&*]).{8,}$");为什么不用 PasswordValidator 或 ASP.NET Core 内置校验
ASP.NET Core 的 PasswordValidator<tuser></tuser> 看似省事，但它默认只检查长度和唯一性，不校验字符类型分布；即使你重写 ValidateAsync，底层仍是走正则或手动遍历——没省多少事，反而多一层抽象。
更关键的是：它绑定在 Identity 框架里，如果你只是做 API 参数校验、或非 Identity 场景（比如配置文件密码、本地工具脚本），硬塞进去反而增加依赖和测试成本。
- 内置校验器对“特殊字符”的定义模糊（比如是否包含下划线、减号），而业务常需明确白名单，如仅允许
!@#$%&* - 它不暴露原始正则，调试时看不到实际匹配逻辑，出问题难定位
- 性能上无优势：正则编译一次可复用，而
PasswordValidator每次调用都可能触发额外对象分配
RegexOptions.Compiled 要不要加？什么时候加
加不加 RegexOptions.Compiled 不是“好不好”，而是“值不值”。它会让正则在首次使用时编译为 IL，后续执行更快，但启动慢、内存占用高。
如果你的密码校验是高频路径（比如登录接口每秒几百次），且正则固定不变，值得加；但大多数内部工具、管理后台、或低频注册场景，完全没必要。
- 加了之后，正则对象应静态缓存，避免重复编译：
private static readonly Regex PasswordRegex = new Regex(pattern, RegexOptions.Compiled); - 别在方法内 new Regex 并加
Compiled——每次调用都重新编译，反而更慢 - .NET 5+ 对普通正则做了 JIT 优化，未加
Compiled的性能差距已不大，优先保证可读性和维护性
容易被忽略的边界：Unicode、空格、不可见字符
用户粘贴密码时可能带首尾空格，或从某些编辑器复制出零宽空格（u200B）、BOM 头。这些字符不会被 [a-zA-Z0-9] 匹配，但会卡在 .{8,} 里让长度达标，导致校验通过却登录失败。
- 务必在正则前先
password.Trim()，否则空格算进长度但不算进字符类型 - 如果业务允许 Unicode 字母（比如中文用户名下的密码），
[a-z]就不够，得用\p{Ll}（小写 Unicode 字母），但多数系统不需要，反而增加复杂度 - 拒绝不可见字符更稳妥：在校验前加一步
password.All(char.IsLetterOrDigit || char.IsPunctuation || char.IsSymbol)，或用正则过滤掉[u2000-u206Fu2E00-u2E7Fu3000-u303F]这类区间
真正麻烦的不是写对正则，而是想清楚：你的系统到底接受哪些字符、谁在输、从哪来、输错后提示是否明确。这些比正则本身更影响体验。
