求显式匹配[]或[][]的正则表达式：脚本语言解析器匹配依赖问题

听起来你在为自定义基准测试脚本语言写解析器时，卡在了数组符号的独立匹配上——之前的正则必须绑定变量模式才能识别[]，没法单独捕获[]或者[][]。这其实是正则匹配优先级和模式设计的问题，我来给你捋捋解决方案：

核心思路：优先匹配更长模式，拆分独立匹配规则 #

正则匹配是按顺序尝试的，所以我们要先让引擎识别[][]（二维数组符号），再匹配[]（一维），这样就不会把[][]拆成两个独立的[]；同时去掉对变量模式的强依赖，让数组符号可以被单独匹配。

基础正则示例 #

直接匹配独立的[]和[][]，可以用这个正则：

\[\]\[\]|\[\]

• 顺序很关键：先写\[\]\[\]，确保引擎优先识别二维数组，再匹配一维的[]
• 转义[和]是因为它们在正则里属于特殊字符，必须用\转义才能匹配字面量

结合变量的场景（同时支持var[]/var[][]和独立数组符号） #

如果你的解析场景里，数组符号既可能单独出现，也可能跟在变量名后面，只需要把变量部分设为可选即可：

(\w+)?(\[\]\[\]|\[\])

• (\w+)?：?标记变量名部分是可选的，这样既可以匹配testVar[][]这类带变量的数组，也能匹配单独的[]或[][]
• 分组设计能帮你在解析时区分“变量名”和“数组类型”两部分内容

避免歧义的小技巧 #

如果你的脚本语言里还有其他带方括号的语法（比如函数调用、嵌套数组），可以给正则加上边界约束，比如用\b（单词边界）限定匹配范围：

\b(\w+)?(\[\]\[\]|\[\])\b

这样就不会误匹配到其他含方括号的语法片段里的[]了。

为什么原来的正则不行？ #

你之前的正则应该是把变量模式设为了必填项（比如\w+\[]），导致引擎必须找到变量名才能识别后面的[]。把变量部分改成可选，再调整匹配顺序优先处理更长的数组符号，就能实现独立匹配的需求了。

内容的提问来源于stack exchange，提问作者Anu