Bash =~ 正则加引号后始终不匹配

在 Bash 中，[[ $text =~ "$pattern" ]] 一直不匹配，放在 if 内的输出也没有出现。即使表达式里写了括号，BASH_REMATCH 也没有给出预期的捕获结果。若右侧整段正则被引号包住，应先检查这个引号：它会让本来有特殊含义的正则字符按字面匹配。

下面针对 Bash 5.x 默认兼容行为。[[ ... ]]、=~ 和 BASH_REMATCH 都不能直接当成 POSIX sh 语法使用；如果脚本显式启用了旧的 compat31 行为，引号规则也不同。

赋值时加引号，匹配时让正则保持有效

这个完整示例将模式保存到变量，再在 =~ 右侧展开：

#!/usr/bin/env bash
text='build-42'
pattern='^build-([0123456789]+)$'

if [[ $text =~ $pattern ]]; then
    printf 'number: %s\n' "${BASH_REMATCH[1]}"
else
    status=$?
    printf 'match status: %s\n' "$status" >&2
    exit "$status"
fi

按该表达式，build-42 应匹配并捕获 42。赋值语句中的单引号用于保存模式字符串，外层引号不会成为变量值。到了匹配位置，$pattern 没有再被双引号包住，括号、+、^、$ 才会作为正则语法参与匹配。

如果改成 [[ $text =~ "$pattern" ]]，整个模式按字面处理。例如 ^ 会变成需要匹配的字符，而不是字符串开头的锚点。此时 build-42 不符合这个字面模式，if 内的 printf 根本不会执行。应先修正条件表达式，不能把没有输出直接归因于捕获数组失效。

模式里有空格，也可以保存到变量

[[ ... ]] 内不会像普通命令参数那样进行词拆分和路径名展开。因此，正则包含空格时，不必为了防止拆词而给右侧变量展开整体加引号：

text='build number 42'
pattern='^build number ([0123456789]+)$'
if [[ $text =~ $pattern ]]; then
    number=${BASH_REMATCH[1]}
    printf '%s\n' "$number"
fi

这里的空格属于模式内容。此规则只用于当前 [[ ... ]] 上下文，不能推广成脚本中所有变量都应去掉引号；传文件名或普通命令参数时仍需按参数边界引用。

如果某部分本来就要按字面匹配，可以只引用那部分。排查时把完整模式先存入变量，通常更容易看清究竟是 shell 引号，还是正则中的反斜杠改变了含义。不需要用 eval 再解析一遍字符串。

区分不匹配和表达式错误

Bash 的 =~ 使用 POSIX 扩展正则表达式，不是 PCRE。返回状态 0 表示匹配，1 表示不匹配，2 表示正则语法不正确。第一个示例在 else 开头立即保存 $?，否则后续输出命令会覆盖这个状态。

移除引号后仍然失败时，先看是 1 还是 2，再检查模式和输入。不要将其他正则引擎的写法直接搬入 Bash，也不要把所有失败都当成输入内容不符。

模式默认可以匹配字符串的一部分。需要校验整条字符串时使用 ^ 和 $；上面的模式因此会拒绝 prefix-build-42、build-42-extra 和 build-xx。若脚本启用了 nocasematch，字母大小写的匹配行为也会改变，应连同脚本的 shell 选项一起核对。

捕获结果在匹配成功后立即取用

BASH_REMATCH[0] 保存整个匹配部分，BASH_REMATCH[1] 保存第一组括号捕获的内容。只有对应匹配成功后，才读取需要的捕获项；不要在失败分支沿用它，也不要先执行另一次 =~ 再读取上一轮结果。

需要把捕获值传给后续逻辑时，像第二个示例那样立即保存到自己的变量。Bash 会在全局作用域设置 BASH_REMATCH，不要用 local BASH_REMATCH 来尝试隔离它。

修改脚本时只调整本次匹配处的引用方式，保留修改前版本。在隔离输入上分别检查应接受和应拒绝的样本，再接回后续业务动作。如果原条件本来用于字面字符串判断，去掉引号会扩大其匹配含义，应恢复原写法，不能把所有右侧引号一并删除。