简介这份面向JavaScript初学者与算法刷题者的代码包聚焦有效括号序列判断这一经典题型帮助读者理解如何借助栈结构完成左括号入栈、右括号与栈顶配对、遍历结束后栈空校验等关键环节并体会空栈访问、类型不匹配和提前返回等边界处理。压缩包共两个文件以一份脚本核心实现和一份文本说明为主整体约八百一十八字节体量轻便适合直接阅读源码或在本机运行验证。已有三千四百二十八人学习说明该题在面试准备与基础训练中关注度较高。核心实现给出判断函数及多组测试用例通过配对映射简化圆括号、花括号、方括号三类符号的匹配判断读者可据此掌握线性时间复杂度的解题思路并迁移到表达式解析、模板语法校验等场景文本说明用于补充运行方式与理解上下文便于快速复现、调试和二次改写。1. 三十行 JS 代码判括号为什么很多人第一次提交还是红色的一段判断字符串是否有效的 JS 代码核心逻辑只有十几行遇到左括号就入栈遇到右括号就比对栈顶扫完再看栈是否为空。可就是这段代码在面试白板、在线判题和表单校验里被写错的比例高得离谱。思路并不是很难真正容易出错的是空串、单边括号、交叉嵌套这三类输入。这份资源提供的就是一份能直接跑起来的 JS 实现围绕(、)、{、}、[、]六种字符按「同类型闭合」和「正确顺序」两条规则判真假。它适合刚接触栈结构的新手跟一遍完整链路也适合想把括号校验放进配置编辑器、表达式解析器、模板语法检查里的老手直接拿走改。下面按「模型怎么立」「代码怎么跑」「参数怎么改」「坑在哪」四步推进每一步都给出可复制的代码块和失败时该看的地方。2. 栈模型的成立理由正则表达式判不了嵌套括号2.1 为什么正则表达式判不了括号嵌套先看一个常见想法括号匹配不就是查找成对的()、[]、{}吗用正则写一个^(\(\)|\[\]|\{\})*$不就完事了。对()、[]{}、()[]{}这类平铺输入确实能判对但只要出现嵌套例如([{}])这个正则就判不了。原因在于正则表达式背后的模型是有限状态机它没有「记忆」能力记不住「当前已经开了几层、每层是什么类型」。括号匹配属于上下文无关语言需要的是一个能压入和弹出的栈不是一张状态表。这也是为什么面试官喜欢拿它当栈的入门题它恰好卡在正则表达式的能力边界之外。实战中还有人用另一种「看起来不算正则」的办法反复替换最内层的成对括号直到替换不动为止。写法如下// 反复消除最内层成对括号能判对但代价高 function isValidByReplace(s) { const re /\(\)|\[\]|\{\}/g; // 只匹配最内层相邻成对 let prev; do { prev s; s s.replace(re, ); // 一轮只能消掉一层 } while (s ! prev); // 没变化说明消不动了 return s ; }这段代码的逻辑是(())第一轮变成()第二轮变成所以判定为有效。参数上re必须是全局标志g否则replace只换第一处循环条件会误判。但它的代价是每轮都要重扫整串深度为 d 的嵌套就要跑 d 轮整体接近 O(n²)。字符串长度一万、全嵌套的用例下它的耗时是栈解法的几十倍在线判题里很容易超时。所以这个方法只适合拿来做思路对照不要当成生产实现。2.2 栈的不变式扫描过程中的三条约束栈解法之所以可靠是因为它维护了一个可以随时验证的不变式扫描到第 i 个字符后栈自底向上保存的是所有尚未闭合的左括号且顺序与它们在字符串中出现的顺序完全一致。由这个不变式可以推出三条硬性约束后面所有的变体都从这里派生遇到右括号时栈顶必须是与之配对的左括号否则立刻判定非法因为「后开的先闭」这条顺序已经被破坏遇到右括号时如果栈为空说明这个右括号没有对应的左括号直接判定非法扫描结束后栈必须为空否则说明还有左括号悬着没闭。反过来说如果只有一种括号比如纯圆括号其实不需要栈一个计数器就够了因为不存在类型混淆只存在数量与顺序问题。三种括号并存时计数器无法区分「这个)该配(还是配别的东西」才必须上栈。这个区别在后面第 4 章讲变体时会反复用到。2.3 十二行核心实现逐行说明与参数含义把上面的不变式翻译成代码主体的实现如下function isValid(s) { // 右括号到左括号的反查表用对象比 if-else 链更好扩展 const pairs { ): (, ]: [, }: { }; const stack []; for (let i 0; i s.length; i) { const ch s[i]; // 1. 左括号一律入栈不做任何判断 if (ch ( || ch [ || ch {) { stack.push(ch); continue; } // 2. 右括号栈空即为「多余的右括号」先短路避免 pop 出 undefined if (stack.length 0) return false; // 3. 弹出栈顶比对类型不匹配立即失败 if (stack.pop() ! pairs[ch]) return false; } // 4. 收尾栈非空说明有左括号没闭合 return stack.length 0; }逻辑说明分四段。第一段把左括号无条件压栈因为左括号在任何位置都是合法的「待闭合」状态。第二段先判stack.length 0这个顺序不能调换——如果先pop()再比较空栈会返回undefined而undefined ! (恰好也返回false看起来结果是对的但真正的空栈错误被掩盖了换成自定义映射表就会翻车这是第 5 章要展开的第一个坑。第三段用pairs[ch]做反查比写三条else if更短也更容易在变体里换成Map。第四段的返回值必须是布尔表达式而不是return true否则(这种输入会被错判为有效。参数上s的约束是「只包含六种括号字符」这是题目前提。实际项目里如果输入可能带空格、注释、转义字符需要在函数外先做清洗或者按第 4 章的流式校验器处理。pairs表的键必须是右括号值必须是左括号写反了整段逻辑会全部反向。2.4 复杂度与必须覆盖的边界输入时间上每个字符最多被访问一次入栈出栈各一次是 O(n)空间最坏情况是整串都是左括号栈深度等于 n所以是 O(n)最好的情况是纯右括号第一次就返回空间 O(1)。有一处免费优化如果字符串长度是奇数直接返回false因为每对括号贡献两个字符。这一行在长输入下能省掉整趟遍历if (s.length % 2 1) return false; // 奇数长度不可能全部配对边界输入必须逐个覆盖漏一个就可能判错输入期望考察点true空串是否算有效按题目定义算)false空栈遇右括号(false收尾栈非空()true最小有效单元([)]false数量对但顺序错计数器法必错(([]){})true多层嵌套加并列(){}}{false中途提前闭合后多余右括号其中([)]是最有价值的一条它左右括号数量都是 2任何只做计数的实现都会判成有效而它恰恰是栈结构的试金石。3. 本地运行零依赖环境从单文件到用例集3.1 环境准备与文件骨架这份代码没有依赖任何第三方库用原生 JS 就能跑。本地验证的常见做法是装个 Node16 及以上都行栈实现没用到新语法然后建一个单文件node -v # 确认 Node 可用16 均可 mkdir bracket-check cd bracket-check touch valid.js # 单文件即可不需要 package.json node valid.js # 直接运行内置自测文件骨架要让同一个文件既能被别的模块引用又能直接执行自测关键是require.main module这个判断// valid.js导出 直接运行时执行自测 function isValid(s) { /* 第 2 章的实现原样放这里 */ } module.exports { isValid }; if (require.main module) { // 只有 node valid.js 时才走进来被 require 时不执行 const cases [[, ], [(), ()], [([)], ([)]]]; for (const [name, input] of cases) { console.log(name, , isValid(input)); } }require.main module的含义是「当前文件是不是进程入口」。少了这个判断别人require(./valid.js)的时候你的测试代码也会跟着跑一遍在单元测试里会输出一堆噪音。module.exports导出的是对象而不是裸函数是为了将来往里追加validateWithIndex、createValidator等变体时不破坏调用方。3.2 用例集用断言把七条边界固定下来手敲console.log看输出只能验证一次改用assert把期望值写死改代码后重跑就能立刻发现退化// cases.js边界用例 断言驱动 const assert require(node:assert); const { isValid } require(./valid); const table [ [, true], [), false], [(, false], [(), true], [([)], false], [(([]){}), true], [(){}}{, false], ]; for (const [input, expected] of table) { assert.strictEqual(isValid(input), expected, 用例失败: ${JSON.stringify(input)}); } // 深层嵌套构造 5000 层验证栈没有被递归或字符串拼接拖垮 const deep (.repeat(5000) ).repeat(5000); assert.strictEqual(isValid(deep), true); // 长串交叉模拟真实文本里大量短括号对 const wide ()[]{}.repeat(2000); assert.strictEqual(isValid(wide), true); console.log(全部用例通过);assert.strictEqual用严格相等避免0 false这类隐式转换把错误吞掉。第三个参数是失败时的提示信息把输入原样打出来非常关键——JSON.stringify能让你看见空串和空格的区别直接拼字符串会看不出来。深层嵌套那条用例是为了验证空间复杂度5000 层意味着栈里会同时存在 5000 个元素如果实现里用了递归这里会直接抛RangeError: Maximum call stack size exceeded。长串交叉那条则是验证实现没有意外的 O(n²) 行为跑一遍如果明显卡顿说明某处做了字符串拼接或数组复制。注意跑之前把s.length % 2 1的优化打开长串用例能快一截。3.3 查表、switch、码点差值三种写法怎么选核心实现里的pairs[ch]是最通用的写法但在高频调用场景下还有人会用码点差值或switch。三者的差别值得说清楚因为选错了会在某些输入上出错。码点差值法的依据是配对的两个括号在 ASCII 表里相邻或隔一位。(是 40、)是 41差 1[是 91、]是 93差 2{是 123、}是 125差 2。所以只要判断当前字符减去栈顶是否属于{1, 2}即可function isValidFast(s) { const stack []; for (let i 0; i s.length; i) { const c s.charCodeAt(i); // 取码点比 s[i] 少一次字符串分配 if (c 40 || c 91 || c 123) { stack.push(c); continue; } const top stack.pop(); if (top undefined) return false; // 空栈遇右括号 const diff c - top; if (diff ! 1 diff ! 2) return false; } return stack.length 0; }这段比对象查表快原因是charCodeAt返回的是小整数栈里存的也是整数没有字符串比较和哈希查找。但它有两个前提必须写进注释输入只含六种半角括号以及不做类型映射。如果传进来一个字母a码点 97它会走到else分支去弹栈把合法状态破坏掉最后给出一个看似合理实则错误的答案。所以在真实项目里用它之前要么保证输入已经过白名单过滤要么在函数开头加一行/^[\(\)\[\]\{\}]*$/.test(s)兜底。switch版本介于两者之间可读性最好但每个字符都要走一次分支判断在百万级字符上比码点法慢。我的习惯是判题和脚本用对象查表追求可读被高频调用的校验器比如编辑器每次按键都跑一遍才换码点法并且把白名单校验固定在上面。3.4 三种调用方式OJ 提交、浏览器控制台、ESM 引入同一份代码在不同环境里的用法差别不小容易出错的是 OJ。在线判题平台通常只让你填函数体不让你写module.exports也不让你读标准输入。把第 2 章那段isValid原样贴进去就行多写一行导出语句有些平台会直接报语法错误。另一个常见问题是输入解析如果题目给的是「第一行一个整数 n接下来 n 行字符串」自己用readline拼解析逻辑时很容易把行尾的\r带进字符串导致最后一个字符判错。浏览器控制台和 ESM 场景下改成具名导出即可// valid.mjsESM 形式浏览器 script typemodule 也能直接用 export function isValid(s) { const pairs { ): (, ]: [, }: { }; const stack []; for (const ch of s) { // for...of 对 ASCII 括号安全 if (ch in pairs) { if (stack.pop() ! pairs[ch]) return false; } else { stack.push(ch); } } return stack.length 0; }这里把判断顺序倒过来了先看是不是右括号ch in pairs否则当左括号压栈。这样写更短代价是「非括号字符」会被当成左括号压进去最后判非空时返回false——在题目约束下没问题但接到真实输入上必须先把非括号字符滤掉。for...of按码点迭代处理代理对比如某些表情符号比s[i]安全不过对括号这种单字节字符两者等价。4. 参数与变体把判定器改成项目里真正要用的样子4.1 括号对做成配置表支持自定义符号固定写死六种括号在很多场景下不够用模板引擎里有% %某些配置语言里有 还有的项目要求同时支持全角括号。把括号对抽成参数只改一处就能扩展function makeValidator(openList, closeList) { if (openList.length ! closeList.length) { throw new Error(左括号表与右括号表长度必须一致); } const openSet new Set(openList); const closeToOpen new Map(); for (let i 0; i openList.length; i) { closeToOpen.set(closeList[i], openList[i]); } return function validate(s) { const stack []; for (const ch of s) { if (openSet.has(ch)) { stack.push(ch); } else if (closeToOpen.has(ch)) { if (stack.pop() ! closeToOpen.get(ch)) return false; } // 其他字符直接忽略便于校验带文本的模板片段 } return stack.length 0; }; } // 用法在标准括号基础上加一对全角括号 const validate makeValidator([(, [, {, ], [), ], }, ]);参数的含义要说清楚openList和closeList必须按位置一一对应第 i 个左括号配第 i 个右括号长度不等直接抛错而不是静默容错——这种配置错误越早暴露越好。用Set和Map而不是普通对象是为了避开原型链上的键比如输入字符恰好是constructor虽然括号字符不可能撞上但换成自定义符号后就不一定了。函数用闭包返回配置只解析一次反复调用时不会重复建表。这是把「配置」和「执行」分开的典型写法也是这个资源最值得复用的结构。4.2 返回值从布尔升级成首个错误位置只返回true/false在校验场景里不够用——用户在编辑器里写错一个括号你需要告诉他错在第几个字符、期望的是什么。把返回值改成对象成本很低function validateWithIndex(s) { const map { ): (, ]: [, }: { }; const rev { (: ), [: ], {: } }; // 反向表用来提示「期望字符」 const stack []; for (let i 0; i s.length; i) { const ch s[i]; if (rev[ch]) { stack.push({ ch, i }); // 记下位置报错时要用 continue; } if (!map[ch]) continue; // 非括号字符跳过 const top stack.pop(); if (!top) return { ok: false, reason: unexpected-close, index: i, char: ch }; if (top.ch ! map[ch]) { return { ok: false, reason: mismatch, index: i, char: ch, expect: rev[top.ch], openAt: top.i }; } } if (stack.length) { const first stack[0]; // 报最外层未闭合的因为它是「最早」的 return { ok: false, reason: unclosed, index: first.i, char: first.ch, expect: rev[first.ch] }; } return { ok: true }; }关键设计有三点。reason用固定枚举值而不是中文描述方便前端按类型做不同高亮。index一律指向「出问题的那个字符」多余的右括号指向它自己类型不匹配指向右括号未闭合指向最早的左括号——这三种指向方式必须统一否则前端划线会错位。expect和openAt是给提示文案用的能拼出「第 12 个字符处期望]与之配对的[在第 3 个字符」。stack[0]报最外层而不是栈顶这一点容易被忽略(((这种输入栈顶是最后一个(但用户真正该补的是最外层那个因为补完外层可能整段就对了。4.3 单一括号类型计数器写法与它的适用边界如果确定只会出现圆括号比如某些表达式语法里只用圆括号分组可以不用栈一个计数器就够空间降到 O(1)function isValidParenOnly(s) { let depth 0; for (const ch of s) { if (ch () depth; else if (ch )) { depth--; if (depth 0) return false; // 中途变负说明右括号多了 } } return depth 0; }这段的逻辑是「深度不能为负、结束必须归零」。depth 0的检查放在递减之后顺序不能反否则第一次遇到)时会漏判。它的性能优势明显但不适用于混合括号([)]在它眼里深度变化是 1→2→1→0返回true而正确答案是false。这个例子在第 2 章出现过一次在第 5 章还会以另一种形式再出现因为它是这类实现最典型的失败点。4.4 流式校验分块输入下的状态保持编辑器、日志管道这类场景拿不到完整字符串只能一块一块喂进来。这时候栈必须活在闭包里不能每次调用重建function createStreamValidator() { const pairs { ): (, ]: [, }: { }; const stack []; let failed false; return { feed(chunk) { if (failed) return false; // 已失败的流不再继续消费 for (const ch of chunk) { if (ch ( || ch [ || ch {) stack.push(ch); else if (pairs[ch]) { if (stack.pop() ! pairs[ch]) { failed true; return false; } } } return true; }, end() { return !failed stack.length 0; }, depth() { return stack.length; }, // 暴露深度方便 UI 显示嵌套层级 }; }failed标志位是必须的一旦判定失败栈已经被pop破坏后续feed继续跑会给出无意义的结果所以要把失败状态固定住让整个流提前结束。end()单独成一个方法而不是在最后一个feed里判空是因为调用方不一定知道哪一块是最后一块。depth()是顺手加的能力做语法高亮时用来决定缩进层级成本几乎为零。5. 避坑与排查五类实际出错场景下面这五条都是从实际调试里总结出来的每条按「现象 → 原因 → 解决」写。它们有一个共同点代码不报错答案却是错的比直接抛异常难查得多。5.1 空栈 pop 出来的 undefined 恰好不匹配现象把映射表从对象换成Map之后)这类输入返回的结果从false变成了true代码一行没改只改了数据结构。原因[].pop()返回undefinedundefined ! (结果为true于是if (stack.pop() ! pairs[ch]) return false能正确返回。但换成Map后写成了stack.pop() ! map.get(ch)而map.get())在表里没配好时也返回undefined两个undefined相等判断被绕过。本质是「空栈」和「不匹配」两种错误共用了一个返回值。解决把空栈判断独立出来放在pop之前让两种错误有各自的出口。改成if (stack.length 0) return false;再pop比对两条路径就彻底分开了。这条也适用于任何「用返回值表示多种错误」的场景。5.2 forEach 里的 return 退不出循环现象想在遇到不匹配时立刻返回false于是写了s.split().forEach(ch { if (...) return false; })结果函数最后返回undefined判题系统报「返回值类型错误」。原因forEach的回调里的return只是结束当次回调等价于continue不影响外层。而且forEach本身没有返回值回调里return false传不出去。这不是括号题特有的问题只是在需要「提前中断」的遍历里特别容易出错。解决换成for...of或经典for循环这两者支持return、break、continue。如果非要用数组方法用some/every并把返回值传出去const bad chars.some(ch ...)。我一般的习惯是只要函数体里可能出现提前返回就不用forEach。5.3 忘记收尾判空半个括号被判成有效现象(、(([])这类输入返回true。测试里如果只写了()和([)]完全发现不了。原因循环里只处理了「右括号多余」和「类型不匹配」两种情况漏掉了「扫描结束栈里还有东西」这第三种。第三种是唯一一种在循环结束后才能发现的错误很容易在写代码时被忘掉。解决函数最后一行必须是return stack.length 0;不能写return true。对应的用例一定要包含只由左括号组成的字符串长度分别为 1、2、3。另外把「奇数长度直接返回false」的优化加上后(会因为长度是奇数被提前挡掉但这只是掩盖问题——((长度是偶数照样能测出漏判所以这条用例不能省。5.4 全角括号与不可见字符看起来一样码点不一样现象从文档里复制了一段带括号的配置粘进校验框明明括号都成对校验却返回false。把字符串console.log出来肉眼看不出任何区别。原因中文输入法下打出来的是全角括号码点和半角的()完全不同另外复制粘贴还容易带进零宽空格、\u00A0不换行空格、行尾\r。这些字符在等宽字体里几乎看不出来但它们既不在左括号集合里也不在右括号集合里会被当成「其他字符」忽略或者被当成左括号压栈。解决入口处先做一次规范化把全角括号映射成半角、把不可见字符替换掉再进校验器。查问题时用[...s].map(c c.codePointAt(0).toString(16))把整串码点打出来比肉眼看快得多。有一个细节要记住六种半角括号的码点是 40、41、91、93、123、125只要输出里出现ff08、ff09这类值就是全角。5.5 递归写法在深层嵌套下直接栈溢出现象本地小用例全过线上遇到一段深层嵌套的模板就抛RangeError: Maximum call stack size exceeded日志里看不出来是哪一步。原因有人把括号匹配写成递归——遇到左括号就递归处理到对应的右括号为止。这种写法逻辑上没错但递归深度等于嵌套层数几千层就能打爆调用栈。JS 引擎的栈深度限制跟运行环境有关本地开发机可能扛得住容器里就未必。解决改成迭代加显式栈把递归深度转成数组长度数组可以到几百万。如果已经写成递归又不想大改至少要做深度上限保护进入递归前判depth 10000就返回错误让失败可控。压测时构造(.repeat(5000) ).repeat(5000)这种用例跑一遍能提前暴露问题。6. 接入真实校验流程两道保护和一次回归把这段代码放进项目里我一般会加两道保护。第一道是入口规范化全角转半角、去掉零宽字符和\r用一个normalize(s)单独承担这样校验器本身只处理干净输入责任清晰。第二道是超长截断超过设定长度比如一万字符直接拒绝并返回原因避免一段异常输入把编辑器主线程卡住。回归测试则用一张固定用例表固定下来每次改动校验器都跑一遍层级用例目的单元、(、)、([)]固定基础分支结构5000 层嵌套、()[]{}重复两千次防止复杂度退化输入清洗全角括号串、带\r\n的串防止编码问题回流这三层里最容易被跳过的是第三层因为它看起来跟算法无关。我踩过一次校验器本身没问题但从富文本编辑器复制过来的内容里混进了零宽字符用户反复粘贴都提示「括号不匹配」排查了半天才发现是输入层的问题。从那以后我每次接这类校验器都强制走一遍「码点打印 固定用例回归」先把输入洗干净再谈算法。希望帮到你。本文还有配套的精品资源点击获取