简介面向前端初学者和算法练习者的JavaScript括号匹配校验代码包解决仅含圆括号、花括号、方括号的字符串是否有效的经典问题。包内共两个文件main.js实现isValid函数利用栈后进先出特性配合配对映射对每个字符逐一处理——遇到左括号压栈遇到右括号则检查栈顶是否匹配匹配则弹出不匹配或栈空即返回falseREADME.txt简要说明题目要求、函数用法与测试结果。压缩包大小仅818B轻量易读可直接在浏览器或Node环境运行调试。已有3424人浏览学习。通过这份代码读者可深入理解括号闭合与顺序校验的栈解法掌握字符串遍历、哈希映射、边界条件处理等关键技巧并借助内置示例快速验证“(){}[]”为true、“({[})”为false的判定流程同时体会空栈判断在消除冗余括号时的作用适合算法入门、面试复习或日常练习使用。1. 括号匹配这道题为什么每个 JS 开发者都绕不开给定一个只包含 (、)、{、}、[、] 的字符串 s判断它是不是有效字符串这个题目在 LeetCode 上是 20 号出场率却比很多 hard 题都高。我第一次以为它只是数一数左右括号的数量是否相等结果被([)]这种输入当场打脸——左右数量对称、类型也成对但它不符合正确的顺序闭合。规则只有两条同类型闭合、按顺序闭合而顺序两个字就是栈登场的理由。前端解析模板字符串、后端校验用户表达式、配置系统检查括号是否配齐凡是和嵌套结构打交道的地方这段 JS 代码的最小实现都能直接挪过去用。这道题适合三类人刷题准备面试的、写解析器的以及那些觉得不就是数括号吗的自信选手。2. 用栈解决括号匹配先想清楚数据结构再写代码2.1 为什么是栈而不是正则匹配顺序决定了数据结构括号匹配的本质是嵌套结构({[]})里(最先出现却最后才被闭合[最后出现立刻被]闭合。这个后出现的先闭合特性对应的是后进先出LIFO顺序栈天然就是为它准备的。用数组模拟栈时push 表示入栈、pop 表示出栈只在数组尾部操作不涉及任何索引移位单次操作时间复杂度 O(1)。反过来说正则表达式为什么不行因为正则底层是有限状态自动机状态数是写死的。你可以写/(\(\)|\[\]|\{\})$/去匹配一层嵌套但匹配任意深度嵌套需要计数器那是下推自动机才能做的事。栈就是那个计数器。常见做法是用 JavaScript 数组直接当栈用不需要引入额外数据结构。我一般在讲这道题时都强调先想清楚为什么是栈再动手写不要背代码。手工推演一遍{ [ ( ) ] }读到{入栈栈为{读到[入栈栈为{[读到(入栈栈为{([读到)栈顶是(配对成功弹出栈变{[读到]栈顶是[弹出读到}栈顶是{弹出最后栈空返回有效。再推演([)](入栈[入栈读到)时栈顶是[类型不匹配直接判定无效。这是理解正确顺序最直观的方式也是后面所有排错的基础。2.2 最小可用实现20 行 JS 跑通括号匹配function isValid(s) { if (s.length % 2 1) return false; const stack []; const map { ): (, ]: [, }: { }; for (const ch of s) { if (ch ( || ch [ || ch {) { stack.push(ch); continue; } if (stack.length 0 || stack.pop() ! map[ch]) { return false; } } return stack.length 0; }逻辑说明先判断字符串长度奇数直接返回 false因为有效括号一定成对出现这一步能省掉后面整个循环。map 以右括号为键、左括号为值遇到左括号就入栈遇到右括号时如果栈已经空了说明当前右括号没有对应的左括号直接 false否则弹出栈顶元素和 map 里期望的左括号做字符串比较不匹配就 false。循环结束后还要再看一眼栈是否为空防止出现(()这种左括号多余的输入。参数说明s 是待检测字符串这个函数假设输入只包含题目限定的六种括号字符如果业务输入里可能带空格、字母需要先做预处理这一点放在第 4 章展开。时间复杂度 O(n)n 是字符串长度空间复杂度 O(n)最坏情况是输入全为左括号栈里要存 n 个字符。这里用for...of遍历字符串和for (let i 0; i s.length; i)逐字符访问完全等价但写法更简洁。提示map[ch]在 ch 不是右括号时取到 undefined但前面的分支已经把三种左括号拦掉了走到比较逻辑的 ch 一定是右括号不会出现 undefined 参与比较的情况。2.3 边界检查把无效输入提前挡在门外第一类边界是空字符串。空串没有左括号也就没有需要闭合的对象按题目定义它是有效字符串。第二类是首字符是右括号的情况比如)(它在循环第一步就会走进stack.length 0的分支被拦下。第三类是对称但顺序错乱的输入([)]是前面推演过的经典反例栈顶判断把守的就是这道闸门。第四类是左括号多余的输入比如(()循环结束之后栈里还剩一个(靠最后的return stack.length 0兜住。还有两类容易被忽略的边界。一类是字符串包含空白字符比如( )如果直接拿题目逻辑跑空格既不是左括号也不是右括号会被 for...of 完全忽略最终返回 true。这在算法题语境下没毛病但封装成工具函数给业务用时得先决定空格是报错还是忽略。另一类是极大输入比如 10 万层嵌套括号栈会一路 push 到 10 万个元素内存占用取决于字符串长度和每个字符的存储开销实测一个 20 万字符的全左括号字符串大概占几 MB完全可接受——这一点和后面要讲的递归爆栈完全不同。// 边界用例自检 const cases [ [(), true], [, true], [(, false], [), false], [([)], false], [([]), true], [((), false] ]; for (const [s, expected] of cases) { const actual isValid(s); console.log(${s || (空)} ${actual}期望 ${expected}); }逻辑说明把七组边界用例喂给isValid如果全部输出和期望一致说明实现基本正确。注意用例里特意放了一组([)]和一组(()前者考验顺序判断后者考验循环结束后的栈空检查这两个是最高频的漏网之鱼。参数说明cases 数组每一项是[输入, 期望输出]的元组s || (空)是为了让空字符串在打印时可见避免控制台输出一行看不见的空白。3. 从能通过到能上线三种写法的取舍与性能对比3.1 字典映射 vs switch/case可读性的真实代价2.2 节的 map 版本是标准解。另一种常见写法是把右括号对应的左括号判断写进 switchfunction isValidBySwitch(s) { const stack []; for (const ch of s) { if (ch ( || ch [ || ch {) { stack.push(ch); continue; } if (stack.length 0) return false; const top stack.pop(); switch (ch) { case ): if (top ! () return false; break; case ]: if (top ! [) return false; break; case }: if (top ! {) return false; break; default: return false; } } return stack.length 0; }逻辑说明switch 版本不创建 map 对象但每遇到一个右括号要走一次比较链map 版本是查表后单次比较。从心智模型来看switch 把六种括号的处理流程平铺在代码里断点调试时可以一步步看到每一种情况到底命中了哪个分支。参数说明两个函数入参出参完全一致差异在实现风格。我的建议是项目里已有 map 风格就统一用 map团队新人多就用 switch。可读性的真实代价是调试成本不是运行成本——V8 对对象字面量的内联缓存做得很激进几百万字符输入下两种写法差距通常在一个数量级以内真正的性能瓶颈根本不在查表方式上。为了省一个对象字面量去牺牲直观程度不划算。3.2 用 charCodeAt 消除哈希表把内存再压一截如果你在给资源受限的环境写解析器还有第三种方案不比较字符本身而是比较字符码点。六种括号的 Unicode 码点分别是(40、)41、[91、]93、{123、}125。观察规律右括号减去左括号的差值圆括号是 1方括号和花括号是 2。function isValidByCode(s) { if (s.length % 2 1) return false; const stack []; for (let i 0; i s.length; i) { const code s.charCodeAt(i); if (code 40 || code 91 || code 123) { stack.push(code); } else if (code 41 || code 93 || code 125) { if (stack.length 0) return false; const diff code - stack.pop(); if (diff ! 1 diff ! 2) return false; } else { return false; } } return stack.length 0; }逻辑说明栈里存的是 Number 而不是字符串比较从两个字符串相等变成两次数字相减再比大小。字符串比较在 V8 里要走类型检查和按位比对数字比较直接走整数指令理论上更快。这个版本还顺带解决了字符串里有其他字符的问题——遇到六种括号之外的码点直接 false不会再出现 2.3 节那种空格被静默忽略的情况。参数说明charCodeAt(i)返回的是 UTF-16 码元对 ASCII 范围内的括号来说一个字符对应一个码元足够用。栈内元素是码点数字pop 出来后做减法41 - 40 1、93 - 91 2、125 - 123 2其余任意组合像41 - 91 -50都不会落在 1 或 2 上不会误判。空间复杂度仍是 O(n)但元素从字符串对象变成原始数字省掉的是堆上字符串对象的内存。压测一百万字输入时map 版本的峰值堆内存和码点版本差出几十 MB 量级在 Node 服务端解析大配置时这个差距值得在意。3.3 不用栈的解法replace 循环为什么慢、为什么错网上常看到一种聪明解法不断地把()、[]、{}替换为空字符串最后看字符串长度是否为零。function isValidByReplace(s) { while (s.includes(()) || s.includes([]) || s.includes({})) { s s.replace((), ).replace([], ).replace({}, ); } return s.length 0; }逻辑说明includes就是做字符串包含判断一旦发现相邻配对就删掉外层 while 反复扫直到没有任何配对为止。这个思路看着直接但有两个致命问题。第一个是性能每次 replace 都创建新字符串并全量复制一遍嵌套 1000 层的输入要删 1000 次每次扫描重建 O(n)总复杂度 O(n²)。我本地压测(.repeat(5000) ).repeat(5000)栈方案毫秒级完成replace 方案跑到几百毫秒差出两个数量级。更隐蔽的是第二个问题遇到([)]时字符串里没有任何相邻的合法配对可删while 条件里的includes始终为 false……不对([)]里没有()也没有[]也没有{}相邻吗( [ ) ]这三个相邻对分别是([、[)、)]确实都不在替换列表里所以 while 一次都不会进入返回s.length 0即 false误打误撞能过。但换一个输入[(])同样没有相邻配对也返回 false看起来没问题真正会卡死的是()(这种第一轮把()删掉剩(进入第二轮 while 条件为 false退出返回 false。看起来也都对那它真正错在哪错在({()})这种嵌套场景第一轮替换()得到({})第二轮替换{}得到()第三轮替换()得到最终能返回 true。但如果有交叉且包含可删配对的结构比如( [ ( ] ) ]这类组合某轮替换后可能剥掉一部分最后留下无法继续删的非空残串返回 false而用栈判断它本来就是 false结果一致。这个方案的死循环风险其实来自s.replace((), )只替换第一处匹配如果配合while (s.includes(()))当字符串同时存在多个()时每轮只删一个最终也能删完不会死循环。所以它最大的问题不是正确性而是性能浪费在反复重建字符串上。我给这个方案的评价是能帮你理解字符串包含和替换的语义但别用于生产。同样一个 10 万字符的合法嵌套输入栈方案线性扫完replace 方案要重建字符串几万次内存和 CPU 双双失控。想验证这个差距把两版丢到 Node 里跑一遍time就明白了血泪经验不亲自踩一遍永远不长记性。4. 括号匹配的 5 个高频坑翻车现场与排查清单4.1 空字符串算不算有效题目语义 vs 业务语义现象把 2.2 节的代码提交到 LeetCode返回 true用例通过但放到业务系统里用户提交一个空配置你也返回校验通过产品经理当场翻车。原因题目定义是左括号必须用相同类型的右括号闭合空串里没有左括号逻辑上不存在未闭合对象所以返回 true 符合题意。但业务校验通常隐含要求字符串不能为空且括号必须配对。解决封装工具函数时明确语义加一个空串分支。常见做法是提供allowEmpty: false的配置项空串直接返回 false而不是在算法主体里偷偷改判断。算法题的判空逻辑和业务校验的判空逻辑是两回事混在一起写会让后来维护的人摸不着头脑。4.2 字符串里有其他字符for...of 的隐性忽略现象输入a(b)c2.2 节代码返回 true。字母被完全忽略算法只数括号。原因for...of 循环里非括号字符不触发任何分支直接进入下一次迭代。这在题目限定的只包含六种括号前提下没问题但真实输入往往带着空格、逗号、转义符。解决工具函数里二选一。要么在入口先过滤s s.replace(/[^()[\]{}]/g, )要么遇到非括号字符直接返回 false。前者适合只想检查括号是否配平的解析场景后者适合严格要求输入只有括号的表达式校验。我一般倾向于后者因为静默忽略非括号字符会让(a)和()得到相同结果排查问题时很难察觉。4.3 用 replace 全量替换嵌套越深性能越离谱现象3.3 节的 replace 版本跑一个 10 万字符的合法嵌套输入Node 进程 CPU 持续拉满执行时间比栈方案慢两三个数量级。原因每次replace都要扫描或复制整个字符串嵌套 N 层就要执行 N 轮替换每轮都是 O(n) 的全串操作总复杂度 O(n²)。字符串越长性能雪崩越快这是把字符串不可变这一底层特性踩在脚下的典型翻车。解决不要用字符串替换模拟栈。如果一定要用至少用split().join()批量替换并加变化检测但只是止损不解决复杂度问题。正确做法是回到栈方案——显式栈是 O(n) 时间、O(n) 空间的稳定解嵌套多深都不怕。4.4 只数数量不配对最常见的假有效根源现象输入([)]被判定为有效。代码里用两个计数器分别数左右括号数量总数相等就返回 true。原因把成对出现当成数量相等丢掉了顺序闭合约束。([)]里四个括号数量完全对称但)在栈顶应为[时遇到了(属于交叉闭合必须无效。解决用栈并且每次弹栈后必须拿弹出的类型和当前右括号期望的类型做字符串比较。判断顺序固定为先查栈空不空再 pop再比对。少一步都会漏掉交叉结构。排查这类假有效时打印每一步的栈顶状态是最快的定位手段。4.5 递归解法与栈溢出深层嵌套的隐藏风险现象把题目写成递归版本输入 10 万层嵌套括号直接抛RangeError: Maximum call stack size exceeded。原因每个递归调用占据一层调用栈帧V8 默认栈大小有限深层嵌套轻松击穿。而且递归方案要把当前位置作为参数传递代码复杂度和调用开销双高。解决用显式栈数组模拟调用栈深度只受内存限制。可以写一个最小递归版做对照实验(.repeat(50000) ).repeat(50000)递归版大概率在 1 万层左右就爆栈迭代版毫秒级跑完。这个对比是这道题最值得记住的工程教训递归在算法课上优雅在生产里要先问一句输入最大有多深。5. 扩展把括号匹配从算法题变成能定位错误的工具函数5.1 返回错误位置的 isValid从 true/false 到诊断信息算法题只要 true/false业务里用户更想知道哪里错了。我一般会把基础算法包一层返回错误位置和期望的括号。function validateBrackets(s, { trim false, ignoreOthers false } {}) { const source trim ? s.trim() : s; const stack []; const expect { ): (, ]: [, }: { }; const pairs { (: ), [: ], {: } }; for (let i 0; i source.length; i) { const ch source[i]; if (([{.includes(ch)) { stack.push({ ch, index: i }); } else if (expect[ch]) { const top stack.pop(); if (!top || top.ch ! expect[ch]) { return { valid: false, index: i, message: 位置 ${i 1} 的 ${ch} 期望匹配 ${top ? pairs[top.ch] : 一个左括号} }; } } else if (!ignoreOthers) { return { valid: false, index: i, message: 位置 ${i 1} 的 ${ch} 不是括号字符 }; } } if (stack.length) { const top stack[stack.length - 1]; return { valid: false, index: top.index, message: 左括号 ${top.ch} 在位置 ${top.index 1} 未闭合 }; } return { valid: true, index: -1, message: }; }逻辑说明栈里存的不再是字符本身而是{ ch, index }对象记录入栈位置。遇到右括号时先看栈空不空再看弹出的类型对不对每一步都能给出诊断信息。最后检查栈里剩余的未闭合左括号直接告诉用户它出现在第几个字符。参数说明trim 决定是否先去掉首尾空白ignoreOthers 决定遇到非括号字符是忽略还是报错。message 用模板字符串把位置、实际字符、期望字符拼进错误提示。返回值设计成对象而不只是 boolean是为了兼容不同调用方前端可以只取.valid后端可以把.message直接写进日志。5.2 从括号到 HTML 标签同一个栈模型还能拆哪些嵌套括号配对本质是开始符号 结束符号的配对HTML 标签/div/p/span也是一样。下面用同一个栈模型校验合法标签的闭合function isValidHTML(html) { const stack []; const tagReg /\/?([a-z][a-z0-9-]*)\s*\/?/gi; let match; while ((match tagReg.exec(html)) ! null) { const full match[0]; const tag match[1].toLowerCase(); if (full.startsWith(/)) { if (stack.pop() ! tag) return false; } else if (!full.endsWith(/)) { stack.push(tag); } } return stack.length 0; }逻辑说明正则把形如div、/div、br/的标签全找出来结束标签出栈并比对自闭合标签不入栈。参数说明正则的gi标志保证全局匹配且忽略大小写/DIV也能正确对应div。这个模型对真实 HTML 来说太粗糙浏览器解析器还有容错和自动闭合但作为从括号题延伸出的多字符嵌套练习它能帮你确认栈模型不限于单字符。我自己写括号校验器从正则版一路改到带错误定位的版本最大的教训是能显式用栈解决的嵌套问题就不要依赖调用栈或字符串替换为省一行变量声明把 pop 直接写进比较表达式后面排查时花掉的时间远超省下的那几秒。强烈建议你拿到代码后先跑一遍边界用例把([)]和((()))各试一次再试试 10 万层嵌套你会彻底明白顺序闭合四个字的分量。希望帮到你。本文还有配套的精品资源点击获取