简介：这份资源面向前端开发者、汉字教学工具制作者及对文字处理感兴趣的编程学习者，提供一套用JavaScript实现汉字结构拆分的代码方案，可用于输入法联想、搜索匹配优化、汉字教学演示等场景。压缩包共1个doc文件，约67KB，以文档形式集中呈现核心拆分数据与实现思路，便于直接查阅和二次整理。代码以cz.mfkdb数组组织，收录大量两字符组合，如「卧」拆为「臣卜」、「骑」拆为「马奇」、「脚」拆为「月去卩」，覆盖阝、月、马、石、土、王等常见部首，并涉及Unicode编码处理、正则与match匹配等实现要点，还提及拆分后分散显示的视觉玩法。已有909人学习下载，适合想快速获取汉字部件对照表、理解拆分逻辑并落地到网页应用或学习工具中的读者参考。
1. 汉字拆开写：一个被低估的 JavaScript 小工具
你有没有在教小孩写字时，被问过“妈妈，‘期’为什么长这样”？或者在输入法里打不出某个字，试着拆成两半念出来，结果还真打出来了？汉字拆分这件事，听起来像语文课的内容，其实在编程世界里也有它的一席之地。JavaScript 汉字拆分，说白了就是用代码把一个个方块字按结构切成若干部件，比如把“卧”切成“臣”和“卜”，把“陈”切成“阝”和“东”。它不是什么高深算法，更像一本用数组写成的“拆字字典”。搞懂它，你就能明白网页上那些按偏旁搜字、按部件匹配的功能，背后到底在干什么。
2. 为什么汉字能被“拆”：从字形结构到数据表
2.1 汉字不是铁板一块，它本来就是拼出来的
很多人下意识觉得汉字是一个整体，其实绝大多数常用字都是合体字，由两个或更多部件组合而成。左右结构的像“朋”是“月”加“月”，“骑”是“马”加“奇”；上下结构的像“花”是“艹”加“化”；半包围结构的像“陈”是“阝”加“东”。这些部件在造字时就存在，只是我们平时写字太快，把它们看成了一个整体。
打个比方，汉字就像乐高积木搭出来的模型。你看到的是一个完整的城堡，但拆开来看，无非是几块标准砖。JavaScript 汉字拆分做的事情，就是提前把“哪块模型由哪几块砖组成”记在一张表里，用的时候直接查表。项目正文里那个cz.mfkdb数组，本质上就是这张表：每一项是一个两元素的小数组，第一个元素是完整的汉字，第二个元素是它的拆分结果。比如['功','工力']告诉你“功”由“工”和“力”组成，['防','阝方']告诉你“防”左边是“阝”右边是“方”。
这种“查表法”听起来朴素，但它恰恰是这类需求最务实的解法。汉字的字形结构没有简单的数学规律可循，你没法用一个公式从“陈”推导出“阝东”，只能靠人把常用字一个个整理出来。所以这份数据的价值不在代码多巧妙，而在于那张表覆盖了多少字、拆得准不准。
2.2 为什么用 JavaScript 来做这件事
你可能会问，拆字这种事，后端做不行吗，为什么偏偏用 JavaScript？原因很实际：拆字的需求大多发生在浏览器里。用户在搜索框输入一个偏旁想找字，在网页上做汉字拼字小游戏，或者教育类页面要动态展示字形结构，这些场景都要求即时响应，把请求发到服务器再等结果，体验就断了。
JavaScript 在浏览器里直接跑，查一个数组的时间几乎可以忽略不计。而且这份数据是纯字符串，没有依赖任何图形库或后端接口，一个<script>标签引进去就能用。对于前端开发者来说，这相当于随身带了一本拆字手册，不用联网也能查。项目正文里给出的就是最朴素的var cz = {...}对象写法，没有框架、没有构建工具，复制粘贴就能跑，这种低门槛恰恰是它被广泛复制使用的原因。
2.3 拆出来的部件，到底拿来干什么
拆字本身不是目的，拆完之后能做什么才是关键。最直接的应用是按部件检索。用户记不清一个字怎么写，但记得它左边是个“阝”，或者下面是个“月”，这时候把输入拆成部件去匹配，命中率比整字匹配高得多。搜索引擎优化里也有类似思路：把汉字拆成部件后建立索引，用户搜“氵”相关的字时，能把“江、河、湖、海”一网打尽。
第二个场景是汉字教学与记忆辅助。把“赢”拆成“亡、口、月、贝、凡”，学生记起来就比死记硬背轻松。教育类网页可以用这份数据动态生成拆字动画，点一下“聪”，它分成“耳、总”两块滑开，视觉上直观得多。第三个场景是输入法与字形游戏，比如拼字游戏要求玩家把打散的部件重新组合成字，后台就需要知道哪些部件能拼成哪些字，这份表反过来用就是答案库。
提示：拆字结果里的部件不一定是严格意义上的部首。比如“徒”拆成“彳”和“走”，其中“走”并不是部首，只是字形上的一个块。做检索时按“部件”理解比按“部首”理解更准确。
3. 查表拆字怎么落地：数据结构与使用方式
3.1 一个对象加一堆数组，就是全部家当
看项目正文的代码，结构非常直白：一个名为cz的对象，里面挂着一个mfkdb属性，值是一个大数组，数组的每个元素是[完整汉字, 拆分字符串]这样的二元组。没有嵌套对象，没有哈希映射，就是顺序排列的列表。这种设计的好处是数据一目了然，增删改都方便，坏处是查找时需要遍历。
如果只是偶尔查几个字，遍历完全够用。但如果你要频繁查询，比如做一个实时拆字提示的输入框，每次按键都遍历几千条记录就会有点吃力。这时候可以在加载时把数组转成一个以汉字为键的对象，查起来就是 O(1)。下面这段代码演示了转换和查询的基本写法：
// 原始数据：二元组数组 var rawList = [ ['卧', '臣卜'], ['陈', '阝东'], ['骑', '马奇'] ]; // 转换成以汉字为键的映射表，查询更快 var charMap = {}; for (var i = 0; i < rawList.length; i++) { var pair = rawList[i]; charMap[pair[0]] = pair[1]; // 键是完整汉字，值是拆分结果 } // 查询单个汉字 function splitChar(ch) { return charMap[ch] || null; // 表里没有就返回 null，避免报错 } console.log(splitChar('陈')); // 输出 "阝东" console.log(splitChar('好')); // 输出 null（假设表里没收录）这段代码的关键在charMap[pair[0]] = pair[1]这一行：它把数组的线性结构转成了键值结构。参数上，pair[0]必须是单个汉字字符，pair[1]是拆分后的字符串，长度不固定，两个到四个字符都常见。查询函数里用|| null兜底很重要，因为用户输入的字未必在表里，直接返回undefined再往下做字符串操作就容易翻车。
3.2 拆分结果怎么用：从字符串到界面
拿到拆分字符串之后，怎么呈现取决于你的场景。如果只是做检索匹配，把拆分结果和用户输入做包含判断就行。如果要做视觉上的“散开”效果，就需要把拆分字符串再切成单个部件，分别放到不同的 DOM 元素里。项目摘要里提到的“散光功能”，通俗地说就是把一个字拆成几块、在页面上分开摆放，这在前端就是创建多个span然后设置不同的位移。
// 把拆分结果渲染成并排的部件块 function renderParts(ch, container) { var parts = splitChar(ch); if (!parts) return; // 没拆出来就不渲染 container.innerHTML = ''; // 清空容器 for (var i = 0; i < parts.length; i++) { var span = document.createElement('span'); span.textContent = parts[i]; // 每个部件单独一个元素 span.style.marginRight = '8px'; // 部件之间留点空隙 container.appendChild(span); } }这里parts是字符串，用下标逐字取出就得到单个部件。注意parts.length对汉字字符串是按字符计的，一个部件如果本身是“阝”这种单字符没问题，但如果拆分结果里混入了多字符组合，就得改用Array.from(parts)来正确切分。这个细节在只处理基本汉字时通常不会踩坑，但一旦数据里出现生僻字或兼容字符，就容易出问题。
3.3 数据从哪来，以及它为什么不可能完美
这份拆字表不是程序算出来的，是人工整理的。这意味着两件事：第一，它的覆盖范围取决于整理者收了多少字，项目正文里能看到大量常用字，但不可能穷尽所有汉字；第二，拆分方式带有一定的主观性，同一个字可能有多种合理拆法。比如“鹅”拆成“我鸟”，这是按左右结构拆的，但如果你按意义拆，可能会想到别的组合。
所以使用这份数据时要有合理预期：它是“一份可用的拆字参考”，不是“汉字结构的权威标准”。做产品时，查不到的字要有降级方案，比如原样返回或者提示“暂不支持”。把这一点想清楚，就不会在遇到生僻字时觉得是代码写错了。
4. 易混概念辨析：拆字、编码、部首不是一回事
4.1 易混点一：汉字拆分 vs Unicode 编码
为什么混：两者都跟“汉字在计算机里怎么表示”有关，而且摘要里也提到了 Unicode，很容易让人觉得拆字是靠编码算出来的。
怎么区分：Unicode 给每个汉字分配一个编号，比如“陈”有一个固定的码位，这个编号和字形结构毫无关系，你没法从码位推出它左边是“阝”。拆字靠的是字形知识，是人为整理的结构表。一句话记：Unicode 管“这个字是谁”，拆字表管“这个字由什么组成”。前者是身份编号，后者是零件清单。
4.2 易混点二：拆字 vs 部首检字
为什么混：拆出来的部件很多就是部首，比如“氵”“木”“忄”，看起来像在按部首分类。
怎么区分：部首是字典为了检索方便设定的分类标签，一个字只归一个部首；拆字是把字形上能分开的块都列出来，可能拆出非部首的部件。比如“徒”拆成“彳”和“走”，“走”不是部首，但它是字形上实实在在的一块。做按部件搜索时用拆字表更灵活，做字典式归类时才用部首。
4.3 易混点三：拆字 vs 笔画拆分
为什么混：都叫“拆”，都跟字形有关。
怎么区分：笔画拆分是把字拆到横竖撇捺这一层，比如“三”拆成三横；部件拆分是拆到“块”这一层，块本身还可以继续拆成笔画。这份 JavaScript 数据做的是部件级拆分，不是笔画级。如果你需要笔画数据，那是另一套东西，通常按笔顺逐笔记录，粒度和用途都不同。
4.4 易混点四：查表法 vs 算法识别
为什么混：提到“用代码拆汉字”，容易联想到图像识别或者字形分析算法。
怎么区分：查表法是“事先记好答案，用时直接查”，不涉及任何图像处理；算法识别是从字形图片或矢量轮廓里分析结构，复杂得多，也容易出错。这份资源走的是查表路线，优点是结果稳定、速度快，缺点是新字不入表就查不到。两者不是替代关系，查表适合已知字集合，识别适合开放场景。
5. 什么时候该用它，什么时候别硬上
先说该用的时候。如果你在做汉字学习类页面，想给每个字加一个“结构展开”的小交互，这份数据拿来就能用，改都不用改。如果你在做站内搜索，用户可能按偏旁找字，把拆字表转成索引能明显提升召回。如果你在做一个拼字小游戏，需要知道哪些部件能组成哪些字，把表反着建一遍就是题库。这些场景的共同点是：字集有限、要求响应快、不需要处理任意生僻字。项目正文里那份数据覆盖了大量常用字，对这类需求足够。
再说别硬上的时候。第一，别拿它当汉字结构的权威来源。人工整理的拆分带有取舍，同一个字不同资料拆法可能不同，做严肃的语言学工具要另找规范数据。第二，别指望它处理所有汉字。表里没有的字就是没有，生僻字、异体字、扩展区字符大概率查不到，产品里必须设计降级路径，不能假设查询永远成功。第三，别用它做笔画级或书写顺序相关的功能，粒度不对，硬套会得到似是而非的结果。第四，如果只是偶尔查一两个字，引入整份数据有点重，直接写死几个映射就够了。
我自己的习惯是：凡是引入这类人工整理的数据表，先在控制台跑一遍覆盖率抽查，随机取几十个常用字看命中率，再取几个生僻字看失败表现。有一次做一个小工具，没做这步，上线后用户输入一个表里没有的字，页面直接空白，排查半天才发现是查询返回undefined后继续做字符串拼接导致的。从那以后我每次接这类查表逻辑，都强制先写一个兜底分支再往下写业务。希望这些经验帮到你，少走一点弯路。
本文还有配套的精品资源，点击获取
