Shell脚本的跨环境兼容性问题是运维和开发工作中经常被低估的坑。明明在自己的机器上跑得好好的脚本，换到同事的电脑上，或者部署到服务器上，就出现数组取值错误、通配符不展开、变量为空等奇怪现象。这背后大概率是Shell解释器不一致导致的，比如脚本是用Bash写的，而执行环境是Zsh，甚至是很久远的dash或busybox sh。这篇文章就来详细分析Bash与Zsh的典型差异，以及如何借助POSIX标准写出高可移植性的脚本。
一、为什么会出现兼容性问题
首先要理解一个基本事实：Shell是一类程序的统称，而不是某一个具体软件。常见的有Bash、Zsh、dash、ksh、busybox sh等，它们对语法的解释并不完全一致。Bash是最广泛使用的Shell，也是绝大多数Linux发行版的默认Shell；Zsh则在macOS Catalina之后取代Bash成为系统默认Shell。也就是说，你在Mac上打开终端写脚本，默认面对的环境已经是Zsh了。
很多教程和网上示例默认按Bash语法编写，比如用declare、用关联数组、用[[ ]]扩展测试语法。这些写法在Zsh中大部分可用，但在细节上存在微妙差异，而在dash这类严格POSIX的Shell中则直接报错。兼容性问题的根源就在这里：你以为自己在写Shell脚本，实际上写的往往是某个特定Shell的方言。
另外要注意脚本第一行的shebang。写成#!/bin/bash则无论当前Shell是什么，都会交给Bash解释执行；写成#!/bin/sh则由系统的sh指向的解释器执行，在Debian系上通常是dash，在macOS上实际上是Bash的posix模式。很多人用sh script.sh来执行一个Bash脚本，这等于强制放弃Bash特性，是常见的踩坑方式。
二、Bash与Zsh的典型差异详解
1. 数组下标从0还是从1开始
这是Bash与Zsh最著名的差异之一。Bash的数组下标从0开始，而Zsh默认从1开始。下面这段代码在两个Shell里输出完全不同：
# Bash 和 Zsh 中分别执行
arr=(a b c d)
echo ${arr[1]}在Bash中输出的是b，在Zsh中输出的是a。如果脚本里大量使用了数组下标，迁移时必须逐个检查。Zsh提供了一个选项setopt KSH_ARRAYS，开启后数组行为会模拟从0开始，但这要求脚本能控制Zsh的选项，并不总是可行。更稳妥的做法是显式指定下标，或在脚本中通过shebang固定解释器。
2. 单词拆分与变量展开
Bash中，未加引号的变量展开会按空白符拆分成多个词，这也是很多脚本空格灾难的来源。而Zsh默认不做单词拆分，变量展开始终保持为一个整体。例如：
files="a.txt b.txt" for f in $files; do echo "处理: $f" done
Bash中循环会执行两次，分别处理两个文件；Zsh中循环只执行一次，$f的值是整串a.txt b.txt。Zsh这么做是为了安全，避免意外拆分，但对于习惯了Bash行为的脚本，就会产生逻辑错误。解决办法是在Zsh中使用${=files}强制拆分，或改用更通用的写法如数组遍历。
3. 通配符不匹配时的行为
当通配符*没有匹配到任何文件时，Bash会保留原始字符串，Zsh则默认报错，提示no matches found。例如执行ls *.log而目录下没有log文件，Bash会把字面量*.log传给ls，Zsh直接终止命令。Zsh中可以用setopt NO_NOMATCH关闭这个行为，或者在脚本中先判断文件是否存在再操作，这也是更健壮的写法。
4. 其他细节差异
除了上述三点，还有一些值得留意的差异：Zsh中$0在交互式环境下含义不同；Bash的<<<here-string在老版本Zsh中不支持；某些转义和prompt扩展语法两者完全不同；Bash的time关键字可以作用于管道，Zsh的用法略有区别。另外Zsh的很多默认按键绑定、补全行为是交互层面的特性，与脚本关系不大，但容易让人误以为脚本行为也会一致。
三、用POSIX标准约束脚本写法
1. POSIX标准是什么
POSIX是由IEEE制定的一系列标准，其中定义了Shell和命令行工具必须遵守的最小行为集合。凡是声称符合POSIX的Shell，都必须支持这套语法。dash、busybox sh严格遵循POSIX，Bash和Zsh在以sh模式运行或设置posix选项后，也基本兼容。换句话说，POSIX语法是所有主流Shell的公共子集，用它写的脚本理论上可以在任何类Unix系统上运行。
2. 常见的非POSIX写法替换
写跨平台脚本时，需要把Bash特有的语法替换成POSIX等价形式。下面列出最常见的几组对照：
# Bash 特有写法 # POSIX 等价写法
if [[ -f "$file" ]]; then fi if [ -f "$file" ]; then fi
echo ${arr[@]} # POSIX 无数组，用多个变量或循环拼接
source config.sh . ./config.sh
echo $((2 ** 10)) # POSIX 不保证 ** 运算符，改用循环或bc
read -r -p "提示:" var printf "提示:"; IFS= read -r var其中[[ ]]与[ ]的区别最值得注意。[[ ]]是Bash扩展，内部不会发生单词拆分和路径展开，写起来更省心，但不可移植。改成[ ]后所有变量都必须严格加引号，否则带空格的路径就会出问题。同理，source要换成点号.，虽然可读性差一些，但任何POSIX Shell都支持。
3. 用dash和shellcheck做验证
光靠记忆替换还不够，最好借助工具验证。第一步是安装dash并用它跑一遍脚本，因为dash对POSIX的执行最严格，很多Bash语法会直接报错暴露出来：
# Ubuntu/Debian 安装 dash sudo apt-get install dash # 用 dash 检查脚本，非 POSIX 语法会立即报错 dash -n myscript.sh dash myscript.sh
第二步是使用shellcheck静态分析工具。它能识别出脚本中使用了哪些Bash特有的结构，并给出具体的可移植性建议。对于打算长期维护的脚本，建议把shellcheck接入CI流程，每次提交自动检查，从源头杜绝不兼容语法混入。
如果脚本确实需要Bash特性，比如关联数组、进程替换，那就老老实实在第一行声明#!/bin/bash，并检查目标机器上存在该解释器。最糟糕的做法是shebang写着#!/bin/sh，正文却全是Bash方言，这种脚本的失败往往发生在最不可控的部署环境里。
四、兼容性检查清单与实践建议
综合上面的内容，可以总结成一份实用的检查清单。写完脚本后对照过一遍，能避免绝大多数跨Shell问题：
- 确认shebang与实际使用的语法匹配，需要Bash特性就写
#!/bin/bash，追求可移植就写#!/bin/sh并遵守POSIX。 - 所有变量展开都加双引号，包括
"$@"和"$var"，这是Bash和Zsh下都安全的第一原则。 - 避免依赖数组下标起点，改用
for x in "$@"或for x in a b c这种直接列举的写法。 - 用通配符前先判断匹配结果，避免Zsh的no matches错误，例如用
for f in *.log前先ls *.log >/dev/null 2>&1 || exit 0。 - 不使用未加引号的裸变量参与循环，防止Bash拆分、Zsh不拆分带来的行为分歧。
- 管道和子Shell中的变量修改要格外小心，POSIX Shell中管道右侧运行在子进程里，修改不会传回父Shell。
最后给一个取舍建议：如果是个人工具、只在固定机器上运行，用Bash甚至Zsh的完整特性没问题，效率优先；如果要分发给团队、部署到不同服务器、或做成安装脚本，就严格按POSIX写，并用dash加shellcheck双重验证。兼容性做得好，脚本才能在任何地方稳定地完成它的使命。
Shell的历史长达几十年，各家实现积累的怪癖很多，POSIX标准正是为了解决这个问题而存在的公共契约。理解Bash与Zsh的差异让你知道坑在哪里，掌握POSIX写法则让你有能力绕开这些坑。两者结合，写出的脚本才真正称得上一次编写、处处运行。