基于栈的括号匹配校验：从算法到可复用JS模块

简介：这份资源面向JavaScript初学者与算法练习者，聚焦括号匹配这一经典字符串处理问题，帮助读者理解如何借助栈结构判断仅含圆括号、花括号、方括号的字符串是否有效。压缩包共2个文件，以js代码文件与txt说明文档为主，包体约818B，其中js文件给出isValid函数的完整实现与测试用例，txt文档用于补充运行与调试说明。已有3426人学习下载，适合用来对照理解左括号按序闭合、右括号匹配栈顶等核心逻辑。读者可从中获得可直接运行的参考代码、配对关系映射的写法以及边界情况处理思路，便于在刷题或面试准备中快速验证与复用。

1. 括号匹配校验：从一道字符串题到一个能跑起来的 JS 校验模块

上周排查一个配置解析的线上问题时，日志里报错的位置指向一段 JSON 片段，肉眼看着括号都对得上，实际却少了一个闭合符号。当时我就想，与其靠眼睛数括号，不如把「判断括号字符串是否有效」这件事做成一个能直接调用的 JS 模块。这份代码资源干的就是这件事：给定一个只包含(、)、{、}、[、]六种字符的字符串s，判断它是否有效——左括号必须用相同类型的右括号闭合，且必须以正确顺序闭合。它适合正在刷算法题想对照实现的人，也适合需要在表单校验、表达式解析、配置检查里复用一段可靠括号校验逻辑的前端或 Node 开发者。下面我按「它怎么设计、怎么跑、怎么改」把这份代码拆开讲。

2. 核心算法拆解：栈结构如何保证括号顺序正确

2.1 为什么这道题非栈不可

先想清楚问题的本质。括号有效性有两个约束：类型匹配和顺序正确。类型匹配好办，遇到右括号时看它和最近的左括号是不是一对；难的是「最近的左括号」这个语义——([)]里)最近的左括号是(，类型对不上，所以无效；([])里]最近的左括号是[，匹配，剥掉之后()再匹配，整体有效。这种「后进先出」的访问顺序，正好是栈的定义。

用计数器行不行？只处理一种括号时可以，遇到左括号加一、右括号减一，最后看是否归零。但三种括号混在一起，计数器就分不清([)]这种交叉嵌套了。用正则反复替换()、[]、{}直到字符串不再变化，也能做，但每轮都要重新扫描全串，复杂度是 O(n²)，长字符串下性能会翻车。栈是 O(n) 时间、O(n) 空间的最优解，也是这道题的标准答案。

我一般会把算法拆成三个判断点，写代码时对着检查：遍历中遇到右括号，栈必须非空且栈顶是配对的左括号；遍历结束后，栈必须为空。这两个条件缺一不可，前者管顺序和类型，后者管「左括号有没有全部闭合」。

2.2 用映射表消灭 if-else 分支

最直白的写法是遇到)就判断栈顶是不是(，遇到]判断是不是[，三个分支写下来又长又容易漏。更干净的做法是建一张右括号到左括号的映射表，查表一次搞定：

// 右括号 -> 对应左括号的映射，查表替代多分支判断 const PAIRS = { ')': '(', ']': '[', '}': '{' }; function isValid(s) { // 奇数长度一定无效，提前返回，省掉一次完整遍历 if (s.length % 2 !== 0) return false; const stack = []; for (const ch of s) { if (ch === '(' || ch === '[' || ch === '{') { // 左括号直接入栈，等待后续右括号来配对 stack.push(ch); } else { // 右括号：栈空说明没有可配对的左括号，直接判无效 // 栈顶不等于映射值说明类型或顺序错误 if (stack.length === 0 || stack.pop() !== PAIRS[ch]) { return false; } } } // 遍历结束栈必须为空，否则说明有左括号没闭合 return stack.length === 0; }

这段代码有几个细节值得说。s.length % 2 !== 0的提前返回是性价比很高的一步：有效字符串的左括号和右括号数量必然相等，总长度一定是偶数，奇数直接出局，省掉整趟遍历。for...of遍历字符串而不是用下标，是因为它按 Unicode 码点迭代，虽然本题字符都是 ASCII，但养成这个习惯在处理含代理对的字符串时不会踩坑。

stack.pop() !== PAIRS[ch]这一行把「栈空判断」和「类型匹配」合并了：stack.length === 0时短路，不会执行pop()；否则弹出栈顶和映射值比较。注意pop()是有副作用的，弹出即删除，所以这个比较必须一次完成，不能先peek再pop。如果输入里混入了非括号字符，PAIRS[ch]是undefined，pop()出来的左括号不等于undefined，会返回false——这其实是个合理的防御行为，但如果你希望「忽略非括号字符」，就得在循环开头加一层过滤，这个改造放到最后一章讲。

2.3 复杂度与边界用例清单

时间上每个字符最多入栈出栈各一次，O(n)；空间上最坏情况全是左括号，栈深度 n，O(n)。这道题没有比这更优的通用解法，别在面试或代码评审里纠结「能不能 O(1) 空间」，除非输入有特殊结构。

边界用例我整理成一张表，写完代码对着跑一遍，基本能覆盖绝大多数翻车场景：

空串返回true这点常有人争论，从「所有左括号都被正确闭合」的定义看，空串没有未闭合的括号，判有效是自洽的。如果你的业务场景要求非空，在函数入口加一句if (!s) return false;即可，别改算法主体。

3. 工程化落地：把算法封装成可复用校验模块

3.1 目录结构与模块划分

单文件贴一个函数能跑，但要在项目里复用，就得考虑导出方式、错误信息和测试。我按常见的前端工具模块习惯拆成三个文件：

bracket-validator/ ├── src/ │ ├── index.js # 对外入口，导出 isValid 和 validate │ └── pairs.js # 括号映射表与字符分类常量 ├── test/ │ └── isValid.test.js # 边界用例测试 └── package.json

pairs.js单独放映射表，是为了让「哪些字符算括号」这个配置集中在一处，将来要支持<>尖括号或者自定义配对符，只改这个文件。index.js导出两个函数：isValid返回布尔值，适合条件判断；validate返回结构化的校验结果，带错误位置，适合给用户提示。这种「一个纯判断、一个带诊断」的双导出模式，我在表单校验和配置解析里用得最多。

3.2 带错误定位的 validate 实现

线上排查问题时，光知道「无效」不够，还得知道「第几个字符出的问题」。validate在栈里存字符的同时存下标，出错时把位置带出来：

import { PAIRS, OPENERS } from './pairs.js'; // 返回 { valid, index, message }，index 为出错字符下标，-1 表示无错误 export function validate(s) { const stack = []; // 元素形如 { ch, index } for (let i = 0; i < s.length; i++) { const ch = s[i]; if (OPENERS.has(ch)) { stack.push({ ch, index: i }); continue; } if (!(ch in PAIRS)) continue; // 非括号字符跳过，不参与校验 if (stack.length === 0) { return { valid: false, index: i, message: `位置 ${i} 出现多余的右括号 '${ch}'` }; } const top = stack.pop(); if (top.ch !== PAIRS[ch]) { return { valid: false, index: i, message: `位置 ${i} 的 '${ch}' 与位置 ${top.index} 的 '${top.ch}' 不匹配` }; } } if (stack.length > 0) { const top = stack[stack.length - 1]; return { valid: false, index: top.index, message: `位置 ${top.index} 的左括号 '${top.ch}' 未闭合` }; } return { valid: true, index: -1, message: 'ok' }; }

和isValid相比，这里有三处工程化改动。第一，栈元素从字符变成{ ch, index }对象，多存一个下标，代价是每个元素多占一点内存，换来的是精确的错误定位，值得。第二，用OPENERS这个Set判断左括号，比三次===比较可读性更好，元素多了也不怕。第三，非括号字符用continue跳过而不是判无效——这是业务校验和算法题的分歧点：算法题保证输入只有六种字符，业务里用户可能粘贴带空格、逗号的表达式，跳过更实用。

message的措辞我特意写成「位置 X 的某字符与位置 Y 的某字符不匹配」，因为用户看到这句话能直接定位到原文，比「括号不匹配」这种笼统提示省一轮沟通。参数上index返回的是出错字符的下标，前端可以拿它做高亮，比如把输入框里第 i 个字符标红。

3.3 跑起来：Node 与浏览器两种验证方式

这份代码不依赖任何框架，Node 环境直接跑：

# 进入项目目录，初始化并安装测试依赖 cd bracket-validator npm init -y npm install --save-dev vitest # 运行测试 npx vitest run

package.json里加一行"type": "module"，就能用上面的import语法。测试文件里把 2.3 节的边界用例表逐条写成断言：

import { describe, it, expect } from 'vitest'; import { isValid } from '../src/index.js'; import { validate } from '../src/index.js'; describe('isValid', () => { const cases = [ ['()', true], ['()[]{}', true], ['(]', false], ['([)]', false], ['{[]}', true], ['(', false], [')', false], ['', true], ['(((', false] ]; cases.forEach(([input, expected]) => { it(`输入 ${JSON.stringify(input)} 应返回 ${expected}`, () => { expect(isValid(input)).toBe(expected); }); }); }); describe('validate', () => { it('交叉嵌套应定位到出错下标', () => { const r = validate('([)]'); expect(r.valid).toBe(false); expect(r.index).toBe(2); // 第三个字符 ')' 出错 }); });

浏览器里验证更简单，把src下两个文件用<script type="module">引入，或者用任意打包工具打成单文件，在控制台调isValid('{[]}')看返回值。我习惯先在 Node 里把测试跑绿，再往浏览器搬，因为 Node 的报错栈更干净，排查算法问题不受 DOM 干扰。

提示：validate里ch in PAIRS判断的是对象自有及原型链上的键，PAIRS是普通对象字面量，in会命中toString这类原型属性。虽然本题字符集里不会出现这些键，但严谨起见可以把PAIRS用Object.create(null)创建，或者改用Map。这个坑我在别的项目里真踩过，输入里混进特殊键名时行为诡异。

4. 避坑与排查：括号校验里最容易翻车的五个点

4.1 现象：([)]被判为有效

原因：只做了类型匹配没做顺序校验，比如用三个计数器分别统计三种括号的数量，数量相等就返回true。([)]里三种括号各一对，计数器全归零，但顺序是错的。

解决：回到栈结构，右括号必须和「最近一个未闭合的左括号」配对，而不是和「任意一个同类型左括号」配对。用 2.2 节的映射表写法，pop()出来的必须是栈顶，天然保证顺序。

4.2 现象：输入")"时抛异常而不是返回false

原因：右括号分支里直接stack.pop()再比较，栈空时pop()返回undefined，undefined !== '('虽然也能得到false，但如果代码写成stack.pop().ch就会抛Cannot read properties of undefined。

解决：弹栈前先判stack.length === 0，短路返回false。顺序上「先判空、再弹栈、后比较」不能颠倒，这是血泪经验，颠倒一次线上就是 500。

4.3 现象：长字符串校验耗时异常

原因：用了正则反复替换的写法，while (/\(\)|\[\]|\{\}/.test(s)) s = s.replace(...)，每轮全串扫描，嵌套深度大时退化成 O(n²)。

解决：换栈实现，一趟遍历 O(n)。如果历史代码不好动，至少加个长度上限保护，超过阈值走异步或分片，别在主线程里同步跑几十万字符的替换循环。

4.4 现象：含空格或逗号的表达式被误判无效

原因：算法题版本假设输入只有六种括号字符，业务输入里常有( a, [b] )这种带其他字符的表达式，非括号字符走进右括号分支，PAIRS[ch]为undefined，直接判无效。

解决：循环里先判断字符是否属于括号集合，不属于就continue跳过。3.2 节的validate已经这么处理了，isValid如果也要用于业务，同样加这层过滤，别直接拿算法题版本上线。

4.5 现象：测试全绿但线上仍报错

原因：测试用例只覆盖了题目给的示例，没覆盖空串、单字符、纯左括号、纯右括号这些边界。更隐蔽的是输入类型不对，传了null或undefined，s.length直接抛错。

解决：函数入口加类型防御，if (typeof s !== 'string') return false;，测试用例按 2.3 节的表补全。我现在的习惯是每写一个纯函数，先把边界表列出来再写实现，顺序反过来容易漏。

5. 二次开发：从判有效到可配置的括号校验器

把这份代码往业务里搬，最先要改的是「括号集合写死」这件事。模板引擎要校验{{ }}，某些配置格式用<>，硬编码六种字符就不够用了。我的改法是让配对关系从参数传入，默认值保持题目语义：

// 支持自定义配对符，默认三种圆方花括号 export function createValidator(pairs = { ')': '(', ']': '[', '}': '{' }) { const openers = new Set(Object.values(pairs)); return function check(s) { if (typeof s !== 'string') return false; const stack = []; for (const ch of s) { if (openers.has(ch)) { stack.push(ch); } else if (ch in pairs) { if (stack.pop() !== pairs[ch]) return false; } } return stack.length === 0; }; } // 用法：校验双花括号模板 const checkTemplate = createValidator({ '}}': '{{' }); checkTemplate('{{ name }}'); // true

这里有个容易忽略的点：多字符配对符（比如{{和}}）用单字符遍历是处理不了的，上面的写法只适用于单字符配对。真要支持多字符，得改成基于 token 的扫描，或者先把多字符配对符替换成占位单字符再校验。我一般会跟需求方确认清楚，绝大多数场景单字符够用，别为了一个罕见需求把算法复杂度抬上去。

另一个改造方向是「容错修复」而不是「判无效」。用户粘贴一段少了个右括号的配置，与其报错，不如告诉他「建议在第 12 个字符后补一个}」。实现思路是在栈非空时，把栈里剩余的左括号逐个映射成右括号，拼成补全建议返回。这个功能我在一个配置编辑器里做过，用户接受度很高，但要注意补全位置可能有多种合理答案，返回第一个即可，别追求唯一解。

验证改造是否正确的办法还是测试先行。每加一种配对符，就往用例表里补三行：一对有效、一个类型错、一个顺序错。跑绿了再合并，别靠手动在控制台敲几个字符串就下结论。

最后说个我自己的教训。早些年我觉得这种「一道算法题」的代码没什么好封装的，直接复制粘贴到需要的文件里，结果同一个项目里散落了四个版本的括号校验，其中一个忘了判栈空，用户输入单个)就白屏。从那以后我每次把这类小算法往业务里搬，都强制走一遍「抽成独立模块 + 边界用例测试 + 类型防御」的流程，宁可多花二十分钟，也不留四个副本互相打架。希望这份拆解帮到你，拿去跑通、改顺，再按自己的业务场景把配对符和错误提示调成合适的形状。

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