简介：这份JavaScript代码面向算法初学者、前端开发者及面试备战人群，解决的是经典的“括号匹配”问题：给定仅含 '('、')'、'{'、'}'、'['、']' 的字符串，判断其是否满足同类型闭合和正确顺序两个条件。实现思路围绕栈这一“后进先出”数据结构，遍历时左括号入栈、右括号与栈顶比对，若遇到空栈或类型不匹配则立即返回无效，逻辑简洁而清晰，是理解JavaScript字符串处理与数据结构结合的入门范例。压缩包内共有2个文件，核心为一个js主文件，其中包含完整的isValid函数和两组简单测试用例；配套的txt说明文件则简述问题背景与代码使用方式。整个压缩包仅818B，非常轻量。目前已有3424人学习下载。借助这份代码，读者可快速掌握栈在字符串对称匹配中的应用，还能借鉴其处理边界情况的写法，直接迁移到表达式校验、代码编辑器语法检查等相关场景，无论是学习、练习还是二次修改都很有帮助。
1. 有效字符串判断：用 JS 的栈把括号匹配从「看着对」变成「可证明对」
很多前端朋友都刷过这道有效字符串判断，但真正把它用到生产代码的人不多。去年我接了个内部配置校验的小工具，用户提交的配置里嵌套了各种括号，我需要判断字符串是否有效——不是数数量对就完事，而是左括号必须用同类型右括号闭合，顺序还必须正确。这个朴素的括号匹配问题，用 js 写最稳的数据结构是栈，而不是正则替换。下面会把原理、实现、边界坑和验证方法一次讲清，既适合准备面试的初学者，也适合要给编辑器做自动闭合、给配置做校验的从业者。核心就一句：先想清楚「栈」为什么是对的，再动手写码。
2. 为什么栈是括号匹配的唯一正确解：先想清楚再写码
2.1 括号闭合的「先入后出」特性：从嵌套到匹配的单调性
括号的嵌套关系和生活中的排队不一样，更像一摞盘子：你要用最上面的盘子，就得先把后来的、放在它上面的盘子全拿走。字符串从左往右扫描，遇到一个左括号时，你并不知道它对应的右括号会在多远之后出现，只能把它记在一个“待办清单”里。遇到右括号时，需要匹配的却是清单里最近加入的那个左括号。这个“最近加入、最先处理”的顺序，就是计算机里的先入后出，缩写叫 LIFO，栈的天生语义。
拿({[]})这个经典嵌套串来走一遍。扫描到(时入栈，扫描到{时入栈，扫描到[时入栈，此时栈从底到顶是( { [。接着读到第一个右括号]，它必须匹配栈顶的[，匹配成功后弹出；再读到}，栈顶是{，弹出；最后读到)，栈顶是(，弹出。整个过程就是“观察栈顶 → 比较类型 → 弹出”的循环。你会发现，括号匹配的本质不是数数，而是维护一个“最近未闭合左括号”的单调序列。
这种特性在真实场景里非常普遍。比如代码编辑器里的自动闭合括号，当用户输入一个右括号时，编辑器要检查的就是光标前最近的那个未闭合括号是不是同类型。再比如运行时函数的调用栈，函数 A 里调 B，B 里调 C，那么 C 必然先返回，然后 B 返回，最后 A 返回，完全符合先入后出。所以括号匹配并不是一道“为了考而考”的面试题，它是理解栈这个数据结构的极简模型。如果你能把({[]})的 push/pop 过程在草稿纸上画出来，后面写代码就不容易出错。
还有一个很容易被忽略的点：有效字符串的长度必然是偶数。每一个左括号都要有一个右括号对应，所以如果字符串长度是奇数，可以直接判 false。这不是什么玄学，是先入后出匹配必然成对出现的结果。很多人会忘记在最前面加这个快速判断，但说实话这个判断不影响正确性，只影响性能。真正影响正确性的是下面要说的两种错误思路。
2.2 两种常见错误思路：正则替换和「计数平衡」，以及它们为什么不行
第一种错误思路是循环使用正则替换。我见过有同事直接这么写：
function isValidByReplace(s) { while (s.length > 0) { const before = s.length; s = s.replace(/\(\)|\[\]|\{\}/g, ''); if (s.length === before) { return false; } } return true; }这段代码的逻辑是把所有相邻的成对括号删掉，然后再扫描一遍，直到删不动为止。比如(()，第一次替换删掉中间的()，剩下(，长度不再变化，返回 false，看着很合理。但问题有二。第一是复杂度，每次replace都要从头到尾扫描整个字符串并生成新字符串。输入是 10 万个((((...))))时，虽然逻辑上最终能删完，但每一轮扫描的字符串长度几乎不变，整体复杂度会退化到 O(n²)。第二，它只适合“字符串里只有括号”的裸串，一旦字符串里混了普通字符，这个正则就会误伤，因为replace只会删掉紧挨着的()，如果中间隔着字母，就永远删不掉。
第二种错误思路更隐蔽，是“左右括号数量相等”。很多初学者会写这样一个计数器版本：
function isValidByCount(s) { let opens = 0; for (const ch of s) { if ('([{'.includes(ch)) { opens++; } else if (')]}'.includes(ch)) { opens--; } if (opens < 0) { return false; } } return opens === 0; }这个版本对只有一种括号的字符串有效，比如(()())可以正确判断。但对三种括号混合的([)]，opens 一路上升到 3，再降到 2，再升到 3，再降到 2，最后降到 0，函数返回 true，而题目要求的是左括号必须以正确顺序闭合，正确答案应该是 false。如果改成三个计数器分别计三种括号，([)]每种各一个，数量照样相等，还是会返回 true。这说明一个残酷的事实：数量只描述了括号的“总账”，没有描述嵌套的“时序”。而顺序信息必须用显式的栈来保留。
为什么说栈是唯一正确解？因为每一次右括号出现时，我们需要的唯一信息是“最近一个未闭合的左括号是什么”，这正好是栈顶。JavaScript 数组的push和pop在尾部操作，都是 O(1) 的时间，整个算法只需要一趟扫描，时间和空间都是 O(n)。相比之下，正则替换要先编译正则、再反复扫描字符串，计数逻辑则会丢失顺序。所以遇到这个题目，别想别的，先写出一个栈，任何“我可以用更聪明的方法”的念头，在遇到([)]这种用例时都会被打回原形。
3. 用 JavaScript 实现有效字符串判断：最小可跑版本与参数拆解
3.1 用 Map 建立配对关系，写出第一个栈实现
有了栈的语义，代码其实很直白。我建议用Map来保存“右括号 → 左括号”的配对关系，而不是写一堆 if/else。下面是我在生产环境里用到的最小实现，加了一些注释方便你逐行对照：
function isValid(s) { // 奇数长度直接返回 false：括号必然成对出现 if (s.length % 2 === 1) { return false; } const stack = []; const pairs = new Map([ [')', '('], [']', '['], ['}', '{'], ]); for (const ch of s) { if (pairs.has(ch)) { // ch 是右括号，弹出栈顶并检查是否同类型 const top = stack.pop(); if (top !== pairs.get(ch)) { return false; } } else { // ch 是左括号，入栈等待匹配 stack.push(ch); } } // 全部匹配完后，栈必须为空 return stack.length === 0; }这段代码的逻辑很清晰：用pairs.has(ch)判断当前字符是不是右括号。如果是，就pop出栈顶的左括号，和pairs.get(ch)期望的左括号比较；如果不相等，说明出现了交叉或类型不匹配，直接返回 false。如果不是右括号，那在题目约束下它一定是左括号，直接入栈。最后一行检查栈是否为空，这一步不能省，否则输入((时，循环结束栈里还压着两个左括号，函数会错误地返回 true。
这里有几个参数值得说明。s是输入字符串，在题目中只会包含六种括号字符；但如果你要复用到真实场景，建议先对s做一层预处理，比如s.trim()去掉首尾空白。pairs这个 Map 的 key 必须全部是右括号，value 是匹配的左括号。有人习惯反过来写，把左括号当 key，那在遇到右括号时就需要额外的查找逻辑，代码会绕一些。另外注意stack.pop()在空栈时返回undefined，而pairs.get(ch)永远是一个字符串，两者永远不相等，所以当字符串以右括号开头时，这个比较会自然让isValid(')')返回 false，不需要单独写空栈判断。
时间复杂度是 O(n)，每个字符最多入栈一次、出栈一次；空间复杂度也是 O(n)，最坏情况是字符串全是左括号，比如((((((，所有字符都压在栈里。这个复杂度对任何能满足题目的算法来说已经是理论最优，因为你至少要读一遍字符串才能知道它长什么样。
3.2 遍历字符串的三种写法：for-of、传统 for 循环、spread 展开，性能与可读性对比
上面代码里用的是for...of循环，这是我最推荐的写法，因为它不需要关心索引，直接拿到每个字符，正文代码也最干净。但实际工作中，根据项目性能要求，你可能需要换一种遍历方式。下面三种写法都能跑，区别在细节。
// 写法一：for...of（可读性最优） function isValidA(s) { const stack = []; const pairs = new Map([[')', '('], [']', '['], ['}', '{']]); for (const ch of s) { if (pairs.has(ch)) { if (stack.pop() !== pairs.get(ch)) return false; } else { stack.push(ch); } } return stack.length === 0; } // 写法二：传统 for 循环（索引访问，V8 里通常最快） function isValidB(s) { const stack = []; const pairs = new Map([[')', '('], [']', '['], ['}', '{']]); for (let i = 0; i < s.length; i++) { const ch = s[i]; if (pairs.has(ch)) { if (stack.pop() !== pairs.get(ch)) return false; } else { stack.push(ch); } } return stack.length === 0; } // 写法三：spread 展开转数组 + forEach（可读但多一次拷贝） function isValidC(s) { const stack = []; const pairs = new Map([[')', '('], [']', '['], ['}', '{']]); let result = true; [...s].forEach(ch => { if (!result) return; if (pairs.has(ch)) { if (stack.pop() !== pairs.get(ch)) result = false; } else { stack.push(ch); } }); return result && stack.length === 0; }三种写法执行的是同一个逻辑，差异主要体现在几个地方。for...of在 JavaScript 层面按迭代器取字符，对代理对（emoji 之类）也能正确遍历，但对纯 ASCII 括号来说没有差别。传统 for 循环用s[i]直接索引，现代 V8 引擎对字符串索引做了优化，性能通常略高，但代码看起来更“老派”，而且如果你习惯用charAt(i)，就会比s[i]慢一点点，因为charAt是方法调用。spread 展开会先把字符串转成字符数组，如果字符串长度是几十万，这一步会额外开辟一块内存，瞬间拉高空间占用。forEach本身不能中断，所以还得用一个result标志位做提前退出，这又给函数增加了状态，可读性反而下降。
我的建议是，如果你写的代码会在浏览器里跑，优先for...of；如果这是一个 Node.js 服务里被高频调用的热路径，比如每毫秒都要校验一次用户输入，那就用传统 for 循环，并把s.length缓存到局部变量里，避免循环条件里重复读属性。至于 spread 版本，我基本不用，因为它既没有性能优势，又给“提前返回”这种常规操作制造障碍。想要“一行代码”解法的人可能喜欢 spread + reduce，但我会在最后一章专门讲为什么我不用那种写法。
还有一个容易搞混的点：在循环里判断字符是不是左括号时，很多人习惯写'([{'.includes(ch)。这可以工作，但includes这个方法名字容易让人误以为它是判断“字符串是否包含某个字符”的，用在热循环里会引入一次线性查找。虽然这里只有三个字符，查找很快，但如果你用pairs.has(ch)，在 Map 里查找是 O(1)，语义也更明确：判断当前字符是不是右括号。所以同一个操作，我会把“判断这一位是不是某个右括号”的任务交给pairs.has，而不是'([{'.includes。这样代码的意图是“如果它能在 pairs 里找到，那它就是右括号”，读代码的人不用去数字符串里到底有哪些左括号。
4. 有效字符串判断的 5 个坑：我在这道题上翻过的车
4.1 空字符串和奇数长度：顺手加的“优化”反而害了你
现象：有同学在函数第一行写if (s.length === 0) return false;，理由是“空字符串没有任何括号，怎么能叫有效”。结果跑用例，空串直接挂掉，因为题目里通常会注明“空字符串可被视为有效字符串”。
原因：题目里的有效定义并不要求字符串必须包含括号，它只要求“如果一个左括号出现，那么它必须被同类型右括号闭合”。空字符串里没有左括号，所以这个条件天然满足。这个边界值在很多算法题里都容易踩，因为人的直觉会倾向认为“空的就是无效的”。
解决：不要对空串做特殊处理，让算法自然走到最后一步return stack.length === 0。空串时循环没执行，栈是空数组，长度是 0，返回 true，正好符合题意。如果你确实面向的业务要求“至少有一对括号才算有效”，那应该在调用层判断，而不是在这个函数里加死规则。至于奇数长度快速判断s.length % 2 === 1，这是安全的，因为奇数长度的字符串成对必然失败，这个优化不会改变结果。
4.2 字符串里混入空格或换行：题目没提不代表你遇不到
现象：从配置文件读出的字符串可能带缩进，比如" ( { } ) "，直接用题目里的“只包含六种括号”的假设来写，遇到空格时既不是左括号也不是右括号，代码把它当作左括号 push 进栈，然后后续括号匹配会错乱，最终返回 false。可业务上希望忽略空格。
原因：题目为了聚焦算法，把输入约束成“只包含六种括号”，这是为了让你不要纠结数据清洗。但接真实数据时，这种约束基本不存在，配置里必然有缩进、换行、逗号，甚至中文字符。
解决：看你的业务到底要不要忽略非括号字符。如果要忽略，最稳妥的做法是在函数入口先过滤一遍：s = s.replace(/[^(){}\[\]]/g, '')，只保留六种括号，再走栈逻辑。如果你希望严格校验“括号之间不能有任何其他字符”，那你就得保持原样，遇到非括号字符直接 return false。这个决策必须在函数文档注释里写清楚，否则下一个人接手时，会把你的严格版改成容错版，或者反过来，然后测试用例又开始飘。
4.3 漏掉最后一步检查栈是否为空：((被判成有效
现象：很多第一次写栈实现的人，循环里处理得很爽，遇到右括号就对栈顶，遇到左括号就入栈，最后直接return true;。结果测试((时返回了 true。
原因：循环只保证了“每一个右括号都找到了它想要的左括号”，但没保证“所有左括号都被右括号闭合”。“栈不为空”就直接意味着还有左括号没等到它的另一半。这个错误极其隐蔽，因为单测用例如果只覆盖()、([])这种肯定能过的字符串，根本触发不了这个分支。
解决：把最后一行写成return stack.length === 0;，一个字都不能省。我一般会在写完函数后，立刻用三个用例自测：((、))、(()()。这三个用例分别覆盖“左括号多”“右括号多”“左右数量相同但顺序不对”的情况。只要这三个都返回 false，漏检栈空的问题就能被堵住。
4.4 Map 的记忆方向：把右括号映射到左括号，否则永远匹配不上
现象：有人写const pairs = new Map([['(', ')'], ['[', ']'], ['{', '}']]);然后在遇到右括号时const expect = pairs.get(top)，试图从栈顶左括号取期望的右括号。这逻辑也能通，但遇到栈顶是undefined时，pairs.get(undefined)会给你一个奇怪的报错，而且代码风格越写越绕。
原因：我理解这样写的动机，是想让“key 是左括号”更符合人的直觉，但算法里我们是以右括号为触发条件的：看到右括号才需要查配对。更自然的设计是用右括号作 key，左括号作 value，然后pairs.get(ch)得到的直接是“期望匹配的左括号”，和stack.pop()的结果进行!==比较，不需要任何二次查找。
解决：统一用[右括号, 左括号]这样的二元组建 Map。如果你是从左括号往右括号映射，那么请把比较逻辑改成if (ch !== pairs.get(top))，但这样在top === undefined时会比较ch和undefined，虽然也能返回 false，但语义不清晰，容易让同事以为你漏掉了空栈判断。既然有更直接的写法，就不要给自己埋小地雷。这个细节看着小，却是我见过最多的代码风格翻车点。
4.5 用 replace 循环处理长字符串：O(n^2) 的翻车现场
现象：项目早期有人用.replace(/\(\)|\[\]|\{\}/g, '')循环消除成对括号，处理几百个字符的配置还能用，后来配置文件涨到几万字符，接口响应时间从 20ms 涨到 800ms，直接超时。
原因：如第 2 章所分析的，replace每次都要把整个字符串扫描并重建。对一个深度嵌套的字符串，比如一万层括号，第一轮扫描能消掉最内层的一对，第二轮消掉次内层，最坏情况要跑一万轮，总共扫描一亿个字符。而栈只需要一次遍历加一次弹栈，无论嵌套多深都只有一个循环。
解决：没有别的办法，把 replace 循环换成栈实现。这是唯一能根治的解法。如果你在优化旧代码，可以先用一个小的 benchmark 脚本对比：生成一个 10 万字符的全嵌套字符串，跑替换版和栈版，看看执行时间差几个数量级。这种踩坑经验我是实打实付过学费的，从那以后，但凡遇到字符串处理算法，我会先算清复杂度，再写第一行代码。
5. 从「通过用例」到「可信赖」：边界测试与变体扩展
5.1 用 Node 写一个断言脚本，把所有边界用例钉死在代码里
只写一个isValid函数并手动调用几次，远不能证明代码没问题。我习惯把这道题的用例子做成一个可重复执行的断言脚本，直接用 Node 内置的assert模块，不需要引入任何测试框架。下面是完整的测试文件，假设isValid已经被定义：
const assert = require('assert'); function isValid(s) { if (s.length % 2 === 1) return false; const stack = []; const pairs = new Map([ [')', '('], [']', '['], ['}', '{'], ]); for (const ch of s) { if (pairs.has(ch)) { if (stack.pop() !== pairs.get(ch)) return false; } else { stack.push(ch); } } return stack.length === 0; } const cases = [ // [输入, 期望结果, 说明] ['', true, '空字符串'], ['()', true, '单层圆括号'], ['()[]{}', true, '并列三种括号'], ['(]', false, '圆括号内放方括弧是类型错误'], ['([)]', false, '交叉闭合'], ['{[]}', true, '多层嵌套'], ['(', false, '只有一个左括号'], [')', false, '只有一个右括号'], ['(()', false, '左括号多出'], ['())', false, '右括号多余'], ]; for (const [input, expected, desc] of cases) { const actual = isValid(input); assert.strictEqual(actual, expected, `${desc}: ${input}`); } console.log('all passed');这段脚本用assert.strictEqual严格比较布尔值，每个用例后面的第三个参数是失败时打印的提示信息，方便一眼看出是哪个场景挂了。我特别推荐把“说明”这一列写上，因为几个月后你回来看测试，可能已经不记得([)]到底意味着什么，而'交叉闭合'这四个字能立刻唤醒记忆。运行方式很简单，在终端执行node test.js，看到输出all passed就说明全部通过。
这里有一个容易被新手的习惯带偏的点：不要用console.log手打输出然后肉眼判断。肉眼判断会有系统性盲区，尤其是那些“看起来差不多”的用例。断言脚本的价值在于，你改动的任何一行代码，都会让一个或多个用例的 assert 抛出异常，从而在持续集成里直接阻断合并请求。这道题虽然简单，但正因为简单，很多人不写测试，结果重构时把边界搞坏了。
5.2 变体：忽略非括号字符、只匹配圆括号、找到第一个出错位置
掌握了基础版本之后，你会遇到各种变体需求。下面给你三个最常见的方向，以及对应的改法。
第一个变体是忽略字符串里的普通字符。比如要校验一段代码里的括号是否匹配，但代码里到处都是字母、数字、引号。这时候可以先过滤，再走栈。常见的做法是：
function isValidIgnoreOthers(original) { const s = original.replace(/[^(){}\[\]]/g, ''); // 然后跑标准栈逻辑 }注意这个正则的字符类写法：[^(){}\[\]]，其中[和]需要转义，否则正则表达式会解析出错。这个变体适合“括号可以出现在任何位置，其他字符不影响判断”的场景。如果你的业务是“代码高亮”，还要考虑字符串字面量里的括号应该被忽略，那问题的复杂度就完全不一样了，需要词法分析，光是这个变体就能拆成一篇长文。
第二个变体是只匹配一种括号。有些配置格式只关心圆括号是否闭合，方括号和大括号是普通字符。你不需要维护三对映射，只要一个计数器就能搞定，因为单一类型的括号只要求数量相等且过程中不出现负数。但我仍然建议用栈，因为栈代码能顺带支持“返回出错位置”，而计数器不行。
第三个变体最有价值：不返回布尔值，而是返回第一个导致匹配失败的位置。这在编辑器里很有用，可以提示用户“你的第 37 行附近缺少一个右括号”。改法是在标准栈循环里，当我们遇到右括号且弹出的栈顶不匹配时，记录当前的索引并返回。代码骨架如下：
function findFirstMismatch(s) { const stack = []; const pairs = new Map([[')', '('], [']', '['], ['}', '{']]); for (let i = 0; i < s.length; i++) { const ch = s[i]; if (pairs.has(ch)) { const top = stack.pop(); if (top !== pairs.get(ch)) { return i; // 第一个出错位置 } } else if ('({['.includes(ch)) { stack.push({ ch, index: i }); } else { // 非括号字符的取舍要看需求 } } if (stack.length > 0) { return stack[stack.length - 1].index; // 最近一个未闭合的左括号位置 } return -1; // 全部匹配 }这里我把栈的元素设计成了{ ch, index }而不是单纯字符，这样就保留了这个左括号在原字符串里的位置。注意当循环结束后栈非空，说明有左括号未闭合，我们要返回的是“最近一个未闭合的左括号”，所以取stack[stack.length - 1].index。如果全部匹配，返回 -1，调用方看到 -1 就知道字符串是有效的。这种返回具体位置的变体，也能让你对栈结构的掌握更扎实，因为你需要同时维护两个维度的信息。
这三个变体并不互斥，你可以在一个函数里同时支持“忽略普通字符”和“返回出错位置”。我通常会写一个 options 参数来控制这些行为，比如{ ignoreOthers: true, returnIndex: false }。但面对这个题目，我建议先保持基础版干净，把变体作为独立函数或独立分支来写，不要一上来就把所有功能塞进一个isValid里，否则测试用例会爆炸式增长，而且每个用例的可读性都会下降。
6. 用递归下降器做对拍验证：让我少写 30 行测试代码的技巧
6.1 递归版本作为参照物，随机生成括号串对拍
栈版本写完后，你可能会想：怎么确认它真的对？多写几个用例当然有用，但用例总是有穷的，不如写一个逻辑完全不同的递归版本，然后用随机数据对拍。这个技巧在很多字符串类算法里都适用，我用它抓到过不止一个隐蔽的状态错误。
递归版本的思路是：定义一个函数consume(index)，从index开始解析一个“完整的括号对”，它返回解析结束后的索引，或者返回 -1 表示失败。碰到左括号就找对应的右括号，中间的部分必须递归地也是合法括号串。下面是简化实现：
function isValidByRecursion(s) { // 只处理括号字符串，返回是否有效 function consume(index) { if (index >= s.length) { return index; } const ch = s[index]; if (ch === '(' || ch === '[' || ch === '{') { const closePair = { '(': ')', '[': ']', '{': '}' }[ch]; let next = index + 1; // 内部允许有连续多个括号序列 while (next < s.length && !closePair.includes(s[next])) { const after = consume(next); if (after === -1) { return -1; } next = after; } if (next >= s.length || s[next] !== closePair) { return -1; } return next + 1; } return -1; // 遇到右括号或普通字符，视为失败 } const end = consume(0); return end === s.length; }这个递归版本走的是“解析 + 递归下降”的路线，和栈的思维方式完全不一样。你可以写一个循环，生成若干随机括号串，同时喂给栈版本和递归版本，比较两者的返回结果是否一致。如果发现不一致，就打印出那个串，用它来定位 bug。对拍脚本的核心代码也很短：
function randomBracketString(length) { const chars = '()[]{}'; let s = ''; for (let i = 0; i < length; i++) { s += chars[Math.floor(Math.random() * chars.length)]; } return s; } for (let len = 0; len < 50; len++) { for (let t = 0; t < 1000; t++) { const s = randomBracketString(len); const a = isValid(s); const b = isValidByRecursion(s); if (a !== b) { console.log('mismatch:', JSON.stringify(s), a, b); process.exit(1); } } } console.log('all matched');这套对拍脚本的价值在于，它把“人想测试用例”变成了“机器生成无数个用例”。你不需要记住每一种边界情况，随机生成会在几千次尝试里碰到各种交叉嵌套、空串、连续右括号等组合。一旦两个版本结果不一致，你就知道自己的实现里藏着逻辑漏洞。我当年就是用这个方法抓到了自己在stack.pop()之前没有检查空栈的问题——虽然题目里那行undefined !== ')'会返回 false，但我的递归版本对空栈有不同的返回路径，于是对拍立刻报错。
最后说一个我自己的教训：以前我在改这类函数时，总是倾向于只补一个“看起来会挂”的用例，然后草率收工。后来一个线上配置字符串因为含有换行，而我的过滤正则忘了把\n算进去，导致生产环境出现一次误判。那次事故之后，我养成了“实现 + 对拍 + 回归脚本”三件套的习惯。现在每写一个字符串处理函数，我都会顺手写一个极简的对拍脚本，十几行代码，却能在将来省掉无数次人肉 debug。希望帮到你。
本文还有配套的精品资源，点击获取
