单词查找和字母重排（word-finder / anagram solver）是一个看起来特别小的功能，但对经常玩填字游戏、Scrabble、Wordle 这类字母游戏的人来说，它是真正的高频工具。这个项目把“输入一组字母—找出所有能组成的单词—按词长或得分排序”的完整流程，做成了适合移动浏览器打开的网页应用，不用安装 App，打开浏览器就能查。
这篇内容适合三类人看：单词游戏卡关时想快速找词的人、想做轻量教育或工具型小产品的开发者、正在研究移动端离线检索和输入交互的前端工程师。我的核心建议是：这类工具真正的难点不在算法，而在移动端的词典加载、输入交互、结果展示和性能控制。下面按我实际测试完一轮的顺序拆开讲。
1. 这个工具到底解决什么问题，为什么必须适配移动端
1.1 典型使用场景
一个单词查找和 anagram 工具要处理的问题其实分三层。
第一层是精确重排。用户输入“listen”，工具能返回“silent”“enlist”“tinsel”这些由同样字母组成的单词。这一类查询需求最直接，拼字游戏里经常遇到“这几个字母能摆出什么词”的疑问。
第二层是子集查找。用户手里有一批字母，比如“a e i l n s t”，想知道能拼出哪些三到七字母的单词。这个场景更常见，因为游戏里几乎不会刚好凑出一组能拼完整单词的字母。工具需要从词表里找出所有字母计数不超过输入计数、且长度满足条件的词。
第三层是通配符。很多单词游戏里有空格或万能牌，用户输入“?listen”或“??st”时，工具要把问号当成任意字母去扩展。这个功能查询成本会明显上升，但也是判断一个单词工具是否好用的分水岭。
这三层需求本质上都是“给定字母集合，从词典里筛出合法词”，只是匹配规则从精确到子集再到带通配符，复杂度逐步增加。做之前先想清楚自己主要服务哪类场景，能省掉很多无用功。
1.2 为什么是移动网页，而不是 App
这类工具的使用场景是碎片化的。用户通常是在游戏进程中发现卡住，随手拿起手机查一个词，而不是专门坐到电脑前搜索。
所以网页应用有天然优势：不需要到应用商店下载，不需要注册登录，不需要申请存储、相册这类权限。用户打开浏览器输入字母就能拿到结果。对开发者来说，发布和更新也简单，静态资源更新后，用户下次打开就是新版本。
另外一个值得考虑的点：这类查询不需要上传用户隐私，纯前端也能完成整个流程。这对用户来说信任成本低，对开发者来说不用维护后端账号体系，部署成本也低。只要把词典在前端组织好，离线也能用。
2. 词典和检索设计：不着急写界面，先把数据组织好
2.1 词表选型和体积控制
词表是工具的地基。不同单词游戏用的词表规则不一样：有的用美式拼字比赛词表，有的用国际通用词表，有的只是普通英语常用词。这些词表的词条数量通常在几万到几十万之间，纯文本体积从几 MB 到十几 MB 都有可能。
在移动端，词表体积不能忽视。用户用手机流量打开页面，如果首屏就要下载十几 MB 的词典，体验会差很多。常见的控制方法有：
- 只放当前场景需要的词表。比如做单词学习工具，常用几万词完全够用，不需要把竞赛词表全塞进去。
- 按词条首字母或长度拆成多个分片，用户输入第一个字母后再按需加载对应分片。
- 对词表做压缩，用更紧凑的格式存储。
- 配合本地缓存，第二次打开不再重复下载。
我的建议是第一步不用追求大而全，先选一个覆盖面够用的词表，把完整链路跑通，后续再根据用户反馈决定要不要换更完整的词表。词表只是数据源，核心算法不用跟着动。
2.2 用字母签名实现精确 Anagram 查找
精确 anagram 最常用的做法是给每个词生成“字母签名”：把单词里的字母按字典序排序，得到一个新的字符串。任何一组字母，只要排序后结果相同，它们就是彼此的重排。
比如“listen”排序后是“eilnst”，“silent”“tinsel”“enlist”排序后也都是“eilnst”。预处理时把所有词按签名分组，用户输入“listen”后，先算出输入字母的排序结果，再到分组里取词，查询时间基本是常数。
function getSignature(text) { return text .toLowerCase() .split('') .sort() .join(''); } // 预处理阶段：遍历词表，把同签名的词放到一组 const anagramMap = new Map(); for (const word of dictionary) { const sig = getSignature(word); if (!anagramMap.has(sig)) { anagramMap.set(sig, []); } anagramMap.get(sig).push(word); } // 查询输入字母的精确 anagram function findExactAnagrams(letters) { const sig = getSignature(letters); return anagramMap.get(sig) || []; }这段代码是完整可运行的思路。实际项目里可以把 anagramMap 序列化成本地数据，启动时一次加载，避免每次输入都重新扫描词表。
2.3 子集匹配：从一组字母里找出所有合法词
子集匹配是另一个高频需求，代价也高一些。方法是把每个词和输入都转成“字母计数向量”，也就是记录每个字母出现了几次。一个词能由输入字母组成，当且仅当这个词里每个字母的出现次数都不超过输入字母里的次数。
function countLetters(text) { const counts = new Map(); for (const ch of text.toLowerCase()) { if (/[a-z]/.test(ch)) { counts.set(ch, (counts.get(ch) || 0) + 1); } } return counts; } function canForm(wordCounts, inputCounts) { for (const [letter, count] of wordCounts) { if ((inputCounts.get(letter) || 0) < count) { return false; } } return true; } function findWordsFromLetters(inputLetters) { const inputCounts = countLetters(inputLetters); const results = []; for (const [sig, words] of anagramMap) { const sigCounts = countLetters(sig); if (canForm(sigCounts, inputCounts)) { results.push(...words); } } return results.sort((a, b) => b.length - a.length); }这里有个明显的问题：如果是几十万词的词表，每次输入都全量扫描一遍，在低端手机上会有明显延迟。常用的优化手段是先按词长分桶，只扫描长度不超过输入字母数的词；再按首字母分桶，进一步缩小候选集。实际排查中，把这两层分桶加上后，大多数实时查询都能控制在可接受范围内。
至于带通配符的查询，常见做法是把每个问号当成 26 个字母去递归尝试。这个逻辑会放大查询量，所以应该限制通配符数量。一般来说，支持 1 到 2 个通配符已经能覆盖绝大多数单词游戏场景，再往上就会明显拖慢速度。
3. 移动端输入和结果页：真正难的是输入体验
3.1 输入框、通配符和筛选条件怎么设计
移动端页面和桌面端有很大区别。桌面端用户习惯输入完整字母后按回车，移动端用户希望尽量少打字、少切换键盘。
输入框的 HTML 属性建议这样设置：
<input type="text" inputmode="text" autocomplete="off" autocapitalize="off" autocorrect="off" spellcheck="false" placeholder="输入字母，? 表示任意字母" id="letters-input" />关闭自动大写和自动纠错很关键。单词工具输入的都是字母组合，手机系统如果自动把第一个字母改成大写，或者自动把不认识的组合改成别的词，查询结果就会出错。
通配符的输入也要处理好。很多手机键盘上打问号需要切到符号页，比较麻烦。更好的做法是提供两个可点击的按钮：一个“添加 ?”，一个“清空”。用户点一下就填入一个通配符，比来回切键盘快很多。
筛选条件建议放在结果列表上方，而不是单独塞进设置页。最常见的筛选条件如下：
| 筛选 | 作用 | 说明 |
|---|---|---|
| 最小词长 | 过滤太短的词 | 默认 3 |
| 最大词长 | 限制结果数量 | 默认不限制 |
| 起始字母 | 固定首字母 | 棋盘走位场景常用 |
| 结尾字母 | 固定尾字母 | 填字场景常用 |
| 必须包含 | 必须包含指定字母 | 容易漏配，要注意 |
实时搜索在移动端要谨慎。输入一个字母就触发一次全量查询，在低端机上不仅卡，还会因为结果反复刷新让用户觉得不稳定。我的做法是对输入做防抖，停手 250 到 300 毫秒后再查询。这样输入过程中不会频繁计算，又能在用户停下来的瞬间返回结果。
3.2 结果排序和展示
结果列表的默认排序建议按词长从长到短。用户在单词游戏里找高分词，通常希望先看到长词；如果是背单词，则更希望按字母序看。可以在排序方式上提供一个切换，默认词长优先，次选项支持字母序。
如果结果数量很大，一次性渲染几千条列表项会卡住页面。建议先渲染前 50 到 100 条，列表滚动到底部时再加载下一批。这个“分批加载”比完整虚拟滚动实现成本低，在移动端效果也非常明显。
每条结果可以附带一个拼音或释义入口，但注意不要把词库里没有的信息硬塞进去。释义数据如果来源不可靠，宁可不放，也不要给用户错误的词义。
3.3 最小页面结构
一个能跑的页面结构不需要复杂：
- 顶部是输入区：字母输入框、通配符按钮、查询按钮。
- 中间是筛选区：词长范围、首尾字母、包含字母。
- 下面是结果列表：词条、排序切换、加载更多。
- 页面底部固定一个清空和复制按钮。
复制功能在移动端很有用。用户找到一个满意的词之后，直接点到结果里的复制按钮，就能粘贴到游戏输入框里。这个动作在桌面端不受重视，在手机上却很常用，值得加。
4. 性能和缓存：旧手机不卡才算真正适配
4.1 计算放到 Web Worker
如果词典只有几千词，在输入回调里直接扫描完全没问题。但如果词表到了几十万词，前端主线程被查询任务卡住，页面就会失去响应，滚动列表、点击按钮都会延迟。
解决方案是把词典加载和查询计算都放到 Web Worker。主线程只负责接收输入、把任务发给 Worker、拿到结果后渲染。这样即使是旧手机，用户在计算期间也能流畅滚动页面。
// 主线程 const worker = new Worker('/worker.js'); worker.onmessage = (event) => { renderResults(event.data.results); }; function onInput(letters) { worker.postMessage({ type: 'query', letters }); }Worker 里加载词典的方式和主线程略有不同，需要考虑fetch词表文件、解析格式、建立索引。这个改造不复杂，但收益很明显，建议在功能稳定后尽早做。
4.2 词典缓存和增量加载
移动端访问最怕重复下载大文件。词典数据第一次加载后，应该缓存到 IndexedDB，之后启动时先读缓存，再在后台检查是否有新版本。如果词表没有变化，就完全不需要走网络。
还有一个常见做法：把词典按长度或首字母拆成多个文件，启动时只加载默认分片。用户输入字母后，如果需要对应分片，再异步加载。这个方案能显著缩短首次启动时间，代价是实现复杂度高一些，适合词表比较大的场景。
如果只是学习用途的小工具，我第一次做会直接全量加载，确认逻辑没问题后再做缓存。不要一上来就想着把缓存、分片、版本管理全做完，那样很容易被基础设施拖住，核心查询反而没时间打磨。
4.3 渲染优化和输入防抖
结果列表的渲染要避免每次都重建整棵 DOM 树。常见做法是保留列表容器，只更新列表项的数据；或者使用文档片段在内存里组装完再一次性插入。对新手来说，最简单的优化是先做分批渲染，不追求虚拟滚动。
输入防抖的时间不要设得太长。太短了会在输入过程中反复查询，太长了用户会觉得反应慢。250 到 300 毫秒基本是移动端的折中选择。另外，查询结果缓存也值得做：同一个输入字母和筛选条件，短时间内不应该重复计算。这个缓存可以用 Map 加一个简单的时间戳判断，实现成本很低。
5. 单条查询跑通之后：批量场景和分享能力
5.1 分享链接和查询条件持久化
单词工具做到一定阶段，自然会遇到“查到了结果，想分享给朋友”或者“同一组条件第二天还要再查”的需求。
一个非常轻量的做法是把查询条件编码到 URL 参数里：
/?letters=listen&min=3&max=6&startsWith=s页面启动时解析 URL 参数，自动填充输入框和筛选条件，并直接执行查询。这样用户可以把链接收藏，也可以发给别人。实现成本很低，但对工具的可传播性帮助很大。
如果未来要做批量查询，也可以沿用这套参数体系。比如从游戏进程里复制一组字母列表，逐条调用同一个查询函数，再把结果汇总。批量场景真正要处理的不是算法，而是输出命名、结果去重和失败重试。对于单词工具来说，因为查询是纯函数，失败概率很低，主要注意输入格式统一就行。
5.2 PWA 化和添加主屏
既然已经做成纯前端网页，顺手加一个 PWA 能力是划算的。至少包括 manifest 和 service worker。manifest 让用户在浏览器菜单里选择“添加到主屏幕”时，能显示一个独立图标。service worker 把页面外壳和词典文件缓存下来，实现离线使用。
对单词工具来说，离线是实实在在的能力。用户可能在通勤路上、地下室里打开工具，网络条件不一定稳定。只要词典已经缓存在本地，查询过程不需要联网。
这类功能不需要一开始就做。先把核心查询和结果展示做到稳定，再加 PWA 外壳，可以避免前期被壳子拖住节奏。
6. 常见问题排查：先看现象，再按顺序查
6.1 启动慢或白屏
如果页面打开后卡在加载状态，或者直接白屏，优先检查三件事：
- 词表文件是否能正常访问，路径是否正确，服务器有没有设置正确的 MIME 类型。
- 词表体积是否过大，有没有在等待下载完成时给用户加载进度反馈。
- 浏览器控制台有没有 JavaScript 报错，比如
fetch失败、JSON 解析失败。
下面是一个快速参考表：
| 现象 | 优先排查 | 常见原因 |
|---|---|---|
| 启动白屏 | 网络面板、控制台报错 | 词表路径错误、MIME 类型不对 |
| 加载慢 | 词表体积、缓存命中 | 每次启动都重新下载 |
| 查询慢 | Worker、扫描范围 | 全量扫描未分桶 |
| 结果漏词 | 输入格式、词表覆盖 | 全角空格、去重逻辑错误 |
这些在 PC 开发者工具里多半能复现，先用电脑调试定位，再回到手机验证。
6.2 结果少或者漏词
先确认不是输入格式问题。全角字母、空格、大小写混合，都可能干扰匹配。先查一次最简单的精确 anagram，对比已知正确答案，能快速判断核心逻辑是否正常。
再看词表本身。如果词表是常用词库，包含不了竞赛级冷僻词是正常的，不要把这当成 bug。检查漏词时，要确认输入的字母计数是不是被错误限制，特别是重复字母。比如输入“apple”，如果程序只用Set去重，就会漏掉“app”这类需要 p 出现两次的词。
6.3 移动端键盘弹出导致布局错乱
老式页面里，移动端浏览器键盘弹出时，100vh 的高度会发生变化，页面底部按钮可能被键盘挡住。现在推荐使用动态视口单位，并在滚动容器底部预留合适的内边距。
如果页面在 iOS Safari 上点击输入框后整体被缩放，检查 viewport 设置是否正确。另外，结果列表的滚动容器要放在输入框下方独立滚动，避免整个页面跟着键盘一起跳动。
6.4 查询速度明显偏慢
先用开发者工具做一次性能测试，看时间花费在加载词典还是查询计算。如果是查询慢，检查是否在每次输入时都扫描全表，有没有做字母计数预计算，有没有把重活扔给 Worker。
如果是渲染慢，重点看结果列表一次性渲染条数。把每次渲染数量降到 100 条以下，配合滚动加载，大多数旧手机都能接受。不要一上来就调并发、加缓存那些复杂手段，先把扫描范围和渲染数量压下来，往往就能解决问题。
如果只是做一个学习用途的单词小工具，默认实现已经够用。但如果要做成长期维护的线上工具，建议从第一天就把三件事顺手做对：词表按长度分区、查询放 Web Worker、结果分批渲染。这三件事做完，后面加通配符、批量查询、分享链接都会轻松很多。很多问题不是工具能力不够，而是词典组织方式和输入交互没有提前想清楚。
