周玉坤举重这阵子我抽空把以前写的一个小工具重新翻出来打磨了一遍，就是标题里这个“纯HTML本地版社工密码生成器”，也叫SocialEngineeringDictionaryGenerator。说白了，它就是一个只有单个网页文件、不需要联网、不需要装数据库的密码词典生成页面，用来根据某个人公开可见的基础信息，比如姓名拼音、出生年月、手机号分段、常用网名这些，在本机直接展开出一批“大概率会被本人拿来当密码”的候选组合。
很多人一听到“社工密码生成器”就觉得是搞攻击的坏东西，这个误会挺大。我在安全测试和防护意识培训里经常要用到类似的字典，不是为了拿它去撞谁的账号，而是想验证一个问题：如果一个人习惯用姓名首字母加生日当密码，或者喜欢把手机号后四位拼在常见单词后面，那他的密码到底有多容易被枚举出来。这个工具就是干这个用的，它能在不把任何隐私信息上传到云端的前提下，把这个验证过程放在你自己的浏览器里完成。
项目是完全开源的思路，核心就是一个HTML文件加上内嵌CSS和JavaScript，没有框架、没有依赖，双击就能用。这篇文章我就把这个项目的设计思路、核心实现、实操用法和我在写它时踩过的一些坑全部拆开讲一遍，给同样有密码安全自测需求或者纯想用前端技术做点实用工具的朋友一些参考。
1. 先搞懂这个项目的真实需求和使用场景
1.1 它到底在解决什么问题
先说个真实的背景。我平时在做账号安全评估时候，偶尔会遇到客户问我：“我的密码够不够安全？”我一般是不会直接评价的，因为密码安不安全，不看长度也不看复杂度，而是看“别人能不能猜到”。
能不能猜到就有讲究了。如果你密码是“Qwer1234”，看起来又有大小写又有数字，但它其实是一个全网最常见的弱密码之一。如果换成“Zhangwei19930815”，长度不短、还带大小写和数字，看起来很强，可只要有人知道你的名字叫张伟、生日是1993年8月15日，这串密码就完全没有秘密可言。
问题的根源就在于，人是懒惰的，也倾向于用有意义的、能记住的信息来构造密码。这个“有意义的信息”往往就是自己的姓名、生日、手机号、邮箱、家人的名字、宠物的名字、喜欢的球星、常用的口头禅，再加上顶多一两次变换规则。所谓“社工密码生成器”，其实就是把人在构造密码时的这些偏好转换成规则化、枚举式的组合，形成一串候选密码列表，然后用来评估一个真实密码是否身处其中。
所以，这个项目解决的并不仅仅是一个“生成密码”的问题，它的核心价值是让用户直观地意识到：以我的公开信息为种子，机器可以用极低成本的枚举方法生成多少种可能的密码组合？如果我自己设置的密码就落在这些组合里面，那我的安全性是零。
1.2 为什么非要做成本地版，而不是在线工具
这个点是我在设计时最坚持的地方。网上类似的密码组合生成器不少见，但几乎都是在线网页，点开一个网页往里输入信息，结果就在服务器端走了一圈。先不说网站本身是否可靠，单就“输入自己的姓名、手机号、邮箱、生日”这一条，我就非常不建议把这类个人隐私数据交给任何第三方网站处理。谁也没法保证你输入的原始信息不会被留下来、被记录、被拿去二次利用。
所以这个工具从一开始就定了一个硬性标准：完全本地运行。整个项目就是一份后缀为html的纯静态文件，所有计算逻辑都用JavaScript写死在这一个文件里。当你在浏览器里双击打开这个文件时，它运行在file协议下，不发起任何网络请求，不调用任何外部接口，更不会把数据发出去。输入的信息只存在于当前页面当前时刻的浏览器内存里，关掉页面就什么都没了。
这也是为什么我把技术方案定位在“纯HTML + 原生CSS + 原生JavaScript”，不引入框架、不打包、不构建。一个文件，一个承诺：数据不出本机。如果你的使用场景比较敏感，甚至可以在断网情况下打开它，效果完全不受影响。
1.3 哪些人适合使用这个工具
从我的实际经验来看，主要会有三类人来用这个页面。
第一类是安全测试工程师。在做授权渗透测试或红队演练的时候，往往需要针对目标人员生成一份“关键词规则字典”，再交给密码喷洒或登录枚举类工具去验证弱口令。这时候本地版单文件工具非常顺手，拷到内网机器里就能用，不依赖外网，也不容易留下痕迹。
第二类是安全意识培训讲师。我在做员工安全培训时，特别喜欢在现场做一个小互动：让一位志愿者上台，输入自己的姓名拼音和出生年份，两秒钟后生成几百个候选密码，然后问大家：“你觉得用个人信息生成的密码，能算安全密码吗？”这个演示效果远比讲一堆理论要好，几乎每次都有同事听完立刻去改密码。
第三类其实是最重要的——普通个人用户，用来自查。你可以把自己的常用密码结构输入进去，看看这个密码是不是建立在公开信息之上的。如果是，其实你已经在用“谁都能猜到”的方式守护你最敏感的数字资产了。
我当然也会强调：请务必只对自己本人的信息、或你拥有明确授权和知情同意的情况下使用。用这个东西针对任何真实第三方个人制作字典，在没有获得授权的前提下，既突破道德底线，也涉及违法风险，这一点我们后面还会专门展开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心设计拆解：一个页面如何组织完整的生成流程
2.1 整体信息架构：从输入到输出的三个大区
我把这个页面拆成了三个视觉和功能清晰的大区：左侧或上方的个人信息输入区，中间的规则设置与生成控制区，以及下方的结果预览与导出区。
这个布局看似简单，实际上是有讲究的。输入区决定“种子”，也就是所有变换的原材料；规则区决定“怎么变”，控制枚举的深度和广度；结果区展示“生成物的集合”，让人对输出规模有直观把握。
输入区我划分了11个基础字段，都是现实中人们构造密码时最容易用到的基本元素：中文姓名、姓名拼音全拼、拼音首字母、出生年、出生月日、手机号、常用邮箱用户名、QQ号、英文网名、关键数字（比如纪念日），再加一个自定义关键词标签。
大多数人乍一看可能觉得字段好多，但实际用下来就会发现，这些字段基本上就是一个人在社交平台主页里能公开看到的全部画像信息。尤其是QQ号和邮箱用户名这种看起来很中性的信息，恰恰是很多人密码的主体部分。
规则区我提供了一些可勾选的变换开关和参数设置，包括大小写策略、特殊符号映射方式、把年份替换成“@”或“_”的风格等。结果区则会在生成后显示总候选数、耗时、页码状态，并提供复制结果和导出成txt文件的功能。
2.2 组合展开逻辑：枚举的核心策略
这部分是整个工具的心脏。密码之所以“能被猜出来”，很多情况下并不是因为某一个词本身太弱，而是命中了一个可穷举的组合空间。我在代码里将组合拆分成三类：基础词库构建、拼接规则枚举、简单变形扩展。
基础词库构建就是从输入的原始字段里提取出所有可用的“词根”。张伟，就会产生“zhangwei”“zw”这两个词根；出生日期为19930815，就可能产生“1993”“0815”“930815”等不同粒度的片段。这些词根是一切的原材料。
拼接规则枚举是把词根和词根之间的常见组合方式变成模板，比如“词根1 + 词根2”是一种，“词根1 + 分隔符 + 词根2”是另一种，“词根1 + 年份”又是一种。这个动作本质上是把人脑中的联想习惯形式化，因为绝大多数人的密码并不是一个随机的词，而是“对自己有意义的两段信息的简单拼接”。
变形扩展则是在词根和组合串的基础上做一些常见的字符替换和键盘习惯模拟，比如把字母“a”替换成“@”，把“s”替换成“$”，在字典单词后面强制追加“123”、“666”、“!@#”这类高频尾巴，或者把完整组合中某一个字符做大小写切换。
这三个维度每各执行一遍，输出结果量会呈指数级膨胀。
2.3 为什么选择逐条遍历而非规则树递归
在开发过程中，我曾认真考虑过要不要把所有规则抽象成一棵可以被遍历的语法树，然后通过递归枚举把结果一次性算出来。理论上树形结构会非常优雅，扩展新规则也会很方便。但后来在实际写代码时，我放弃了这种过于抽象的设计，转而采用了一种更朴素的“逐层展开 + 数组迭代”的策略。
主要原因有两条。第一，基于人与密码关系的认知模型，真正的常见密码并不会用到太复杂的嵌套规则。现实中绝大多数人就是“记忆单元A”和“修饰词B”的排列，复杂嵌套像“首字母大写 + 反转 + 键盘平移一位”已经很少见了，因为用户自己都记不住，更不会作为平时的登录密码。第二，数组迭代法更利于控制去重时机和输出排序，也方便我在中途给页面加一个“进度提示”，万一生成量太大起码可以把当前卡在哪一步显示清楚。
当然，我并没有完全抛弃可扩展性。在实际代码里，我把每一个规则类型都定义成一个独立函数，这些函数全部挂在同一个全局字典对象上。以后想新增某种变形规则，只要照着已有函数写一个，再在总流程里加一行调用就行。我自己用下来的感觉是，这种“牺牲一定的理论优雅，换取工程上的直观可控”的选择，对这个体量的工具来说反而是最合适的。
我在实际测试中一个很大的感受是：规则太多后很难判断到底哪类组合是用户真正需要的。如果一股脑全按笛卡尔积去展开，生成几百万条是分分钟的事，但里面有效命中的比率会变得非常低。
3. 核心功能实现：手写单文件生成器的关键细节
3.1 HTML骨架与表单设计要点
整个页面虽然功能上并不花哨，但在结构组织上我尽量保持清晰。首先，文件的文档类型声明和语言属性很重要，尤其要强调一下中文环境下字符集设定：
html复制<!doctype html>
<html lang="zh-cn">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>SocialEngineeringDictionaryGenerator - 本地社工密码生成器</title>
<style>
/* 页面样式全部内联在style标签里，不引用外部CSS文件 */
</style>
</head>
<body>
<!-- 表单与结果区域都在此处 -->
<script>
// 页面逻辑全部写在这个script标签里，不依赖任何外部JS库
</script>
</body>
</html>
这里我必须强调一下，charset="utf-8"是绝对不能省略的。我最早做原型时因为顺手拷了一个模板，没注意字符集设置，结果在Windows中文环境里用浏览器打开文件，所有中文字符全变成了一堆乱码，用户输入姓名的时候完全没法解析，这个问题在后面第6节会再细说。
在表单设计上，我并没有使用最传统的form元素加提交按钮模式，而是把所有input元素放在一个div容器里，按钮的click事件单独绑定在JS中。这样做有一个好处，就是避免页面发生刷新。因为我们整个应用是想保持“表单始终在当前操作状态”的体验，如果每次点按钮都走一遍form的submit动作，页面会重新加载，已填写的字段和生成的中间状态都会丢失，非常不利于反复调整参数。
每个输入字段我都在前边放置了一个label说明文字，但又不像教科书那样每个label的for属性都指向一个固定的id。在实际的页面里，这种一一对应的关系很容易在后续复制和扩展字段时漏改，从而造成点击label时焦点不到对应输入框上的用户体感问题。所以我在这个项目中采用了一个偷懒但有效的做法：直接把input包在label元素里面，不需要写for和id即可实现“点击文字聚焦输入框”的效果：
html复制<label>中文姓名
<input type="text" id="fullName" placeholder="例如：张伟">
</label>
对于出生年、出生月日这类需要数字约束的字段，我给了input元素type="number"，并设置了合理的min和max范围，防止有人填出乱七八糟的数值导致生成器算出无意义的结果。手机号字段则用type="tel"，移动端上会弹出数字键盘，算是顺手适配了一下手机使用场景。
3.2 CSS排版与交互反馈的实现思路
设计CSS的时候我是按照桌面端优先来思考的，因为平时用这个工具的场景大部分是坐在电脑前做安全分析，输出结果要复制、要存txt，用手机操作反而不方便。我设置了一组合理的默认宽度，表单区和结果区采用双栏布局在宽屏下并排展示，在窄屏或小窗口中则自动切换成单栏流式排列。
配色上我尽量克制，没有采用花哨的渐变色或深色霓虹风格，用的是一个偏“终端工具”的浅灰背景加深色卡片，强调文字用深蓝或橙色。顺便说一句，这类工具页面真的不建议做得太酷炫，长时间盯着一份高饱和撞色页面很容易疲劳，生成的字典又全是文本，本身就需要很高的专注度。
按钮的反馈状态是一个容易被忽视的点。点击“开始生成”之后，由于JS是单线程的，如果生成量一下子上来，页面可能短暂进入无响应状态。所以我做了两步缓解：第一步，点按钮后立即修改按钮文案为“正在生成...”，并给它加上disabled状态，从视觉和交互上双重告诉用户“程序正在工作”；第二步，在总循环次数较大时每隔几万次就往页面上写一次进度提示，让用户知道没有卡死。
最终的结果输出框，我使用的是textarea控件的只读模式，而不是pre或div内容展示。textarea的优势在于，它天然支持鼠标框选、Ctrl+A全选、Ctrl+C复制，这对需要把几千行候选密码复制走的场景非常重要，比div的可选性可靠得多。
3.3 JavaScript核心：词根准备与去重逻辑
在JS的开发中，最核心的一个环节是“词根准备”。每当用户点击生成按钮，我不会直接拿拼音、生日、手机号这些原始字段去套用模板，而是会先建立一个数组词根集合，对每一个输入做预处理和裁剪。
拿中文姓名来举例。如果是单名，全拼就是一个词根；如果是双名，全拼是一个词根，姓加名单个字的组合也可以拆成两个独立词根。拼音首字母在姓名上变化更多，可能是“zw”，也可能是“zhw”，还可以是全首字母“zzw”。这些词根之间存在着大量重叠，如果直接全部塞进列表中，后面每一轮组合都会产生大量重复结果，最终输出文件里满屏都是几乎相同的字符串，文件膨胀得厉害，可用性也差。
所以在词根准备完成后，立即执行一次前缀树的去重或者至少是数组的unique去重。考虑到这个工具的运行环境不需要兼容老掉牙的浏览器，我直接用Set数据结构做了过滤：
javascript复制function buildBaseWords() {
const words = [];
// 加入全拼
if (fullPinyin.value) words.push(fullPinyin.value.trim().toLowerCase());
// 加入首字母
if (initials.value) words.push(initials.value.trim().toLowerCase());
// 加入出生年
if (birthYear.value) words.push(birthYear.value.trim());
// 加入出生月日，例如0815
// ...
// 将手机号按长度切出前三位、中间四位、后四位、整体
// ...
return [...new Set(words.filter(w => w.length > 0))];
}
光有词根还不够，因为现实中很多人会在密码里使用“组合词根”。比如账号主体是“zhangwei”，但为了不重名或达到站点长度要求，他可能会写成“zhangwei123”“zhangwei2023”“zhw0815”等形态。所以我的另一个重要函数是拆分词根片段，也就是把输入值按照不同长度切分成子串，方便后边再互相拼接。
手机号是最典型的例子。一个11位手机号13812345678，在构造密码时，可能被使用的片段有完整号码、后四位5678、中间四位1234、或者前3位138加后4位5678。在准备阶段，我会按这些常见切法把手机号拆成多段并加入词根容器。
这一层准备代码实际写下来占用了整个JS文件的三分之一。我一度觉得它重复代码多，不够精炼，但在后续测试中发现，正是这些看似笨拙的预切分逻辑，大幅度减少了最终结果中低价值字符串的比例，反而让工具的命中体验更好了。
3.4 密码常见拼接与变形规则库
词根列表就绪之后，下一步是拼接规则。我在这个项目里内置了一个按优先级排序的规则函数链，按照人们日常设置密码的习惯顺序来排列，大致包括：词根本身单独作为候选；词根加年份；年份加词根；词根加手机后四位；词根加特殊符号；词根加大写首字母；词根加重复型尾巴如“123123”“666”“888”“abc”等。
这里需要特别解释一下“为什么这些规则这么土但这么有效”。曾经我做过一个小范围样本统计，在一批被公开的弱密码样本中，单纯由“姓名拼音首字母 + 生日年份或月日 + 特殊字符尾巴”构造出的密码占了相当高的比例。犯罪分子和攻击者并不比你更有想象力，他们之所以能成功，不是使用了多么惊人的算法，而是识别了“人的密码构造规律”这一确定性。所以这个工具在设计规则时，并不是要去穷举所有可能性，而是要把这些高概率的模式穷举出来。
再看变形扩展。语言习惯上，很多人会喜欢把某个字母换成长得像的符号。比如中文拼音里常见的“a”变“@”、“i”变“1”、“e”变“3”、“o”变“0”、“s”变“$”。我写了一个替换图层函数，遍历所有已经生成的候选词，把其中包含可替换字符的项再做一轮替换。但这里我给自己留了一个限制开关，默认最多做单字符替换，而不是同一词里同时把a和s全部替换掉，因为这个选项一旦打开，输出量会爆炸式增长，里面大部分结果也超出了普通人的记忆负担，反而并不真实。
大小写处理上也遵循类似原理。默认不把所有字母大写或小写各生成一遍，而是只增加一种策略：“首字母大写其余小写”。因为统计上来讲，密码第一位字母大写的习惯比把某一位改成大写要常见得多。
3.5 生成与导出：复制、下载、防止卡顿
生成按钮触发的主流程如下：先收集所有基础词根，按当前选中的规则分别调用生成函数，把得到的结果全部push到一个总数组。每追加完一个大类规则的结果，就对总数组执行一次Set去重，这个去重时机的选择是我调试了很多遍才得出的经验——如果到最后才去重，中间过程会累积海量内存占用，几十万条数据在低配机器上可能直接让标签页崩溃；但如果每生成一条就去重一次，整个时间又会成倍拉长。
最终结果展示在textarea里，并同时统计总数输出。我推荐生成结果在10万条量级以内直接展示在框里没问题，但如果超过这个量级，请切换到“仅导出不预览”模式。我专门提供了一个开关，让用户在生成前自己决定要不要把结果全部渲染到textarea里边。关闭预览之后，生成结果直接以文本文件下载，这样能避开大文本渲染导致的页面卡死问题。
文件导出我用了一个非常朴素的方案，创建一个Blob对象，再借助浏览器的下载能力：
javascript复制function downloadResult(content) {
const blob = new Blob([content], { type: 'text/plain;charset=utf-8' });
const link = document.createElement('a');
link.href = URL.createObjectURL(blob);
link.download = 'dict_' + Date.now() + '.txt';
document.body.appendChild(link);
link.click();
document.body.removeChild(link);
URL.revokeObjectURL(link.href);
}
小细节是下载的文件名上直接盖一个时间戳，这样即使多次生成同一个人的词库，也不会互相覆盖，对于需要保留多轮操作记录的场景会方便很多。
4. 实操演示：从零生成一份候选密码集
4.1 一组典型输入的生成过程
为了更直观地讲清实际操作过程，我拿一个完全虚构的例子来演示。假设用户叫李明，拼音全拼是liming，首字母是lm，出生日期是1990年5月12日，手机号是13812340001，QQ号是1234567。把这些信息填进输入框之后，我喜欢选上一组看起来最贴近现实的规则组合，不贪多，主要是检出常见遗漏。
点击生成后，工具的流程会先把“李明”“li”“liming”“lm”这些名字相关词根准备好，再把“1990”“0512”“9012”“2012”等日期切片处理好，接下来把手机号解析出“138”“1234”“0001”“13812340001”等有效部分。第三步，进入规则函数链，做单词拼接、大小写处理、字符替换和尾巴追加。
我实际演示中得到的列表开头部分会包含这样一些结果：liming、liming1990、liming1990@、Liming1990、lm123456、lm0512、123456lm、liming1234等。看到这一串输出，基本就能直观感受到这套工具在模拟一个真实账号被枚举时的压力。
在实际生成前可以留意一下右侧的候选编号总数。以这样一份简简单单的输入，在默认规则下大概能生成几千条候选。一旦我额外勾上更激进的字符替换和键盘平移规则，数量会快速跳到几万条。听起来几万条好像不多，但在配合自动化工具做高频次的密码枚举时，由姓名和生日生成的候选命中率往往高得吓人。
4.2 结果体量评估与筛选技巧
生成结果并不是越多越好，这一点我很想强调。如果你是一个安全意识培训讲师，现场演示时生成8万条候选，效果反而可能不太好。因为观众的注意力会被海量输出带走，看不到“个人规律”的核心了。
实际上在测试自己或导出给自动化工具用的时候，也需要有筛选思路。我在项目里加了一组可选的“长度过滤”和“排除纯数字”选项，可以在输出前先把低于设定长度或者没有字母参与的结果清理掉。因为很多系统现在有了基本密码策略，纯数字6位数在现实中能通过的场景已经越来越少了，保留它们只会让列表变臃肿。
还有一种筛选思路是按模板来源过滤。比如只想知道“姓名加生日”这一类会不会命中某条密码，可以在输入时只填姓名和生日。由于每个输入框都只是普通字段，用到哪几个就填哪几个，不填的留空，生成器会自动无视它们。同时我在输入框中加了一个清空按钮，方便一次只测一组维度，然后核对输出结果。
我自己最常用的验证方式是这样的：先把我自己的某个真实密码写在一张纸上，然后在生成器里填上我名字拼音和生日，生成的候选集如果包含了这个密码——那我立刻去改密码。有时候也会反过来做：先在生成器里生成一份关于自己的完整候选集，然后挑出其中我认为最像的十条，确认一下它们是否触及了我的某类行为习惯。
4.3 实际使用中要避免的几个操作误伤
我在使用和测试中遇到过一个比较常见的误操作：“一键生成”后，所有结果默认都展开在结果区，由于数量特别大，页面直接卡住，鼠标点哪儿都没反应，最后只能强制关闭标签页。如果你在生成器里填入了大量字段并把规则全选打开，几百万条候选就会出现这种状况。后面我做了改进，即便你忘了关预览，程序也会在超过规定的渲染上限时自动转为只显示前两百条，并把完整结果生成下载链接，总算是从根上解决了这个问题。
另外提醒一句，生成的txt字典文件最好不要直接丢在云盘或聊天工具里发送。它就是一份普通人信息的镜像，一旦被人拿到，知道你这些基础信息的人就可能利用它去尝试登录你的各种账号。自己测试完之后，把它删掉比较稳妥。
5. 安全边界与正确使用姿势
5.1 社工密码生成器为什么是一把双刃剑
社会工程学在安全领域既是一种被大量研究的攻击方法，也是防御者必须弄懂的思维方式。攻击者利用人的心理弱点、习惯和信任关系，诱导目标泄露信息或执行某些操作。社工字典的生成，本质上就是“把你的习惯固化成可枚举的集合”，它本身没有善恶偏向，会用的人能在几分钟内评估一个人的密码韧性，不会用的人则可能走上歪路。
正因如此，我在页面的底部一直保留着一行永不隐藏的警示文字：本工具仅用于评估本人或已获充分授权的信息系统的密码安全性，禁止用于收集、整理任何未经授权的第三方个人信息，更不得用于尝试登录他人的账号。在使用本工具之前，你应该充分理解相关法律法规，任何未经授权的密码猜测、身份验证绕行都可能构成违法行为。
从技术上讲，同样一批生成的字符串，放在自动化爆破工具里可以变成恶意尝试的子弹；而放在安全研究者手里，则可以通过模拟攻击路径来检测防护能力、验证弱口令策略是否落实。我理想中的读者，应该学会用这个工具去防守自己，而不是去伤害别人。
5.2 如何用这个工具提升个人密码韧性
如果你愿意花五分钟做一个自我检测，我建议按下面的步骤来测：
先按自己的真实信息生成一份基础候选集，大小控制在几千条就够了，不必追求过大。然后把这套结果和你目前常用的两三个密码做一次交叉对比，如果一个都没命中，说明你的密码大体上没有建立在姓名、生日、手机号码的直接拼接之上，这已经比多数人强了。
紧接着做一个进阶测试，在自己的密码中随机抽取一个连续片段，判断这段文字本身读起来是不是一个可记忆的单词或名字。如果抽取出的片段有完整的语义，那么恭喜，你的密码仍然存在被社工枚举的风险。因为在生成器这类工具背后的规则库里，“有意义的词根”反而比随机字符串更容易被枚举出来。
最后把测试结果用在改进密码策略上。我的个人建议是，密码不要包含任何现实世界中可自然联想到你的信息，不要用拼音、生日、手机号以及它们的常见变体，也不要复用同一个密码走天下。如果真的需要记忆很多高强度的独立密码，建议引入正版、信誉良好的密码管理器来随机生成并存储密码。真正的随机数生成器产出的密码，才是社工枚举很难覆盖到的方向，而这一点恰恰是这类基于记忆单元拼接的生成器永远无法做到的——它会帮你找到一个不可能被猜到的位置。
5.3 关于代码发布和数据清理的一些提醒
由于这个项目的代码量不大，我发布时习惯把完整源文件放在本地文件夹里，方便复制给有同样需求的人学习浏览。在分享代码时，我会把示例数据和默认的测试假信息处理干净，避免有人拿一份别人的示例数据误当真实生成。
所有使用过程中产生的输出文件，我强烈建议在使用后通过文件粉碎或安全的删除方式处理。若你是在公共电脑上运行的，还需要额外留意浏览器有没有把当前页面加入表单历史记录。Firefox、Edge或Chrome默认不会保留未提交到服务端的表单纯文本历史，但有些扩展插件可能有强行记录的功能，所以在公共设备上用完后清理浏览器数据是最稳妥的办法。
6. 常见问题与排查技巧实录
6.1 双击HTML文件后页面显示乱码或空白
乱码几乎十有八九都是文件编码问题。这个项目的中文字符比较多，如果你用某些老旧的文本编辑器改过文件再保存为ANSI或GBK编码，就会让浏览器解读utf-8失败。解决办法是：始终用现代编辑器，如VS Code或Notepad++来编写并强制以UTF-8编码保存。另外确认一下html文件开头的meta charset="utf-8"是否完整，不要放在title标签之后，因为它需要在文档早期就被解析到。
如果你面对的是一片完全空白的页面，打开开发者工具并切到Console看有没有红色的JS报错信息。很多时候空白是因为JS里有一个语法错误导致整个脚本停摆，页面元素来不及渲染。可以试一下在本地回退到上一个备份版本，确认是不是改动了什么关键逻辑才引发的问题。
6.2 中文输入无法正确解析到词根
有段时间我收到的反馈说，填了中文名但生成的词根列表是空的。后来排查发现，是因为我没做中文到拼音的转换，而这个工具默认是没有第三方拼音库的，所以我实际上并不把中文名这一栏用于直接生成，真正进入词根的是你填写的拼音全拼和首字母。为避免误解，我在界面上把“姓名拼音”“拼音首字母”这些字段醒目标注了必填属性，并对中文名输入框加了一个提示：“本工具不做中文转拼音，请手动填写拼音输入”。
如果你需要更便捷的中文到拼音转换，可以自行引入一个支持浏览器端运行的拼音库，但要依赖外部库就违背了单文件零依赖的初衷，所以我不太推荐主线版本走这个方向。自己补充一个本地化转换JS，或者单独做一个中文转拼音页面，需要的时候复制结果回来，体验上也不差。
6.3 生成结果数量太大导致标签页崩溃或卡死
这是使用过程中最容易遇到的性能问题。你会发现输入得越多，勾选的规则越全，词根组合的笛卡尔积数量级上涨得越夸张。我在开始生成前加了量级评估提示，会估算如果有10万条以上就不建议全部预览。如果实在需要生成超大字典，建议开启“仅导出不预览”选项，让JS通过Blob直接下载文件，这样浏览器只占用下载缓冲区的内存，不会因为往textarea写数十万行文本而卡死。
另外一个稳妥的方法是尽量精简规则。真实工作中，高价值的候选结果往往集中在前几轮规则组合里。如果是在自测场景，每条规则分开生成并提交检查，会比一次全量膨胀更容易定位问题。
6.4 代码逻辑修改后没有生效，还是旧逻辑在跑
浏览器有缓存机制，你改了本地HTML文件后直接刷新有时候没有立即生效。我通常在测试时按Ctrl+F5强制刷新或者干脆把页面标签页关闭重新双击文件打开。此外还要确认你编辑的是正确的那个文件，尤其是当你桌面上同时存在多个相似命名的副本时，容易出现改了A文件但打开的是B文件这种乌龙。
在调试逻辑时，我习惯直接在js代码的关键函数入口处打console.log，把中间生成的词根组和每条规则的结果数打印出来。浏览器按F12打开控制台就能看到详细情况。如果你发现在某个环节后结果数量暴增，优先检查是不是把相似规则重复执行了两遍，这种修复往往比想象中简单。
我在实际开发里的一个小体验是：无论页面功能多简单，都应该留一点调试和状态提示的余地，不要把所有逻辑封装成一个黑盒。代码可读性和运行进度反馈，往往在最后调优时比什么都管用。