简介：面向 JavaScript 初学者与算法练习者的括号匹配题配套代码包，聚焦“有效括号”判定：左括号须由同类型右括号闭合，且闭合顺序正确。内容围绕栈这一后进先出结构展开，完整呈现遍历字符、左括号入栈、右括号比对栈顶并在失败时提前返回、最终检查栈空的解题思路，并配有 true/false 测试示例，便于理解边界条件与常见错误。压缩包仅 818B，含 2 个文件，其中 1 个 JavaScript 源码承载核心实现，1 个文本文件用于补充题目或运行说明，体量轻巧，适合课堂示例、面试刷题与本地快速验证。目前已有 3428 人学习下载，可作为掌握栈应用、梳理解题逻辑和排错复盘的参考材料。

1. 一段二十行的判题代码，为什么值得单独拆一遍

上周有人往群里丢了一段 JS 代码，说结果不对："([)]"被判成了true。我打开一看，思路没错，是栈，但pop之后他拿长度去比对类型，等于把“配对”换成了“计数”，嵌套顺序一乱就全崩。这个问题本身不复杂——给定一个只含(、)、{、}、[、]六种字符的字符串s，判断它是否有效：左括号必须用相同类型的右括号闭合，且必须以正确顺序闭合。但真把它写成一份能放进项目里、能被别人调用、能在边界输入上不翻车的代码，中间有不少细节值得摊开讲。

这份代码的定位很明确：一个纯函数式的括号有效性校验器，零依赖、单文件、可直接 Node 跑，也可以挂到表单校验、表达式解析、模板语法的预检查上。适合两类人：刚学栈这个数据结构、想找一个最小可运行例子的新手；以及手上有解析器、配置语法、富文本标记需要做前置校验，想直接抄一个稳的实现的熟手。后面几章按“选型 → 拆代码 → 跑起来 → 踩坑 → 改造”走一遍。

2. 技术选型：为什么这三类括号必须用栈，计数法和正则各差在哪

先说结论：这类题在工程里几乎只有一种正解，用栈。但很多人的第一反应不是栈，而是“数一数左右括号数量不就完了”，或者“拿正则把成对的替换掉，替换空了就合法”。这两种写法在特定输入下都能过，放到真实场景里就露馅。把三条路摆在一起对比，才知道为什么最后落到栈上。

2.1 三种写法的实测差异：计数法、正则替换、栈

计数法最省事，一个变量加减到底：

// 计数法：只统计数量，不记录类型和顺序 function isValidByCount(s) { let balance = 0; for (const ch of s) { if (ch === '(') balance++; else if (ch === ')') balance--; // 中途变负说明右括号多了，可以直接返回 if (balance < 0) return false; } return balance === 0; // 收尾必须归零 }

这段代码对"()"、"(())"、"())("都能给出正确答案，但一遇到"([)]"就返回true。原因很直白：balance只记了多少，不记谁跟谁。(和[都加一，)和]都减一，类型信息在计数的瞬间就丢了。更麻烦的是它连“三种括号混用”都识别不了，"([)]"的字符数量完全合法，唯一的问题是顺序。所以计数法只能在“输入里只有一种括号”的前提下成立，超出这个前提就是错的。

正则替换的思路是“消消乐”：反复把最内层的成对括号删掉，删到不能再删，看剩下的是不是空串。

// 正则消消乐：每轮消掉最内层的一对 function isValidByRegex(s) { const pair = /\(\)|\[\]|\{\}/g; let prev; do { prev = s; s = s.replace(pair, ''); // 一轮扫描只能消掉一层 } while (s !== prev); return s.length === 0; }

"([)]"在这套逻辑下：第一轮没有()、[]、{}这样的相邻对，s没变，循环直接退出，返回false，结果是对的。它能正确处理嵌套，问题在复杂度：每一轮replace都要完整扫一遍字符串，嵌套深度为n/2的时候就要扫n/2轮，整体退化成 O(n²)。输入几百个字符看不出差别，输入十万个字符就是几十亿次字符访问，实测会明显卡住。而且它天然带一层“反复创建新字符串”的垃圾回收压力，在浏览器主线程上跑大文本是要挨骂的。

栈的写法一次遍历就能出结果，时间 O(n)、空间 O(n)，空间只跟嵌套深度有关，不跟字符串长度强绑定：

// 栈：左括号压栈，右括号跟栈顶比对 function isValidByStack(s) { const stack = []; const pairs = { ')': '(', ']': '[', '}': '{' }; for (const ch of s) { if (ch === '(' || ch === '[' || ch === '{') { stack.push(ch); // 左括号：记录待配对 } else { // pop 出来的必须和当前右括号的类型对上 if (stack.pop() !== pairs[ch]) return false; } } return stack.length === 0; }

三者的差别可以压成一张表：

我一般不会在项目里留前两种，哪怕只是图省事写个临时校验。原因不是“算法课要求用栈”，而是错误判定的代价太高——一个语法预检查放过了不该放过的字符串，问题会被推到后面的解析阶段，报错位置离真正的错误点十万八千里，排查成本翻好几倍。

2.2 单文件脚本的骨架：入口、核心函数、导出方式

这份代码的物理结构很简单，一个文件三段：映射表、核心函数、导出与自测入口。结构简单但边界要划清楚，否则别人拿到手不知道从哪调。

// valid-parentheses.js const PAIRS = Object.freeze({ ')': '(', ']': '[', '}': '{' }); const OPENERS = new Set(['(', '[', '{']); function isValid(s) { // 核心实现放在这一层，见第 3 章 } // 双出口：CommonJS 方便 Node 直接 require，ESM 环境走默认导出 if (typeof module !== 'undefined' && module.exports) { module.exports = { isValid, PAIRS }; } export default isValid; // 打包器会把上面这段当成具名 + 默认混合导出

PAIRS用Object.freeze包一层不是炫耀，是防止下游某处手贱改了映射表导致全项目判定漂移；OPENERS用Set而不是数组，是因为Set.has在字符集变多之后仍然是 O(1)，而Array.includes是线性扫描，虽然这里只有三个元素差别不大，但扩充字符集的时候不用回头改。双出口的写法在小工具库里很常见：Node 侧require拿到的是对象，前端打包器走export default，两边都能用，代价是文件不能直接当<script>引，得配构建。

注意：如果你的运行环境同时支持 CJS 和 ESM，别在同一个文件里既写module.exports又写export还指望node直接跑，得用.mjs或package.json里的type字段明确模块类型，否则会撞上SyntaxError: Unexpected token 'export'。

3. 核心函数拆解：一次循环里做完的入栈、比对与提前返回

核心函数是整个项目唯一需要读透的地方，二十来行，但每一行都对应一类输入。拆成三层看：进循环之前挡掉一批明显不合法的输入，循环里处理左括号和右括号两种角色，循环结束后还要补一刀判断栈是否为空。

3.1 映射表与入参校验：先把脏输入挡在门外

进循环之前的校验决定了这个函数在真实调用里稳不稳。判题环境永远给你一个“只含六种括号的字符串”，业务环境不会这么客气：可能传null，可能传数字，可能是用户粘贴的半截 JSON 里混着字母。

function isValid(s) { // 1) 类型校验：非字符串一律判非法，避免后续 s.length 报错 if (typeof s !== 'string') return false; // 2) 长度剪枝：合法串长度必为偶数，奇数长度不用进循环 if (s.length % 2 === 1) return false; const stack = []; // ...主循环 }

第一行typeof s !== 'string'挡的是null、undefined、数字、对象。这里有个取舍：要不要对null抛错而不是返回false？纯函数做布尔判定时返回false更省事，但如果这个函数被当成“前置守卫”用，抛错能更早暴露调用方的 bug。我个人倾向返回false，理由是括号校验本身是“输入是否合规”的判断，传错类型也算不合规的一种，语义上站得住。

第二行是常被忽略的剪枝。合法串里左右括号必然成对出现，字符总数一定是偶数；奇数长度直接返回，能省掉整整一次遍历。空串走的是s.length % 2 === 0这条分支，进循环一次都不转，最后stack.length === 0为真，返回true——空串算合法，这一点在后面的排查章会单独说，因为踩过的人不少。

3.2 主循环：左括号入栈、右括号比对，pop 的返回值就是答案

主循环是全文最值得细读的一段，短但每一句都有说法：

function isValid(s) { if (typeof s !== 'string') return false; if (s.length % 2 === 1) return false; const stack = []; for (let i = 0; i < s.length; i++) { const ch = s[i]; if (ch === '(' || ch === '[' || ch === '{') { stack.push(ch); // 左括号：只记录，不判断 continue; } if (ch === ')' || ch === ']' || ch === '}') { // pop 直接拿来比对：栈空时 pop 返回 undefined，天然不等于 '(' / '[' / '{' if (stack.pop() !== PAIRS[ch]) return false; continue; } // 出现六种括号之外的字符：严格模式直接判非法 return false; } return stack.length === 0; // 收尾：栈必须清空 }

第一个分支只做压栈，不做任何判断。这是栈写法最核心的一点：遇到左括号时你不知道它后面会跟什么，唯一能做的就是记住它，把判断推迟到遇见右括号。

第二个分支是整套逻辑的精华，stack.pop() !== PAIRS[ch]这一句同时覆盖了两种失败。栈空的时候pop()返回undefined，PAIRS[')']是'('，undefined !== '('成立，直接返回false——这就是“右括号多了”的场景，不用额外写if (stack.length === 0)。栈非空时pop()取到栈顶元素，如果类型对不上，比如栈顶是'['而当前是)，同样返回false——这就是“类型交叉”的场景，"([)]"卡在这一句。一行代码干掉两个分支，省了一行判断也少了一个出错点。

第三个分支处理“六种括号之外的字符”。这里有两种设计取向：严格模式直接返回false，宽松模式忽略跳过。这个函数默认走严格模式，理由是它被定位成“整个字符串是否是合法的括号序列”，混进其他字符本身就不合法。如果你的场景是“从一段混合文本里挑出括号部分校验”，宽松模式更合适，那需要改这一行，第 6 章会给出配置化的写法。

循环用for (let i = 0; i < s.length; i++)加下标，而不是for...of。对纯 ASCII 括号字符两者结果一样，但下标版本在你要返回错误位置的时候直接就有i可用；for...of按码点迭代，遇到代理对字符时拿到的“位置”和字符串索引对不上，后面扩展字符集时会咬人一口。

3.3 三条失败路径与一个必须走到末尾的判断

把上面的代码按失败时机归类，一共三条路径，缺一条就会漏判：

前两条在循环里就被return false拦掉了，第三条只能等循环全部跑完才知道。这解释了为什么最后一行必须是return stack.length === 0而不是return true：只要还有左括号留在栈里，就说明它们始终没等到对应的右括号，输入不合法。很多翻车现场就出在这一行——有人循环里判完就return true，结果"("被判成合法。

再往深一层，stack.length === 0这行还承担了“空串”的判定。空串不进循环，栈一直是空的，返回true。这个语义要和调用方对齐：空串算不算“有效的括号序列”？数学上空集满足任意全称命题，工程上空字符串通常视为“没有语法错误”，所以返回true是合理的。但如果你的调用方把空串当作“用户什么都没填”要单独报错，那这一层就得在外面拦，别改这个函数。

4. 跑通与验证：Node 环境下的执行、断言表与耗时观察

代码写完了得能跑。这份脚本没有任何依赖，Node 装好就能执行，但要真正验证它对不对，光跑一两个用例没用，得有一张覆盖所有失败路径的用例表。这一章给两种跑法、一套表驱动测试，外加一段大输入下的耗时观察方法。

4.1 两种跑法：命令行直跑与模块引入

最直接的方式是把文件存成valid-parentheses.js，加一段入口代码，命令行执行：

// 文件末尾追加：直接 node 执行时才会跑这一段 if (require.main === module) { const samples = ['()', '()[]{}', '(]', '([)]', '{[]}', '(', ')', '']; for (const s of samples) { console.log(JSON.stringify(s), '=>', isValid(s)); } }

node valid-parentheses.js # "()" => true # "()[]{}" => true # "(]" => false # "([)]" => false # "{[]}" => true # "(" => false # ")" => false # "" => true

require.main === module这个判断的作用是隔离：文件被别的模块require进来时这段不执行，只有node 文件名直接跑时才执行。没有它，测试用的console.log会混进业务日志里，属于典型的“自己能跑，别人集成完一堆输出”的问题。

第二种跑法是当模块引：

// 在业务代码里 const { isValid } = require('./valid-parentheses'); // 表单提交前的语法预检查 const expr = form.get('expression'); if (!isValid(expr)) { throw new Error('括号不匹配，请检查输入'); }

引入方式简单，但要注意路径和模块类型。如果项目是 ESM（package.json里有"type": "module"），require会直接报错，得改成import isValid from './valid-parentheses.js'，而且导入路径必须带扩展名。

4.2 表驱动测试：把 20 个用例压进一个数组

手写一个个if断言太啰嗦，标准做法是表驱动：把输入和期望值放进数组，跑一轮循环。

const assert = require('assert'); const { isValid } = require('./valid-parentheses'); const cases = [ // [输入, 期望值, 备注] ['()', true, '最小合法'], ['()[]{}', true, '三种类型并列'], ['{[]}', true, '嵌套合法'], ['([{}])', true, '三层嵌套'], ['(]', false, '类型交叉'], ['([)]', false, '嵌套顺序错乱'], ['{()', false, '左括号未闭合'], ['())', false, '右括号多余'], [')', false, '单右括号'], ['(', false, '单左括号'], ['', true, '空串'], ['((((((', false, '全左括号'], ['))))))', false, '全右括号'], ['(()())', true, '并列嵌套'], ['(()', false, '深度不闭合'], ['a(b)c', false, '混入非括号字符'], [null, false, '非字符串输入'], [123, false, '数字输入'], ]; let passed = 0; for (const [input, expected, note] of cases) { const actual = isValid(input); try { assert.strictEqual(actual, expected); passed++; } catch (e) { console.error(`FAIL: ${note} 输入=${JSON.stringify(input)} 期望=${expected} 实际=${actual}`); } } console.log(`${passed}/${cases.length} 通过`);

几点说明。assert.strictEqual用严格相等，避免1 == true这种宽松比较把true和1混过去。JSON.stringify(input)在打印时把null和字符串"null"区分开，比裸console.log清楚。用例表里[null, false]和[123, false]这两条专门测 3.1 那行类型校验，很多人写测试只测 happy path，边界一漏就白测。

表驱动的好处是加用例只需要加一行，不需要动测试逻辑。项目要扩展字符集（比如支持<>当括号）的时候，改完实现直接在表里加几行新用例，跑一遍就知道有没有破坏原有行为。

4.3 大输入下的耗时与内存：什么时候该关心

括号校验在某些场景下会被喂进大文本：整份 JSON、整个模板文件、几万行的配置文件。栈写法是 O(n) 的，理论上线性增长，但“线性”不等于“可以无视”。

// 生成一段 10 万字符的合法括号序列并计时 function bench() { const n = 50000; // 5 万对括号，共 10 万字符 const s = '('.repeat(n) + ')'.repeat(n); const t0 = process.hrtime.bigint(); const ok = isValid(s); const t1 = process.hrtime.bigint(); console.log('结果:', ok, '耗时:', Number(t1 - t0) / 1e6, 'ms'); console.log('堆内存:', (process.memoryUsage().heapUsed / 1024 / 1024).toFixed(2), 'MB'); } bench();

5 万对括号意味着栈的深度是 5 万，stack数组会存下 5 万个单字符字符串。这里有个容易被忽略的细节：JS 里从字符串取单个字符s[i]，得到的虽然是长度 1 的字符串，但 V8 有内部化（interning）优化，单字符通常共享，实际内存占用远小于 5 万个独立对象。所以这段代码的内存压力主要来自数组本身，不是来自字符串对象。

真正要注意的是极端深嵌套配合递归的场景。如果这个校验函数不是独立调用，而是被一个递归下降的解析器包着，深层嵌套会导致调用栈爆掉，报RangeError: Maximum call stack size exceeded。栈写法本身不递归，压力在数据不在调用栈，这是它相对递归写法的一个实实在在的优势。我在处理配置文件解析时更偏好这种一次遍历的非递归实现，就是为了把“递归深度”这个变量从系统里去掉。

5. 排查记录：五类括号匹配翻车现场与定位方法

这套逻辑不长，但翻车点不少，而且很多是“看起来对、边界错”。下面五条都是我或者周围人真实遇到过的，按现象、原因、解决写清楚。

5.1 输入侧的三次误判

一、空字符串被判成 false。现象：测试用例里['', true]一直失败，其他全过。原因：函数开头写了if (!s) return false;，本意是挡住null，结果""也是 falsy，被一并挡掉了。解决：把宽松真值判断换成类型判断if (typeof s !== 'string') return false;，空字符串是合法字符串，走正常流程自然返回true。这类问题的根子是 JS 的真值表里""、0、null、undefined、NaN全是 falsy，写守卫条件的时候必须明确你要挡的是哪一种。

二、全角括号导致整段判非法。现象：用户从文档里复制了一段配置，括号肉眼看没问题，程序判定全错。原因：中文输入法下打出的是全角（）、［］、｛｝，码点分别是 U+FF08、U+FF3B、U+FF5B，和半角括号完全不是一个字符。函数跑到第一个全角字符，落进“六种之外”的分支，直接return false。解决：两种思路，一是在校验前做一次归一化，把全角映射回半角；二是在错误返回里带上非法字符的位置和码点，让用户自己能看到问题在哪。我倾向后者，因为静默替换字符是有风险的，用户可能真的想输入全角。归一化的写法大致是：

// 只做常见全角括号到半角的映射，别用 NFKC 全量归一化 const FULLWIDTH_MAP = { '（': '(', '）': ')', '［': '[', '］': ']', '｛': '{', '｝': '}' }; function normalize(s) { return s.replace(/[（）［］｛｝]/g, (ch) => FULLWIDTH_MAP[ch] ?? ch); }

注意别图省事用s.normalize('NFKC')，那会把更多字符一起变形（比如全角数字、全角字母、连字），属于“为了解决一个小问题引入一堆新问题”。

三、代理对字符被拆开。现象：输入里混了 emoji，函数报错位置和用户在编辑器里看到的位置对不上。原因：s[i]按 UTF-16 码元索引，一个 emoji 占两个码元，下标i指向的是半个字符。如果代码里要把错误位置返回给编辑器做高亮，位置就会偏。解决：要么统一用for...of按码点迭代并且自己维护字符计数，要么在返回值里说明索引是“UTF-16 码元位置”而非“字符位置”，让前端自己换算。这个坑不致命，但排查起来很费时间，因为现象是“高亮位置差一格”，看着像编辑器的问题。

5.2 栈操作与性能的两个坑

四、pop之后又判断长度，出现差一错误。现象："([)]"被判成合法，其他交叉类型的也漏判。原因：写成stack.pop(); if (stack.length === 0 || stack[stack.length - 1] !== PAIRS[ch]) return false;。pop已经把栈顶移除了，再去取stack.length - 1取到的是下一个元素，比对对象整个错位。解决：直接用pop的返回值比对，if (stack.pop() !== PAIRS[ch]) return false;，一行搞定，也不需要额外判空——栈空时pop返回undefined，自然不等于任何左括号。这个写法还有个附加好处：不管从哪个分支返回，栈的状态都是“已经弹出”，不会留下脏状态。

五、用正则消消乐处理大文本，主线程卡死。现象：小数据没问题，用户粘贴一份几千行的 JSON 后页面卡三秒。原因：每轮replace只消一层，深层嵌套时轮数是嵌套深度，总成本 O(n²)，加上每轮都创建新字符串，GC 压力叠加。解决：换成栈实现，一次遍历到底。如果历史代码不好改，至少加个长度上限，超过阈值走异步或者直接拒绝，别在主线程上硬扛。我在浏览器侧处理用户输入时有个习惯：任何对输入长度的假设都要写进代码，比如if (s.length > 100000) return { ok: false, reason: 'input too long' }，比事后查性能问题省事得多。

6. 二次开发：把布尔值升级成带错误位置的可诊断返回

纯true/false在判题场景够用，在业务场景不够用。用户输入"{[}"你告诉他“括号不匹配”，他还是不知道该改哪。二次开发最值得做的第一件事，就是把返回值从布尔升级成带位置和期望值的结构；第二件事是把字符集从硬编码改成配置，让同一个校验器能覆盖尖括号、书名号甚至自定义配对。

6.1 返回结构改造：从 true/false 到 { ok, index, expect }

改造的核心是不提前返回，把错误信息收集起来再返回。栈的入栈出栈流程完全不变，只是在每个return false的位置多记一笔：

function validate(s) { if (typeof s !== 'string') { return { ok: false, index: -1, reason: 'not-a-string', expect: null }; } const stack = []; for (let i = 0; i < s.length; i++) { const ch = s[i]; if (ch === '(' || ch === '[' || ch === '{') { stack.push({ ch, index: i }); // 记住左括号的位置，报错时要用 continue; } if (ch === ')' || ch === ']' || ch === '}') { const top = stack.pop(); if (!top) { return { ok: false, index: i, reason: 'unexpected-close', expect: null }; } if (top.ch !== PAIRS[ch]) { // 关键：报的是“栈顶那个左括号”的位置，不是当前右括号的位置 return { ok: false, index: top.index, reason: 'mismatch', expect: PAIRS[top.ch] }; } continue; } return { ok: false, index: i, reason: 'illegal-char', expect: null }; } if (stack.length > 0) { const top = stack[stack.length - 1]; return { ok: false, index: top.index, reason: 'unclosed', expect: PAIRS[top.ch] }; } return { ok: true, index: -1, reason: null, expect: null }; }

改动看着多，其实就三处。栈里存的是{ ch, index }而不是裸字符，这样任何时候都能知道这个左括号是从哪来的。mismatch分支报的是top.index——栈顶左括号的位置，因为用户真正要改的是那个配错对的左括号，指到右括号上他会一头雾水。unclosed分支取stack[stack.length - 1]，报最后一个没闭合的左括号，通常也就是最内层那个，改起来最直接。

reason用短横线命名的字符串而不是数字码，是为了日志里可读、前端可以直接映射成提示文案而不用查表。expect只在需要“补一个什么字符”的时候有值，前端可以拼成“第 5 个字符处缺少]”这样的提示。

6.2 字符集配置化与流式分块校验的接法

字符集配置化很简单，把PAIRS和开括号集合变成参数：

// 工厂函数：传入配对表，返回一个校验器 function createValidator(pairs) { const openers = new Set(Object.values(pairs)); return function validate(s) { const stack = []; for (const ch of s) { if (openers.has(ch)) { stack.push(ch); continue; } if (ch in pairs) { if (stack.pop() !== pairs[ch]) return false; continue; } return false; } return stack.length === 0; }; } // 支持尖括号的版本 const validateWithAngle = createValidator({ ')': '(', ']': '[', '}': '{', '>': '<' });

注意配对表必须是“右括号 → 左括号”，方向反了整套逻辑全错。Object.values取出所有左括号建集合，加一种新括号只需要在传参时多一个键值对，实现代码一行不用动。

流式分块校验是另一个常见需求：大文件按块读进来，每块单独校验会出错，因为一个括号对可能跨块。正确的接法是让栈在块之间存活，每次只喂一块进去、只判断“当前块内有没有出错”，最后一块读完再看栈是否为空：

// 跨块复用同一个栈，块边界不影响正确性 function createStreamValidator(pairs) { const openers = new Set(Object.values(pairs)); const stack = []; return { feed(chunk) { for (const ch of chunk) { if (openers.has(ch)) { stack.push(ch); continue; } if (ch in pairs) { if (stack.pop() !== pairs[ch]) return false; continue; } return false; } return true; // 只是“到目前为止没错”，不代表整体合法 }, finish() { return stack.length === 0; }, // 收尾还得问一次 }; }

这里最容易翻车的是把feed的返回值当成最终结论。feed返回true只说明“这块没出错”，整个序列合不合法必须等finish()。我最初写流式版本时就漏了这一层，块边界刚好切在一对括号中间，最后一块返回true，调用方直接放行，脏数据就这么进去了。从那以后我每次做增量校验，都强制在接口上把「块内检查」和「整体收尾」拆成两个方法，名字上就不给人混淆的机会。希望这些细节能帮你少走一遍我走过的路。

本文还有配套的精品资源，点击获取