从“dddddd”看弱密码、表单校验与脏数据治理的工程实践

每次看到那种注册页面或者后台表单里躺着一串“dddddd”，我都会停下来多看两眼。它太常见了，常见到已经成了系统里的一个“通用符号”：有人拿它当测试数据，有人拿它占位，有人干脆是不小心按住了D键没松手。但你真去查的话会发现，这串纯重复字符背后，涉及的东西远比表面看起来多——它既是弱密码的典型代表，也是表单校验的漏网之鱼，还是测试人员偷懒的痕迹。这篇文章就打算围绕“为什么我们总是打出dddddd”展开，从输入习惯、系统校验、密码安全到测试工程，把这串字符里里外外拆一遍。

我在这里说的东西，写代码的、做测试的、搞安全的、运营后台数据的，应该都能找到自己熟悉的那一面。哪怕你只是个经常在网上填表的普通用户，读完也会明白为什么有些输入框会提示“不能使用连续重复字符”，以及你随手打的那几下D键到底会跑到哪里去。

1. 先搞清楚“dddddd”到底从哪来

1.1 为什么人会顺手打出“dddddd”

先聊个基础问题：人为什么要输入“dddddd”？不是每个人都抱着恶意去填垃圾数据，更多时候，这串字符的出现完全是无意识的。

我观察过不少人的操作习惯。当鼠标点到输入框、正准备填写时，手指通常停留在键盘中排队列上，手指轻轻一下落就是D键。按下一次如果觉得不合适，很多人会再按第二下、第三下，结果就是一串“dddddd”。这跟输入“aaa”“1111”“test”是同一个道理——大脑还在思考要填什么，手指已经先替你做了一次无意义的输出。

另外一种情况更典型：拿它当临时占位。比如在CRM系统里新建一条客户记录，联系电话还没问到，先填一列“dddddd”顶着，等后续拿到真实数据再回头改。这种用法在业务人员手里尤其多，他们不知道系统的字段约束，只知道表单这里必须填点东西才能保存，于是就用最快的方式凑一个值出来。

从用户体验角度说，“dddddd”的出现其实是交互设计失效的信号：输入框没有明确的占位提示、没有格式校验提示、校验失败后也没有清晰的报错文案，用户只能凭直觉硬填一个能过系统这关的值。真正需要解决的，不是用户为什么填“dddddd”，而是为什么系统能接受它。

1.2 数据后台看到“dddddd”意味着什么

站在后端数据视角看，一行“dddddd”往往是脏数据的起点。以我做过的一个用户画像项目为例，清洗数据时发现“dddddd”出现在以下字段的频率有多高：昵称、城市、公司名、备注、甚至是手机号一栏。手机号填“dddddd”的人虽然不多，但只要系统允许这一栏为空、用户又能无限制输入任意字符，这个坑就一定会被踩。

从数据清洗角度，这种值很讨厌。它不仅没有任何业务含义，还会污染统计口径。比如运营统计“华东区客户数量”时，如果有一批记录的城市字段是“dddddd”，这批数据要么被单独排除，要么会被当成一个独立的城市参与聚合，直接影响报表结果。更麻烦的是，这种脏数据的识别成本通常很低，但清理成本高：你得写规则去匹配、人工确认哪些是真实用户的疏忽、哪些是测试数据。

所以很多系统在设计字段时会刻意做一层的兜底防护。你可以把它理解成“系统级免疫”：不允许用户一上来就提交纯重复字符，从源头上减少脏数据的产生。至于这个免疫怎么实现，后面我会展开讲。

2. 弱密码与重复字符：藏在简单输入里的安全风险

2.1 六连D密码为什么那么容易被破解

“dddddd”另一个常见的身份是弱密码。我见过有同事用这种密码做测试账号，也见过真实用户把它当正式密码用。聊到安全这个角度时，问题就不一样了——它不仅仅是脏数据，而是一个实打实的安全漏洞。

密码学上有一个概念叫“密码空间”。简单说，就是尝试破解一个密码时，所有可能组合构成的空间大小。一个只有26个小写字母、且密码长度为6的密码空间，大小为26的6次方，也就是3.08亿种组合。听起来很多，对吧？但现代设备每秒可以做的猜测次数远超这个数。我还专门写过一个小脚本做过本地测试，一台普通笔记本CPU单线程跑MD5哈希，每秒能算几百万次。如果攻击目标根本不需要猜全26个字母，只需枚举“同一字符连续重复6次”这种模式，字典里直接放几条规则秒过。

更核心的问题在于，“dddddd”属于典型的键盘序列。很多密码破解工具在进入暴力破解之前，会先跑一遍“常见弱密码字典”，这类字典集合了历年泄露数据里出现频率最高的密码，而连续重复字符一定在其中。换句话说，攻击者甚至不用什么复杂策略，拿字典一跑就中。

2.2 密码策略是如何挡下这类输入的

正规系统在密码注册环节通常会加两道限制。第一道是“复杂度规则”：要求大小写字母、数字、特殊字符里的至少三种，且密码长度最少8位。第二道是“黑名单规则”：禁止纯数字、禁止键盘顺序字符（如abcd、qwer）、禁止连续重复字符（如aaaaaa、111111、dddddd）。

第二道规则的实现原理，是正则表达式加逻辑判断。以“连续重复字符”为例，系统会扫描用户提交的密码，一旦发现有连续三个字符完全相同，就直接打回。为什么是三个而不是六个？因为多数合法密码中也可能出现两个重复字符，比如“passssword”这种，但三个连续相同字符的组合已经属于高度可疑。当然，不同系统的阈值设置不同，有的更严，两个相同就拦截，有的更宽，四个才动。

我在实际配置过这类密码策略后有个体会：规则设计最容易翻车的地方是矫枉过正。真有过例子：用户取了个名字叫“lilyyy”，密码里想带一点个人标识，结果被连续三个y的规则拦住了。他打电话来投诉，说“我起名就是这样的”。这类误伤场景不是说完全无解，而是在校验规则里增加一个“命中后人工复核”的层级，或者允许用户在提示文案中看到具体原因，而不是看到一句冷冰冰的“密码不合规”。

3. 系统该怎么识别和拦截“dddddd”

3.1 前后端校验的完整链路

从工程实现角度看，拦截“dddddd”这类输入需要前后端配合，不能只在一端做。

前端拦截的目的，是在用户还没提交之前就提示他“你这串值不合理”，体验最好。做法是在表单组件上挂监听事件，当用户输入完、失焦或点击提交时，跑一遍校验逻辑。最简单粗暴的做法是正则匹配：/^(.)\1{2,}$/意思是捕获任意一个字符，然后看后面是否连续重复两次以上。如果整串输入都由同一个字符构成，就命中拦截逻辑。

但前端校验只是第一道门，真正决定数据是否能入库的是后端校验。因为前端代码运行在用户自己的浏览器里，随时可以被绕过：直接禁用JS、修改请求参数、用脚本调接口，都能把“dddddd”直接发给服务器。后端校验收到的参数必须当成“不可信输入”来对待，这一点是写服务端接口的基本素养。如果后端只依赖前端过滤，数据库里早晚会躺进各种各样的垃圾数据。

我当时做网关参数校验时，后端策略一般分三层：第一层是“黑名单匹配”，专门匹配全重复字符、纯数字、键盘顺序等；第二层是企业自定义规则，比如业务字段不允许出现“test”“dummy”“dddddd”等特定值；第三层是“白名单逻辑”，针对具体字段的数据类型，比如邮箱必须是合法格式、手机号必须符合号码规则。

3.2 正则与规则引擎怎么设计

聊到具体设计，总得给点能直接抄作业的示例。假设你是个后端开发，现在要写一个校验工具，拦截掉“dddddd”“aaaa”“1111”这类输入，给你几条可落地的规则。

先定义第一步的检测逻辑：判断字符串是否由单一重复字符组成。核心正则如下：

import re def is_all_repeated_char(s: str) -> bool: return bool(re.fullmatch(r"(.)\1{4,}", s)) # 5个及以上的相同字符

这一步抓的是“aaa”“bbb”这类全重复。第二步是键盘顺序检测，比较常见的是检测键盘位置相邻连续输入，比如“qwerty”“asdfgh”。这个正则写起来比较细，我喜欢直接维护一份已知模式列表，涉及键盘顺序规则时用字符串匹配代替正则，运行效率更高：

keyboard_patterns = [ "qwertyuiop", "asdfghjkl", "zxcvbnm", "qwerty", "asdf", "zxcv", "123456", "654321", ] def contain_keyboard_sequence(s: str, min_len: int = 5) -> bool: lower_s = s.lower() return any(pattern in lower_s for pattern in keyboard_patterns if len(pattern) >= min_len)

第三步是组合判断。对于密码字段，检测到全重复字符或键盘序列后直接拒绝；对于普通字段，比如昵称、地址，全重复字符只会给个“请填写有效信息”的提示，不至于一刀切。因为昵称偶尔真有只叫“00”的用户，但绝不会有叫“dddddd”的正常用户。

3.3 容易误伤的情况与解法

我做了这么多年输入校验，遇到最大的一个坑就是：规则越严，误伤越多。

举一个我自己踩过的例子。有一次负责电商订单的收货人信息校验，为了对付垃圾数据，加了一条规则：收货人姓名不允许连续三个相同字符。上线第二天就被客服同事找上门，说一堆用户下单失败。调研发现，很多用户的真实姓名里就有连续重复字，比如“祁朵朵”、“李小亮”、“王芳芳”，还有人故意在备注里写“请放快递柜”。这个规则直接影响了好几个真实订单。

从那以后我对校验规则的态度变成了“分层级”：与安全相关的字段（密码、手机号、邮箱）严格校验；与真实信息有关的字段（姓名、地址）做宽松匹配，优先采用“排除法”，而不是“回收法”。校验目标不是把所有可疑数据都干掉，而是把明显不合理的数据拦在外面。对“dddddd”这类输入，宽松匹配的核心逻辑其实就是一句话：它是否是“全串重复”——是，就拦；不是，就放。

4. 测试场景里的“dddddd”：填假数据的学问

4.1 随手填假数据的成本有多高

聊完系统怎么拦截，再说说制造这些数据的源头之一——测试。

做功能测试的时候，大家都有过这样的经历：页面上一堆必填项，手机号没有合适的测试数据，姓名随便写，公司邮箱也不在手边，于是每个人都熟练地在键盘上敲下一串“dddddd”。这个操作本身没问题，因为它快速、无害、能帮我们验证功能是否能跑通。真正的隐患是，测试数据没清理，带着“dddddd”的假记录流进了生产库。

我自己就见过一次特别头疼的事故。某系统从测试环境同步到生产环境时，配置脚本漏写了清理步骤，结果线上客户表里多出两条手机号为“dddddd”的订单记录。销售打电话回访时，客户说根本没见过这个订单。整个事件的排查成本非常高，因为要追溯数据来源、要修改关联订单状态、还要确定后续的同步脚本加上过滤条件。

所以测试环节，我现在的团队有一条明确规定：测试环境要填假数据可以，但假数据必须“看起来像真的”，比如姓名填“测试甲A”、手机号填“13800000001”，邮箱填testa@example.com。这类数据容易识别，又不会撞上真实用户信息，后续清理脚本一条正则就能筛干净。

4.2 必知常见问题速查

最后整理一份实际工作中经常遇到的“dddddd”相关问题速查表，都是能直接落地的经验。

做一个经验上的收尾。不管你是开发者、测试还是产品经理，下次看到“dddddd”的时候，建议你想一下它为什么会出现。如果是系统没拦住，去修校验；如果是用户不知道为什么填，去改提示语；如果是测试数据没清干净，去查同步流程。这串字符是一个很小的细节，但它往往能暴露出产品链路里比较深的一个问题。

我个人实际处理这件事时，更习惯在一个易被忽略的环节着手：别只想着怎么拦截，还要想想怎么分析。我在数据侧加了道程序，凡是看到“dddddd”这类全重复值就自动打标，标记进监控报表，每周看一次数量变化。这个习惯坚持一段时间后，不同环节中的重复输入问题就逐渐现形了——校验规则什么时候变严格了，测试数据清理是不是偶尔漏了一步，全都一目了然。处理“dddddd”这件事，本质上不是在为一个奇怪的字符串操心，而是在为系统输入质量的底线做一次体检。