Bash中反引号`...`与$(...)的差异及适用场景

嘿，这个问题问到点子上了！很多写Shell脚本的朋友都会像你一样交替用这两种写法，它们本质都是命令替换——把命令执行的输出结果赋值给变量，但确实存在一些关键差异，适用场景也各有侧重。

核心差异 #

1. 嵌套支持的便捷性 #

这是最直观的区别：$(...)天生支持嵌套，不需要额外转义，写起来非常顺畅。比如你想嵌套执行命令：

# 获取当前脚本所在目录下的文件列表
script_files=$(ls $(dirname $0))

而如果用反引号`...`来做嵌套，必须对内部的反引号进行转义（加\），可读性瞬间下降：

script_files=`ls \`dirname $0\``

复杂嵌套的情况下，反引号的转义会让代码变得混乱，很容易写错。

2. 转义规则的复杂度 #

反引号的转义逻辑比$(...)更繁琐：

• 在反引号内部，反斜杠\会被当作转义符，比如`echo \$HOME`会输出$HOME（而不是你的家目录路径）；
• 如果要在反引号里使用反引号本身，必须写成\`；
• 相比之下，$(...)的转义规则和普通Shell语法完全一致，不需要额外记忆特殊规则，处理特殊字符、换行时更不容易出错。

3. 可读性与兼容性 #

• 可读性：$(...)的语法边界更清晰，尤其是命令较长或者嵌套时，一眼就能识别出这是命令替换；反引号和单引号视觉上很相似，字体较小时容易混淆，可读性差一些。
• 兼容性：两种写法都是POSIX标准的一部分，但反引号的支持更“古老”——几乎所有Shell（包括最原始的Bourne Shell）都能识别；而$(...)虽然现在主流Shell（bash、zsh、dash等）都完全支持，但极少数非常老旧的Shell环境可能不兼容。

适用场景 #

优先选择$(...)的情况 #

• 涉及嵌套命令替换的场景：比如需要在一个命令的输出基础上执行另一个命令，$(...)的写法简洁易读，不易出错；
• 命令较长、包含特殊字符或换行的脚本：清晰的语法边界能提升代码的可维护性，团队协作时更友好；
• 大多数现代Shell环境：现在几乎没人用几十年前的老旧Shell了，$(...)是更推荐的写法。

适合用反引号的情况 #

• 必须兼容极端老旧的Shell环境（比如原始Bourne Shell）：这时候只能用反引号来保证脚本能运行；
• 个人习惯且命令简单：如果只是单条短命令的替换，比如files=ls``，你觉得顺手也可以用，但还是建议逐渐过渡到$(...)，养成更好的编码习惯。

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