我接到的那个项目工单标题是一串连续二十多位的“1”1111111111111111111111。项目正文是空的关键词是空的摘要描述也是空的。当时我的第一反应是系统创建工单时出了bug把默认值带进来了又或者是谁手滑在标题栏里按住了键盘。后来跟运营同事一聊才知道这串“1”是我要处理的那批数据的样本——用户备注字段里出现了一堆连续重复的数字1他们怀疑是刷单、灌水或者系统导入异常于是把这串“1”直接复制成了工单标题。这个场景听起来很荒唐但实际工作中很常见。越是没有信息的项目越可能藏着一个具体的业务痛点。这篇文章我会完整复盘从一条只有占位符标题的工单出发怎么把它做成一套“重复字符/占位符脏数据识别”的校验方案。内容会覆盖需求澄清、技术选型、前后端代码落地、上线后踩过的坑以及最终如何沉淀成数据质量规范。适合后端开发、前端开发、数据开发、质量测试和需要跟“脏数据”长期斗争的技术PM阅读。1. 接到一个全是“1”的工单先别急着写代码把空信息当线索1.1 那个看似乱码的项目名其实是业务样本先说清楚这串“1”是怎么被当成项目标题的。运营同事在后台导出一批用户备注做内容抽检发现不少备注形如“111111111111”“啊啊啊啊啊啊”“testtesttest”。他们想提一个需求让系统以后能自动拦截这类没意义的输入但又不知道该怎么描述就在工单标题里粘贴了其中一条样本数据正文和关键词都没填。换句话说这不是手滑这是“用数据本身代替需求描述”。在我这些年处理工单的经验里这种“以样本当标题、以空白当正文”的提交方式比看上去要普遍得多。业务方不是不想把需求写清楚而是他们自身也说不清技术语言。我给你一串“1”意思是“你去看这玩意儿有问题帮我干掉它。”如果你只是机械地写个^1$的正则把连续1干掉那后续一定返工因为明天会出现“啊啊啊啊”后天会出现“abcabcabc”。所以收到这种工单第一步永远是搞清楚这个“1”是从哪个业务场景来的出现在哪个字段出现频率多高影响是什么我后面会详细说怎么问但这里先记住一个原则工单里的每个空白都是需求上下文的一部分。空白不代表没信息它代表信息在别处需要你去捞。1.2 在信息真空里问对三个问题我处理这个工单时约了运营和客服各聊了二十分钟。没有一上来就问“你们要什么功能”而是先问了三组问题第一问谁需要这个能力答案是运营内容审核组和客服团队。他们每天要处理大量用户提交的备注、昵称、收货地址里面掺杂着乱按键盘产生的垃圾内容。以前的处理方式是人眼扫效率极低而且靠自觉不同人判断标准不一致。第二问这些数据出现在哪些字段这个问题特别关键。同样的“111111111111”在备注字段出现大概率是垃圾输入在手机号字段出现可能是测试环境的数据在证件号字段出现反而可能是一套脱敏后的测试值不一定是脏数据。不同字段对“脏”的定义完全不同必须分开配置。第三问期望的处置动作是什么是要拦截用户提交还是只贴警告标签还是事后批量清洗这是一个影响架构的问题。线上拦截是入口控制性能要求高事后清洗是出口治理可以接受复杂算法而只打标签则涉及数据存储结构。运营团队的诉求是“两步走”先在提交入口拦住明显垃圾再把已经进库的历史脏数据清洗出来。问完这三个问题信息真空基本就填上了。这件事的实质不是“删除连续1”而是“识别重复字符型占位符并分级处置”。如果我在第一天就闷头写正则后面大概率要推翻。1.3 为什么定性为“占位符/重复字符脏数据识别”把需求从“去掉连续1”抽象成“重复字符脏数据识别”这一步是整套方案能否复用的分水岭。连续十几个“1”只是占位符类脏数据的一种。真实业务里我见过这些变体同一字符重复型111111、qqqqqq、。。。。。。。键盘顺序型qazwsx、123456、zxcvbnm常见测试语型test、测试、asdf、abcdefg拼音乱按型dsadsadsa、jkljkljkl无意义复制型啊啊啊啊、嘿嘿嘿嘿、哈哈哈哈这个要看场景有时是真实情绪表达如果方案只盯着“连续1”那今天上线的功能明天就失效。因此我倾向于把这类问题统称为“低信息量文本识别”在技术上可以拆成三个层次字符重复度检测、模式复杂度检测、黑名单兜底。第一层抓“111111”第二层抓“abcabcabc”“12121212”第三层抓“test”“asdf”这类固定套路。这样定性之后技术方案就不是一个正则而是一套可以插到任意表单和接口里的校验组件。它能复用到昵称、备注、收货地址、企业名称等多个字段上。这也是为什么我建议你在接下这种“信息真空”项目时不要急着实现标题字面意思先花半天把问题重新定义一遍。2. 检测“连续同一个字符”的四种技术路线与选型对比2.1 正则表达式最直接但容易被绕过最直观的做法是正则。拿 JavaScript 举例匹配“整个字符串由同一个字符重复组成”可以这样写const isRepeatedChar (str) /^(.)\1$/.test(str);在 Python 里也类似import re def is_repeated_char(s: str) - bool: return bool(re.match(r^(.)\1$, s))这个正则的意思是开头捕获任意一个字符(.)然后\1引用这个字符表示至少再重复一次^和$保证只能是由这一个字符组成的字符串。比如111111111匹配111222不匹配。它的问题也很明显只能抓“同一个字符连续重复”这一种模式。12121212这种两个字符交替的它抓不到abcabcabc这种短模式重复的它也抓不到。而且如果后续要扩展规则比如“两个字交替”“三个字循环”正则写起来会越来越长最后变成一团没人敢动的面条代码。正则还有一个隐患叫 ReDoS正则拒绝服务攻击。如果一个表达式写成^(.*a){20}$这种嵌套回溯的形式在极端输入下会吃掉大量CPU。^(.)\1$本身回溯很少相对安全但团队如果管理不好正则库长期看会有风险。所以我的建议是正则适合在确定字段、固定模式时做第一层快速筛查但不适合作为唯一方案。2.2 字符串去重后的长度判断简单粗暴性能最优比正则更简单粗暴、也更稳健的方案是把字符串拆成字符集合看集合里是不是只有一个元素。JavaScript 一行就能完成const isRepeatedChar (str) new Set(str).size 1;Python 也几乎一样def is_repeated_char(s: str) - bool: return len(set(s)) 1这个方案背后的原理很简单Set天然去重如果字符串里的字符全部相同去重后集合大小必然是 1。别小看这个看似“不聪明”的方案它在绝大多数场景下比正则更可靠。一来它不需要维护任何字符表中英文、数字、标点、emoji 都能处理二来没有回溯问题时间复杂度是 O(n)性能极稳三来它天然支持“任意字符重复”不限于数字1。上线至今这是我最常用也最推荐的第一层校验。当然它也有自己的边界new Set()这种全角字符和1212半角字符混排时集合大小是 2不会被标记。可是121212这种交替重复集合大小是 2也不会被标记。所以去重长度判断只负责“整串单独重复”这一类更复杂的模式检测要交给熵或压缩率方案。2.3 信息熵与压缩率从统计学角度识别“无聊”的字符串如果想把检测能力从“全是1”扩展到“重复模式”可以引入信息熵。香农信息熵衡量的是字符串的不确定性如果字符串里只有一个字符不断重复信息熵就是 0如果字符种类增加、分布更均匀熵就更大。Python 计算归一化信息的代码很简单import math from collections import Counter def normalized_entropy(s: str) - float: if not s: return 0.0 freq Counter(s) n len(s) entropy -sum((count / n) * math.log2(count / n) for count in freq.values()) max_entropy math.log2(max(len(freq), 2)) return entropy / max_entropy if max_entropy else 0.0这个函数会返回一个 0 到 1 之间的值。归一化熵越接近 0说明字符串越“单调”接近 1说明字符分布很均匀。以11111111为例归一化熵是 0以abcabcabc为例字符只有 a、b、c 三种但每种出现次数相同熵也不算高明显低于一段自然语言文本。更粗犷一些的办法是用压缩率。把字符串丢给 zlib压缩后的长度和原始长度的比值越小说明这个字符串的重复度越高import zlib def compression_ratio(s: str) - float: if not s: return 1.0 original len(s.encode(utf-8)) compressed len(zlib.compress(s.encode(utf-8))) return compressed / originalaaaaaaaaaa压缩后很小比值极低一段正常的随机备注压缩后比值更高。这个方案的好处是几乎不用维护规则坏处是计算成本比Set高了一个数量级。所以熵和压缩率更适合离线批量清洗不适合在用户输入的每一个字符上实时跑。2.4 黑名单匹配兜底业务规则字符重复和低熵能解决大部分“机器生成”的垃圾输入但还有一种情况是“人肉输入”的常见测试语比如“test”“测试”“asdf”“qwerty”“嘿嘿嘿嘿”。这些字符串的熵不一定低也没有明显的重复结构只能靠黑名单。黑名单方案本身没什么技术含量但工程上需要设计好不能把黑名单写死在代码里否则每发现一个新词都要发一次版。我的做法是维护一张字典表至少包含这些字段字段说明示例pattern要拦截的原始文本111111type类型重复字符/键盘序列/测试语keyboard_seqfield_scope生效字段范围*表示全部remark,nicknameaction处置动作拦截/警告/仅记录blockenabled是否启用truecreator维护人ops_zhangreason添加原因用户反馈刷单备注黑名单的价值不在“拦截率”而在“兜底”。它是重复字符检测、熵检测做完之后最后一张网。任何检测算法都无法覆盖所有业务奇葩输入黑名单提供了一个快速响应机制运营今天反馈一个新词管理员往表里插一条数据5分钟内生效不需要等研发排期。2.5 最终选型分级组合策略先快后准我从一开始就没打算在四种方案里单选一个而是按“在线快路径”和“离线准路径”做了分级组合。在线校验路径也就是用户提交接口里跑的采用的是Set去重长度判断 黑名单快查。这两步都是毫秒级不引入复杂计算。Set负责抓“整串是一个字符重复”的机器行为黑名单负责抓“test”“111111”等业务沉淀。对于没有命中但熵值可疑的内容在线链路不急着判死会打上一个“待人工复核”标签。离线清洗路径也就是每天晚上跑批处理历史数据时才会用上归一化熵 压缩率 模式检测。这些算法可以容忍几百毫秒甚至几秒的计算时间可以处理上百万条存量数据生成一份“疑似脏数据报告”再让运营逐条确认。为什么要分级因为在线场景的错误判定代价太高宁可漏判不要误杀离线场景有充足时间做更精细的分析宁可多捞一些可疑样本也不要放过。这两者的目标天然不一样。选型表格我放在这里方便你直接抄方案识别能力性能误杀风险适用场景正则^(.)\1$单字符连续重复极快中固定字段第一层过滤new Set(s).size 1整串单字符重复极快中低在线接口通用检查归一化熵低复杂度文本较慢低离线数据扫描压缩率高重复度文本较慢低离线辅助判断黑名单固定套路词极快需人工维护所有链路的兜底3. 代码落地一个可以嵌入任何表单的“全1检查”模块3.1 前端校验用户输入时实时拦截前端校验的核心作用是“体验拦截”让用户刚输入完就知道这段内容是无效的而不是等服务端返回一个“输入无效”的错误。我先写了一个纯函数复用性优先const normalizeFullWidth (str) str.replace(/[\uff01-\uff5e]/g, (ch) String.fromCharCode(ch.charCodeAt(0) - 0xfee0) ); function isLowQualityInput(rawValue) { const value normalizeFullWidth(rawValue).trim(); if (!value) return false; if (new Set(value).size 1) return true; if (value.length 4 /^(.)\1{3,}$/.test(value)) return true; return false; }normalizeFullWidth负责把全角字符转成半角防止“”绕过检查。new Set(value).size 1是主检查只要字符串里只有一个唯一字符就判定为低质量。第二行^(.)\1{3,}$是为了兼容“前面有正常文字后面突然跟了一大串重复字符”的情况比如“哈哈哈111”这种。但前端单独用这个函数还不够。用户可能输入“1111 1111”中间有空格所以trim()只去了首尾空格中间空格会导致Set大小变成 2从而漏判。实际场景里我会再加一步把中间空格全部去掉再判断const compactValue value.replace(/\s/g, ); if (new Set(compactValue).size 1) return true;前端拦截函数挂到输入框的blur事件或防抖后的input事件上。提示语也要写得有人情味比如“这个名字看起来像重复占位符请重新填写”而不是冷冰冰的“格式错误”。需要特别说明前端校验永远只是体验层不能作为安全边界。因为用户可以绕过页面直接调接口所以服务端必须再做一次完整校验。3.2 后端兜底服务端REST API校验后端这边我把它做成了一个公共校验组件而不是在每一个业务接口里复制粘贴。用一个 Python FastAPI 示例来演示from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() def normalize_full_width(value: str) - str: return .join( chr(ord(ch) - 0xfee0) if \uff01 ch \uff5e else ch for ch in value ) def check_low_quality(value: str) - dict: normalized normalize_full_width(value).strip() compact normalized.replace( , ) if len(compact) 0: return {block: False, reason: } if len(set(compact)) 1: return {block: True, reason: REPEATED_CHARACTER} if len(compact) 4 and compact in BLACKLIST: return {block: True, reason: BLACKLIST_MATCH} return {block: False, reason: } class UserRemarkRequest(BaseModel): remark: str app.post(/api/v1/remark) def submit_remark(req: UserRemarkRequest): result check_low_quality(req.remark) if result[block]: raise HTTPException(status_code422, detailresult) # 继续正常业务处理 return {code: 0, message: ok}这段代码里的BLACKLIST是一个从数据库定期加载的集合不是写死的常量。业务侧可以通过一个管理接口增删每次增删后主动刷新内存缓存不用重启服务。错误码设计很关键。我不建议所有校验失败都返回同一个INVALID_INPUT否则运营排障时根本分不清是手机号格式错还是备注是垃圾内容。我的做法是返回结构化错误码REPEATED_CHARACTER表示重复字符BLACKLIST_MATCH表示命中黑名单LOW_ENTROPY表示低信息量。这样前端可以针对不同错误码展示不同提示排障系统也能直接聚合统计。服务端校验应该放在公共校验层也就是每个 Controller 处理业务之前都会经过的那一层。如果只加到某几个接口就会出现“这个字段管了、那个字段没管”的漏洞运营迟早会带着新的脏数据样本来找你。3.3 数据清洗脚本批量修复历史脏数据入口堵住之后还得处理库里那批已经产生的历史脏数据。写清洗脚本有一个原则不要直接 delete先标记后人工复核。因为自动判断一定有误杀风险真删了就找不回来了。我当时的清洗脚本大体是这样import hashlib import csv def mark_dirty_data(input_file, output_file): seen set() with open(input_file, r, encodingutf-8) as fin, \ open(output_file, w, encodingutf-8, newline) as fout: reader csv.DictReader(fin) writer csv.DictWriter(fout, fieldnamesreader.fieldnames [dirty_flag, dirty_reason]) writer.writeheader() for row in reader: remark row.get(remark, ) if not remark: continue compact remark.replace( , ) if len(set(compact)) 1: row[dirty_flag] 1 row[dirty_reason] REPEATED_CHARACTER elif normalized_entropy(remark) 0.3: row[dirty_flag] 1 row[dirty_reason] LOW_ENTROPY else: row[dirty_flag] 0 row[dirty_reason] writer.writerow(row)清洗逻辑只做“标记”不会物理删除数据。运营拿到这份 CSV 后可以在后台逐条确认确认无误再批量清理。我还给每一条记录算了一个content_hash用于幂等防止清洗任务因为网络超时重跑时把运营已经复核过的数据再次标记。幂等设计很重要。我第一次跑清洗任务时没考虑这个问题任务中途失败重启结果“已处理”的一批数据被再次标记运营二次确认时差点把正常数据删掉。从那以后所有清洗任务都会在写结果前检查content_hash是否已经存在存在则跳过。3.4 性能与安全的边界校验模块上线前我还压了一轮性能。Set去重的时间复杂度是 O(n)字符串长度 100 以内基本是微秒级完全不用担心。但有几个边界必须提前防住超大输入如果接口接收一个几十KB的备注字段Set和正则都还好但压缩率检测会明显变慢。所以在线链路上必须限制输入长度超过 500 字符直接走“待人工复核”不做复杂计算。正则回溯虽然^(.)\1$安全但如果团队里有人后续改成^(.?)\1$这类表达式遇到长字符串可能触发回溯性能问题。所以正则方案统一封装在组件里业务侧不直接写正则。编码与组合字符用户输入“e\u0301”e加重音符号视觉上是“é”码点上却是两个字符。Set会把它当成两个不同字符导致“看似重复实际不重复”的判断偏差。好在这个场景在中文业务里很少见但如果你做国际化需要引入Intl.Segmenter按字素拆分。全角与半角全角数字“”和半角数字“11”码点不同Set会认为是2个不同字符。所以我在组件入口统一做全角转半角这个步骤不能省。性能和安全边界本质上是一件事校验组件是你系统暴露给用户的第一个门卫门卫不能因为检查太认真把大厅堵死也不能因为流程太粗糙放人乱闯。4. 上线后踩过的坑误杀、绕过与冷启动4.1 坑一把“证件号”“银行卡号”误判为脏数据校验模块上线第二天客服就收到一个合作方的投诉他们上传的一批证件号备份被系统拦截了。我查了一下日志发现这批数据的证件号经过脱敏后长这样111111111111111111。这明显是测试环境导出的数据但合作方把它当成线上真实数据传了上来。问题出在哪我们的校验组件没有区分字段类型对证件号、银行卡号这类“允许测试值/脱敏值”的字段也都启用了重复字符检查。这类字段的业务特征和备注完全不一样它们的“全1”不代表用户乱填反而可能是脱敏算法把真实值替换成了固定占位符。修复方案是引入字段级别配置。我在规则表里加了一个field_scope字段只有被纳入校验范围的字段才会执行检查。比如remark、nickname、address启用严格模式id_card_number、bank_card默认只记录不拦截。上线前我忽略了“同一套校验规则不可能适配所有字段”这个基本事实被现实狠狠教育了一次。4.2 坑二Unicode全角字符和emoji的干扰第二轮问题来自 Unicode。有人用全角数字“”提交备注我们的前端normalizeFullWidth做了转换能拦住但如果用户直接调 API绕过了前端后端也会转半角所以全角这关过了。真正让我头疼的是 emoji。用户输入“”时new Set()在大多数现代 JavaScript 引擎里结果是 1因为 emoji 被当作单码点字符串存储能正常识别。但有些 emoji 是组合序列比如“”这个家庭 emoji它实际上由多个码点组成。如果用户重复输入这个组合 emojiSet会把多个码点拆开数结果不等于 1从而漏判。这种场景没那么常见但确实不好处理。我最终把前端的判断从new Set(value)改成Array.from(value)然后再做去重。Array.from能按码点切分避免代理对拆碎问题。至于字素级别也就是真正意义上“用户感知的一个字符”前端可以用Intl.Segmenter处理但那会带来额外兼容成本目前只在离线清洗脚本里用了。4.3 坑三攻击者绕过——连续字符加空格/换行上线第三周运营反馈又出现了一批“1111 1111”的备注。我看到Set去重结果不是 1当场意识到问题用户加了空格把连续字符拆开了。攻击者或者乱填用户根本不需要什么复杂手段只要在每个字符之间插入一个空格就能让我们的“去重判断”失效。修复很直接在校验前先移除所有空白字符包括空格、制表符、换行符。但也要注意移除空白后再校验会影响中文文本比如“大家好 大家好 大家好”去掉空格后变成“大家好大家好大家好”虽然Set大小不是 1但低熵算法会把它识别出来可能误杀真实表达。所以在线链路我只对“重复字符型”移除空白对“低熵型”保留原始空格计算。这种绕过方式也给团队提了个醒攻击者永远会找最容易绕过的口子。你不能只在规则层面打补丁最好在数据接入层就做归一化处理例如入库前统一把全角转半角、把连续空白折叠成单个空白从源头减少脏数据变体。4.4 坑四历史数据清洗的幂等性前面提到清洗脚本要加content_hash做幂等这里我把具体问题展开讲。第一次清洗跑批时我把“疑似脏数据”全部标记然后让运营在后台人工勾选删除。运营处理到一半批处理任务因为数据库连接超时中断重启后从头开始跑。没有幂等控制的情况下之前已经标记过的记录重新进入输出文件运营为了不误删只能把整个文件再人工过一遍浪费了小半天时间。后来我换了个做法清洗任务开始前先对每一条原始记录计算md5(content)利用这个哈希值作为唯一键。任务重跑时先查一下结果表里是否已经存在这个哈希存在就直接跳过。同时已标记记录在写入前还会带上cleaned_at时间戳运营能清楚看到哪一批是这次新扫出来的哪一批是上次遗留的。这里还有个实践经验清洗任务尽量做成“生成报告”而不是“自动修改”。把所有判断结果写进一张独立的结果表运营确认后再执行UPDATE或DELETE。这样即使判断逻辑有问题影响范围也只在报告层不会污染线上数据。5. 从“一串1”到一套数据质量管理规范的复盘5.1 入口防错与出口清洗的配合这个项目做到后半段我越来越意识到单个校验组件只是解决了一个点真正需要的是把数据质量治理的链路串起来。我现在复盘这套方案时会把整个脏数据治理拆成三道防线第一道防线是前端拦截负责在用户输入那一刻给出即时反馈让正常用户改正让灌水用户觉得麻烦。第二道防线是后端校验负责在所有入口接口执行不可绕过的规则包括重复字符、黑名单、限流策略这里要考虑性能但不能为了性能牺牲覆盖度。第三道防线是离线清洗负责对存量数据做定期扫描利用熵、压缩率、模式检测等更重的算法把历史遗留的脏数据挖出来生成报告供运营确认。三道防线层层递进每一道的目标、算法、性能要求都是不一样的。前端拦截可以宽松一点误判顶多让用户换个表达后端校验一定要严谨避免误杀正常数据离线清洗要尽量全量覆盖宁可多标记一些可疑样本也不要放过漏网的垃圾数据。如果只做其中一道都会出现“拦住了新的、旧的一堆”或者“旧的清了、新的又进”的尴尬局面。5.2 占位符字典的持续维护黑名单字典不是建完就完事的它会随着业务形态变化不断膨胀。运营每天都会看到新的脏数据样本如果每个样本都要走版本发布流程那这个系统的响应速度就太慢了。我的方案是给运营侧开一个管理后台让他们自己维护字典但加了审核和生效机制。一张维护周期表可以说明这个问题环节周期负责角色动作脏数据样本收集每周运营/客服提交新发现的可疑输入字典增删随时运营管理员在管理台增删黑名单词标记原因命中率回顾每月数据分析统计各词条命中量清理低效或误杀词条全量扫描每季度研发重跑离线清洗任务验证新规则有效性字典维护最大的风险是“误杀膨胀”。比如某段时间“哈哈哈哈”被当成无意义内容加入黑名单结果电商大促时用户都在晒单“哈哈哈哈哈到货了”被拦了一大片。所以字典里的每一个词条都要带生效范围和生效原因并且定期回顾命中率。连续三个月零命中的词条自动进入“待确认下线”状态避免死规则长期挂在线上制造误判。5.3 这次项目给我带来的工作方式改变处理完这个“1111111111111111111111”工单我养成了两个习惯。第一个习惯是看到再离谱、再没有信息量的工单先约业务聊十五分钟。哪怕对方说不出什么技术术语只要把业务场景还原出来方案就能少走一半弯路。第二个习惯是任何校验规则都必须可视化。我给运营做了一个拦截日志视图展示每天拦截了多少条、每个规则的命中率、每个字段的拦截分布而不是让规则成为一个黑盒。业务方看得到效果才愿意持续维护字典看不到效果就会觉得这个系统没用又把问题绕过系统来问你。说到底这一串“1111111111111111111111”不是垃圾它是一个信号业务里有数据质量问题而你恰好有机会从源头把它堵住。把它当成一行需要删除的数据你只能写一个删除脚本把它当成一个数据质量治理的入口你就能沉淀出一套可复用、可维护、可扩展的规则体系。我现在负责的每个新项目都会在启动阶段优先梳理“哪些字段允许什么、不允许什么”把脏数据拦截在入口而不是等它污染报表再回头清洗。最后再分享一个小技巧如果你也遇到了这类只有占位符标题的项目别急着写代码先把样本数据保存下来。它们是最好的测试用例。等方案上线后你把历史样本重新跑一遍能直观看到规则的覆盖率和误杀率。这比任何文档都能说服业务方——你确实把他们的“一串1”接住了。