手写代码高亮编辑器：textarea覆盖层与Token化实现详解

去年做内网部署的系统时，我遇到一个特别现实的需求：表单里需要内嵌一个能写配置脚本的编辑器。内网环境不能拉CDN，打包也不愿意为一个小功能引入上百KB的第三方编辑器源码，更别说CodeMirror那套theme和mode加载体系了。于是“用原生JS自己写一个交互式代码高亮编辑器”这个看似离谱的任务，就落到了我头上。

做完之后我最大的感触是：代码高亮听起来很高深，拆开之后其实就是“正则切Token + 样式拼接”的事，真正麻烦的是编辑器交互层面的细节——光标、滚动、缩进、输入法，每一项都能让人加班。这篇文章会把这套组件的完整实现拆开讲：textarea+覆盖层的整体架构、Token化高亮引擎、输入与滚动同步、行号/括号匹配/主题切换这些交互功能，以及我在实测中踩出来的几个隐藏很深的坑。如果你有类似的需求，或者单纯想搞懂一个代码编辑器是怎么工作的，可以照着这篇直接往下做。

1. 先别急着写代码：textarea方案还是contenteditable方案

1.1 什么场景下值得自己动手写编辑器

很多人一听“手写编辑器”就觉得是重复造轮子，我也不反对这个观点。在有CodeMirror、Monaco可用的场景下，确实不应该自己造。但当项目满足下面任一条件时，手写一个反而更划算：

1. 部署环境受限：内网、离线环境不能用CDN，npm包又要过审，一个小功能引入整个编辑器源码性价比很低。
2. 需求高度定制：只需要高亮某几个关键词或一种领域语言，不希望引入一整套主题体系、插件机制。
3. 体积敏感：页面本身很轻，为了一个编辑器把包体积增加上百KB不划算。
4. 学习驱动：你想弄懂编辑器底层的原理，把它当成技术拆解项目来做。

我当时做的内部系统属于前两种。配置脚本是团队自定义的一套类Lua语法，界面风格有严格的视觉规范，引入CodeMirror之后还要改主题、禁掉一堆用不到的功能，折腾一圈下来不如自己写一个。

1.2 两条路线的核心差异

在动手之前，先要把技术路线定下来。主流的“自研”方案有两条，差别很大：

contenteditable方案最吸引人的地方是“所见即所得”：用户看到的就是DOM本身，光标、选区、高亮都在同一个文档流里，没有两层错位的问题。但代价是你要处理浏览器间各种诡异的差异，比如不同平台的光标行为、粘贴带格式、中文输入法候选框干扰，这些坑深不见底。textarea方案刚好相反，输入行为全交给浏览器，代价是需要在视觉上做一层“高亮覆盖”，把textarea的文字藏起来，同时保证两层在空间上严格对齐。

1.3 为什么最终选择textarea+覆盖层

我的选择是textarea+覆盖层。理由很简单：textarea把最难的部分——输入法、光标、选区、滚动、撤销栈——全部兜住了。你不需要跟Range对象搏斗，不需要监听composition事件去猜用户是不是在组词，只要把textarea当成一个“真正的内容源”，然后在它下面放一层只负责视觉的高亮层。这对中文用户尤其友好，因为输入法在textarea里的表现是最稳定的，而contenteditable在部分浏览器上会遇到候选框位置错乱的问题。

textarea方案的另一个隐藏优势是表单语义。编辑器内嵌在表单里，提交时直接取textarea.value就能拿到源码，不需要额外写隐藏域同步。复制粘贴时默认也是纯文本，对代码编辑器来说这恰恰是正确的行为。

这套架构的思路可以概括成一句话：数据侧与呈现侧分离。数据永远在textarea.value上，呈现永远在pre.innerHTML里，两者通过事件同步，互不污染。把这句想明白，后面所有功能都好设计了。

2. 高亮引擎：把源码拆成Token再拼回去

2.1 Token化到底解决了什么问题

高亮的本质不是“对整段字符串做替换”，而是把源码切分成若干片段，对这些片段逐一判断类型，再给不同类型套不同样式。这种切分在编译器领域叫词法分析，切出来的片段叫Token。在我们这个场景里不需要构建AST语法树，只需要拿到每个Token的类型、起止位置和原文就够了。

举个例子，const name = "hello";这段代码，应该切出这些Token：

• const：关键字
• name：标识符
• =：符号
• "hello"：字符串
• ;：符号

空格也是Token的一部分，只是用默认颜色渲染。实现时最省力的方式是维护一个规则表，规定每种Token的正则表达式，然后在源码上依次匹配出所有Token，合并排序后按位置顺序渲染。

有人会问：直接对整段代码做全局替换不行吗？比如code.replace(/function/g, '<span>function</span>')。这种方式的致命伤在于，它会无差别替换掉字符串和注释里的function。比如const a = "function";，结果字符串里的function也被上色，高亮就错了。Token化方案之所以正确，是因为它在同一份源码上先采集所有Token的位置，再通过重叠剔除规则决定最终归属，这样字符串和注释就会“抢占”内部的普通关键字，互不干扰。

2.2 规则表、优先级重叠与HTML转义

我这里给一份可直接运行的规则表，覆盖了JavaScript常用的高亮类型。实际项目中你可以按需增删，这个结构非常灵活。

const TOKEN_RULES = [ { type: 'comment', pattern: /\/\/[^\n]*|\/\*[\s\S]*?\*\//g }, { type: 'string', pattern: /"(?:[^"\\\n]|\\.)*"|'(?:[^'\\\n]|\\.)*'/g }, { type: 'number', pattern: /\b\d+(?:\.\d+)?\b/g }, { type: 'keyword', pattern: /\b(?:function|const|let|var|return|if|else|for|while|class|new|typeof|instanceof|switch|case|break|continue|try|catch|finally|throw|this|super|extends|import|export|default|async|await|yield)\b/g }, { type: 'func', pattern: /[A-Za-z_$][\w$]*(?=\s*\()/g } ];

匹配完成后，每个Token统一成四个字段：type（类型）、start（起点）、end（终点）、text（原文），收集到数组里。

接下来要处理重叠问题。以// "hello"这行注释为例，注释规则会匹配到整行，字符串规则也会匹配到内部的"hello"，两者范围重叠。处理重叠的办法是：先把所有Token按start从小到大排序，start相同则按规则顺序排序，然后顺序扫描，用一个cursor记录当前已覆盖到的位置，只要某个Token的start小于cursor就直接跳过，否则保留它并推进cursor。

还有一个必须处理的点是HTML转义。源码可能包含<、>、&、引号等字符，直接拼进innerHTML会把它们当成标签或实体处理，轻则高亮错乱，重则产生XSS风险。所以从源码切片到HTML碎片时，必须先做一次转义：

function escapeHtml(str) { return str .replace(/&/g, '&amp;') .replace(/</g, '&lt;') .replace(/>/g, '&gt;') .replace(/"/g, '&quot;') .replace(/'/g, '&#39;'); }

注意：转义必须作用在所有源码文本上，哪怕是Token的原文也要转义。<span class="tok-keyword">这种我们自己拼的HTML标签不受影响，因为那是我们在代码里直接写的字符串，不经过escapeHtml。

2.3 一个能直接用的highlight函数

有了规则表和转义逻辑，核心高亮函数就只剩下两件事：调用tokenize拿到Token数组，然后顺序拼接HTML字符串。

function tokenize(code) { const tokens = []; TOKEN_RULES.forEach((rule, ruleIndex) => { const regex = new RegExp(rule.pattern.source, rule.pattern.flags); regex.lastIndex = 0; let match; while ((match = regex.exec(code)) !== null) { tokens.push({ type: rule.type, ruleIndex, start: match.index, end: match.index + match[0].length, text: match[0] }); if (match[0] === '') regex.lastIndex++; } }); tokens.sort((a, b) => a.start - b.start || a.ruleIndex - b.ruleIndex); const merged = []; let cursor = 0; for (const token of tokens) { if (token.end <= cursor) continue; if (token.start < cursor) { token.start = cursor; if (token.start >= token.end) continue; } merged.push(token); cursor = token.end; } return merged; } function highlight(code) { const tokens = tokenize(code); let html = ''; let pos = 0; for (const token of tokens) { if (token.start > pos) { html += escapeHtml(code.slice(pos, token.start)); } html += `<span class="tok-${token.type}">${escapeHtml(token.text)}</span>`; pos = token.end; } if (pos < code.length) { html += escapeHtml(code.slice(pos)); } return html; }

这段代码看起来不长，但它已经解决了高亮中最容易出问题的三个点：字符串内容不会被误高亮、重叠Token有明确的归属优先级、所有源码字符都经过转义。日常几百行以内的代码，匹配性能完全不是问题。

我在项目里还把规则表做成了配置项，可以传入不同语言的高亮规则。比如JSON高亮只需要字符串、数字、关键字三类，SQL高亮再加表名、函数名。Token化流程和渲染逻辑分离之后，扩展新语言就是加几条正则的事。

3. 编辑器外壳：透明输入层与高亮渲染层的对齐艺术

3.1 两层布局的CSS对齐要点

先贴出最核心的HTML结构和样式。这是整个编辑器稳定的基础，值得多看两眼。

<div class="editor"> <div class="editor-body"> <pre class="layer-code"></pre> <textarea class="layer-input" spellcheck="false" autocapitalize="off" autocomplete="off"></textarea> </div> </div>

.editor { position: relative; width: 100%; height: 420px; font: 14px/1.6 "Fira Code", Consolas, "Courier New", monospace; } .editor-body { position: absolute; inset: 0; } .layer-code, .layer-input { position: absolute; inset: 0; margin: 0; padding: 16px; border: 0; font: inherit; letter-spacing: normal; tab-size: 4; white-space: pre; word-wrap: normal; } .layer-code { z-index: 1; overflow: hidden; } .layer-input { z-index: 2; color: transparent; caret-color: #333; background: transparent; resize: none; outline: none; overflow: auto; } .layer-input::selection { background: rgba(120, 160, 255, 0.35); }

对齐的关键有三个。

第一，字体必须完全一致。字体栈要统一设置在父容器上，子元素用font: inherit继承，绝对不要在textarea和pre上分别写一套font-family。只要两边字体不同，字符宽度就会有偏差，光标和文字会逐渐错位，越往下越明显。

第二，字号、行高、padding、边框必须精确一致。任何一边多一个像素，高亮文字和实际输入位置就会漂移。最省心的做法是让两层共享同一个CSS规则，只通过z-index和color区分职责。

第三，white-space都要是pre，并且关闭自动换行。textarea的换行逻辑和HTML默认的white-space: pre本来就一致，但如果你让pre自动换行了（word-wrap: break-word），屏幕上行数和textarea内部的行数就对不上了，光标和渲染层会彻底错乱。

3.2 监听输入、防抖渲染与滚动同步

textarea的输入事件会实时更新value，但高亮层不会自动跟着变，需要监听input事件刷新渲染层。这里要注意：不要每次按键都全量渲染，加上一层防抖是最简单也最有效的性能手段。

const editor = document.querySelector('.editor'); const input = editor.querySelector('.layer-input'); const codeLayer = editor.querySelector('.layer-code'); let renderTimer = null; input.addEventListener('input', () => { if (renderTimer) clearTimeout(renderTimer); renderTimer = setTimeout(render, 120); }); function render() { codeLayer.innerHTML = highlight(input.value); syncScroll(); } function syncScroll() { codeLayer.scrollTop = input.scrollTop; codeLayer.scrollLeft = input.scrollLeft; } input.addEventListener('scroll', syncScroll);

这段逻辑很短，但它回答了“交互式代码高亮编辑器”里最核心的问题：用户能打字，高亮能实时跟着变，滚动时两层不会错位。为什么不用保存光标位置？因为textarea的value没有变化，只是下层pre的innerHTML变了，textarea的光标完全不受影响，这是textarea+覆盖层方案比contenteditable简单得多的地方。

这里有一个体验细节：120ms防抖意味着输入后高亮会“稍微延迟”。对几百行的脚本来说几乎感知不到；如果你希望更跟手，可以把防抖降到60ms，或者用requestAnimationFrame按帧渲染，不再叠加防抖。后面性能小节我会再展开。

3.3 Tab缩进与回车缩进继承

要让编辑器具备“编辑器”的手感，至少要处理两个特例按键：Tab和Enter。

Tab默认会切换焦点，但代码编辑器里应该插入缩进。可以在keydown里阻止默认，把两个空格（或一个\t）插入到光标位置，同时移动光标：

input.addEventListener('keydown', (e) => { if (e.isComposing) return; if (e.key === 'Tab') { e.preventDefault(); const start = input.selectionStart; const end = input.selectionEnd; const value = input.value; input.value = value.slice(0, start) + ' ' + value.slice(end); input.setSelectionRange(start + 2, start + 2); triggerRender(); } if (e.key === 'Enter') { e.preventDefault(); const start = input.selectionStart; const end = input.selectionEnd; const value = input.value; const lineStart = value.lastIndexOf('\n', start - 1) + 1; const prefix = value.slice(lineStart, start).match(/^\s*/)[0]; const insert = '\n' + prefix; input.value = value.slice(0, start) + insert + value.slice(end); input.setSelectionRange(start + insert.length, start + insert.length); triggerRender(); } });

这里有两个细节很关键。一是e.isComposing判断：中文输入法选词过程中也会触发Enter，如果这时候强行插入换行，会破坏输入法的组合状态，所以必须放行。二是回车缩进继承：逻辑是读取光标所在行行首的空白字符，在新行前自动补上相同缩进。这样写嵌套代码时不需要手动敲空格，体验会顺滑很多。

我第一次实现时遗漏了prefix这段逻辑，结果写if语句时代码缩进全乱，深层嵌套基本没法用。补上之后，这个编辑器已经能用来写小段代码了。

4. 把“编辑器”做成编辑器：行号、当前行、括号匹配与主题切换

4.1 行号侧边栏的正确打开方式

行号是代码编辑器最常见的辅助元素。实现上并不难，但涉及独立滚动和增量刷新，容易踩坑。我的做法是在编辑器左侧加一个固定宽度的gutter区域，内部放一个行号容器，监听input和scroll事件同步行号。

const gutterInner = editor.querySelector('.gutter-inner'); const gutters = []; function renderGutter() { const lineCount = input.value.split('\n').length; if (lineCount > gutters.length) { while (gutters.length < lineCount) { const div = document.createElement('div'); div.className = 'gutter-line'; gutterInner.appendChild(div); gutters.push(div); } } else { while (gutters.length > lineCount) { gutterInner.removeChild(gutterInner.lastChild); gutters.pop(); } } gutters.forEach((div, i) => { div.textContent = i + 1; }); }

这里有个性能技巧：行号不需要每次都重建DOM。如果行数只增不减就新增节点，减少就删掉多余节点，最后再批量改文本。这比每次innerHTML整体重绘更省事，滚动和快速输入时不容易卡顿。

gutter区域和textarea之间还需要做纵向滚动同步：在scroll事件里同时设置gutterInner.scrollTop = input.scrollTop，这样代码滚动时行号会跟着走。注意不要水平移动gutter，让它固定在左侧。

4.2 当前行高亮和括号匹配

当前行高亮能帮用户快速定位光标所在位置。实现思路是：根据selectionStart计算光标在第几行，然后在渲染层添加一条绝对定位的背景条。因为渲染层的行高是固定的，每行的top就是行号乘行高，定位很简单。

function getCurrentLine() { const value = input.value; let line = 1; for (let i = 0; i < input.selectionStart; i++) { if (value[i] === '\n') line++; } return line; }

计算出行号以后，创建一条position: absolute的背景div，top设为(line - 1) * lineHeight，height设为lineHeight，然后追加到渲染层或者单独的层。每次input、click、keyup事件触发时重新定位。注意渲染层的内容和背景div不能互相遮挡，背景div的z-index要低于代码文本，或者先插入背景div再插入代码内容，让代码自然盖在背景上。

括号匹配是另一个很能提升“专业感”的交互。思路不复杂：光标位于某个括号字符上时，在源码中找与它配对的另一个括号，然后给两个字符加高亮样式。配对算法用栈来扫：

function matchBracket(code, index) { const pairs = { '(': ')', '[': ']', '{': '}' }; const open = code[index]; const close = pairs[open]; if (!open || !close) return null; let depth = 0; for (let i = index; i < code.length; i++) { const ch = code[i]; if (ch === open) depth++; else if (ch === close) { depth--; if (depth === 0) return i; } } return null; }

左括号向右扫描，右括号就反向扫，逻辑完全对称。这里有个我踩过的坑：如果代码里有字符串和注释，括号算法不能盲目遍历，否则会匹配到字符串或注释里的括号。严谨做法是先把字符串和注释的Token范围传进来，判断光标位置是否在区间内，如果是就跳过匹配逻辑。

4.3 用CSS变量做主题切换

高亮编辑器的配色管理，我强烈建议用CSS变量。主题切换无非是换一组色值，用CSS变量后不需要写任何切换逻辑：

.editor[data-theme="light"] { --color-bg: #ffffff; --color-fg: #24292e; --color-comment: #6a737d; --color-string: #032f62; --color-keyword: #d73a49; --color-number: #005cc5; --color-func: #6f42c1; } .editor[data-theme="dark"] { --color-bg: #1e1e1e; --color-fg: #d4d4d4; --color-comment: #6a9955; --color-string: #ce9178; --color-keyword: #569cd6; --color-number: #b5cea8; --color-func: #dcdcaa; } .tok-comment { color: var(--color-comment); } .tok-string { color: var(--color-string); } .tok-keyword { color: var(--color-keyword); } .tok-number { color: var(--color-number); } .tok-func { color: var(--color-func); }

切换主题只需要设置editor.dataset.theme = 'dark'，所有颜色更新都由CSS完成。这个方案也方便用户自定义配色，只要覆盖CSS变量即可，不需要改JS逻辑。

我还会把背景色和前景色也做成变量，这样整体视觉风格能一并切换。后面如果要做暗色模式跟随系统，只需监听prefers-color-scheme给dataset.theme赋值，成本极低。

5. 性能优化与实测踩坑记录

5.1 全量渲染的性能瓶颈与应对方式

textarea方案最大的性能风险在render函数：每次防抖到期，都要对整段代码做tokenize、拼接HTML、整体赋值innerHTML。对几百行代码来说，tokenize不到1ms，innerHTML重写可能花2~5ms，用户完全无感；但到了几千行甚至上万行，innerHTML重写会涨到几十毫秒，滚动时还可能因为重复渲染出现卡顿。

我在实际项目里踩到过这个坑：某个页面的配置脚本被业务方堆到了2000多行，输入时总感觉高亮慢半拍，滚动重建时也能看到明显的延迟。解决办法是给渲染加双重保护：一是保留input的防抖，把高频输入期间的渲染收敛；二是滚动事件里只更新scrollTop和行号，不重渲染高亮，高亮交给防抖完成。

如果你的编辑器要应对大文件，可以考虑把“全量渲染”改成“只渲染可视区”。思路是：根据textarea的scrollTop和clientHeight算出当前可见的行范围，只对这个区间做tokenize和拼接，区间外用占位符。这样做的好处是渲染时间与文件总行数解耦，代价是实现量会增加不少，需要管理每行的Token缓存和高度一致，属于进阶优化。

5.2 我在实际项目中踩过的五个坑

按踩坑顺序列一下，这些坑通常不会出现在三方库文档里，但自己实现时大概率会遇到。

第一个是字体一致性问题。Windows下如果字体栈里没有等宽字体，或者编辑器父元素字体与textarea/层的字体不一致，字符宽度偏差会让下层高亮和实际光标位置错开。代码里的解决方式是把font设置放在编辑器容器上，所有子元素都用font: inherit继承，强制使用等宽字体栈。

第二个是选区颜色遮挡问题。textarea透明层依旧会绘制选区背景，默认的蓝色背景会盖住下层高亮，选中代码时高亮颜色会全部消失。处理方式是给textarea::selection设置半透明背景，让下层颜色还能透出来。这个方案不能彻底消除遮挡，但对高亮编辑器来说是可接受的效果。

第三个是输入法候选框与透明文字层的组合问题。部分浏览器在输入法组字过程中，textarea内部会直接显示组字文本，因为color: transparent，用户会看不到正在输入的拼音或重组文字。兜底做法是在compositionstart时暂时关闭透明，给textarea加一个class让它显示正常文字颜色，compositionend后再恢复透明。这不是最优雅的方案，但至少保证中文用户能正常输入。

第四个是XSS与HTML结构破坏问题。如果highlight输入不对源码做转义，一个简单的<就能让渲染层结构错乱，一段带onerror属性的img标签就能触发脚本。要在渲染函数里保证所有源码文本都经过escapeHtml，包括Token的原文部分，不能有遗漏。

第五个是IME对Enter和Tab拦截的影响。前面提过要用e.isComposing判断，否则中文输入法选词时按Enter会意外插入换行，Tab也会干扰候选框。这个细节看起来小，但对中文用户体验影响很大，我见过好几个编辑器方案在这个问题上翻车。

5.3 手写编辑器的能力边界

正则驱动的Token化方案有一个绕不开的边界：它对复杂语法无能为力。JavaScript里的模板字符串嵌套表达式、正则字面量与除法符号的歧义、JSX/TS类型标注，这些光靠正则根本无法正确区分。如果项目需要完整支持某种主流语言，我更建议直接用CodeMirror或Monaco，它们的parser和长文档性能都经过大规模验证，没必要自己重新发明一遍。

手写编辑器的定位应当是：零依赖、体积小、行为可控、满足业务特定的那一小撮语法高亮需求。比如内部系统的配置脚本、模板语言、领域专用语言，这种场景反而比通用代码编辑器更合适。判断标准很简单：如果编辑器只需要支持一种或几种自定义语法，且被编辑的代码量在千行以内，手写就是划算的；如果要对标通用IDE体验，还是收手去接成熟库更稳妥。

这个编辑器我后来又迭代了几版，把语言规则抽成了配置，加了简单的自动补全建议。回头看，最值钱的不是那几行高亮代码，而是我理解了textarea方案下“数据侧与呈现侧分离”的核心思路——这比记住某个库的API有用得多。如果你也在做一个需要内嵌编辑器的内部系统，希望你能少走我走过的这些弯路。