正则表达式密码格式验证做法大全使用教程与实战指南实用指南
平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“正则表达式密码格式验证做法大全”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。
前言
结合项目来看，这里有你想要的正则表达式。网上这方面的内容比较分散，本文将尽量写出验证各种密码格式的正则表达式。
话不多说，直接上答案。
1种
只能由1种组成
只能由字母组成，1-9位
^[a-zA-Z]{1,9}$只能由数字组成，1-9位
^d{1,9}$只能由特殊字符组成，1-9位
^[^da-zA-Zs]{1,9}$至少包含1种
至少包含字母，1-9位
^(?=.*[a-zA-Z]).{1,9}$至少包含数字，1-9位
^(?=.*d).{1,9}$至少包含特殊字符，1-9位
^(?=.*[^da-zA-Zs]).{1,9}$2种
只能由2种组成
只能由字母、数字组成，1-9位
^(?=.*d)(?=.*[A-z])[da-zA-Z]{1,9}$只能由字母、特殊字符组成，1-9位
^(?=.*[a-zA-Z])(?=.*[^da-zA-Zs])([a-zA-Z]|[^da-zA-Zs]){1,9}$只能由数字、特殊字符组成，1-9位
^(?=.*d)(?=.*[^da-zA-Zs])(d|[^da-zA-Zs]){1,9}$至少包含2种
至少包含字母、数字，1-9位
^(?=.*[a-zA-Z])(?=.*d).{1,9}$至少包含字母、特殊字符，1-9位
^(?=.*[a-zA-Z])(?=.*[^da-zA-Zs]).{1,9}$至少包含数字、特殊字符，1-9位
^(?=.*d)(?=.*[^da-zA-Zs]).{1,9}$任意2种组成
由字母、数字、特殊字符，任意2种组成，1-9位
^(?![a-zA-Z]+$)(?!d+$)(?![^da-zA-Zs]+$).{1,9}$3种
至少包含3种
至少包含字母、数字、特殊字符，1-9位
^(?=.*d)(?=.*[a-zA-Z])(?=.*[^da-zA-Zs]).{1,9}$理解这一步时，至少包含字母、数字、特殊字符，1-9位，同时且不能连续出现3个大小连续或相同的数字(如：456、654、888)
^(?=.*d)(?!.*(d)1{2})(?!.*(012|123|234|345|456|567|678|789|987|876|765|654|543|432|321|210))(?=.*[a-zA-Z])(?=.*[^da-zA-Zs]).{1,9}$吐槽
结合项目来看，这块内容一般放在前言里的，但对于正则表达式的内容，写在上面有些多余，因为正则表达式这东西用的时候很少，一部分人可能对怎么写不感兴趣，或者要用的时候比较急，只想复制粘贴后能正常运行，我朋友就属于前两者（医生：你说的这个朋友，是不是你自己呀.jpg）。
理解这一步时，能看到这儿说明你应该没那么急，那么下面我们就来聊聊——写出满足密码验证条件的正则表达式，需了解哪些关键语法？
表格总结
| 字符 | 描述 |
|---|---|
| ^ | 匹配输入字符串的开始位置。 |
| $ | 匹配输入字符串的结束位置。 |
| * | 结合项目来看，匹配前面的子表达式零次或多次。比如，zo*能匹配“z”以及“zoo”。*等价于{0,}。 |
| + | 结合项目来看，匹配前面的子表达式一次或多次。比如，“zo+”能匹配“zo”以及“zoo”，但不能匹配“z”。+等价于{1,}。 |
| ? | 从实现思路看，匹配前面的子表达式零次或一次。比如，“do(es)?”能够匹配“does”或“does”中的“do”。?等价于{0,1}。 |
| {n,m} | 结合项目来看，最少匹配n次且最多匹配m次。比如，“o{1,3}”将匹配“fooooood”中的前三个o。“o{0,1}”等价于“o?”。 |
| . | 匹配除换行符之外的任何单个字符。 |
| [a-z] | 匹配任意小写字母。 |
| [A-Z] | 匹配任意大写字母。 |
| [a-zA-Z] | 匹配任意字母，不区分大小写。 |
| d | 匹配一个数字。等价于[0-9]。 |
| s | 落到代码里，匹配任何空白字符，包括空格、制表符、换页符等等。等价于[ fnrtv]。 |
| (?=pattern) | 实际处理时，正向肯定预查。比如，“Windows(?=2000)”能匹配“Windows2000”中的“Windows”，但不能匹配“Windows3.1”中的“Windows”。 |
| (?!pattern) | 从实现思路看，正向否定预查。比如“Windows(?!2000)”能匹配“Windows3.1”中的“Windows”，但不能匹配“Windows2000”中的“Windows”。 |
| x|y | 理解这一步时，匹配x或y。比如，“z|food”能匹配“z”或“food”。“(z|f)ood”则匹配“zood”或“food”。 |
| [xyz] | 从实现思路看，字符集合。匹配所包含的任意一个字符。比如，“[abc]”能够匹配“plain”中的“a”。 |
| [^xyz] | 在这个场景下，负值字符集合。匹配未包含的任意字符。比如，“[^abc]”能够匹配“plain”中的“p”。 |
理解这一步时，上面这些语法应该是大家最常用的、也是最基础的，但对写密码格式验证的正则表达式来说，不是最关键的。
关键是下面3套组合拳：
(?=.*x)
必须有x。
例：必须有数字——(?=.*d)，以此类推。
(?!.*x)
不能有x。
例：不能有数字——(?!.*d)，以此类推。
(?!x+$)
不能全是某一种字符。
例：不能全是数字——(?!d+$)，以此类推。
有了上面的公式，再去看前面的示例应该就比较好理解了。
落到代码里，这里有些人可能就有点疑惑了——上面的表中不是写的(?=pattern)表示在特定字符前，匹配前面的字符吗？如：Windows(?=2000)能匹配“Windows2000”中的“Windows”，怎么跟后面提到的用法不一样？
要弄明白上面定义之前，先梳理一下预查/断言的相关知识：
(?)括号里以?开头就是预查语法，?看作判断，这比较好理解；(?=)为正向肯定预查，(?!)为正向否定预查。=为肯定，!为否定，默认为正向，那反向就在中间加一个<，
即：(?<=)为反向肯定预查，(?为反向否定预查。
这里需留意：→ 为正向，←为反向，这有点像坐标轴，所以反向就用指向左的<表示就好记多了（向左向右是相较于匹配字符而言的）。- 落到代码里，预查表达式的位置不影响方向，比如：
x(?=y)与(?=y)x都为正向；x(?<=y)与(?<=y)x都为反向；但会影响光标位置，x(?=y)光标在x右边，再向右查找，(?=y)x光标在x左边，再向右查找，所以x(?=y)等价于(?=xy)x
Windows(?=2000) 能匹配 "Windows2000" 中的 "Windows"，因为它断言 "Windows" 后必须紧跟 "2000"，如果这个条件成立就匹配"Windows"。如果改为 (?=Windows2000)Windows，它就从位置0开始判断是不是"Windows2000"，如果成立就匹配 "Windows"，但前提是整个字符串以 "Windows2000" 开头。所以，当我们不在意“2000”前面有没有“Windows”，甚至不在意前面有没有字符时，(?=.*2000).*就代表必须有“2000”，也能够写作.*(?<=2000.*)。
最后
在这个场景下，之所以写这个随笔，也是由于最近在找一个密码验证的正则表达式，找了好久都没有一个满意的。搜到的文章里有示例的不够全面，或者详解部分不够针对，不符合应用场景。在看了一些资料后，终于写出了需的正则表达式，后来意识到可能大家也会遇到跟我类似的情况，所以就想挑战一下自己，算是完善自身，帮助他人，我想这也是大家写博客的初衷。
从实现思路看，总的来说，正则表达式校验密码适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。
