The Smurf1. 先搞明白：Bash 和 POSIX 之间到底是“父子”还是“竞争”
我接触 Bash 这么多年，见过最普遍的误解，就是认为“Bash 就是 Linux 上的 shell，跟 POSIX 这个生僻词没什么实际关系”。直到你写的脚本从 Ubuntu 挪到 macOS，或者从交互式终端跑进 cron、从 bash 切到 sh，问题才会像火山一样爆发出来。这章标题叫“Bash and POSIX”，看上去是标准文档里最干巴巴的一节，但实际踩坑的时候，你会发现它几乎解释了你遇到过的所有诡异行为。
先说结论：Bash 是 POSIX shell 规范的一个超集实现，但它不是 POSIX 标准的“克隆品”。POSIX 是一套由 IEEE 制定的操作系统接口标准，其中 Shell and Utilities 部分（也就是 POSIX.1-2017 的第 2 章和第 3 章）定义了一个名为 sh 的命令解释器应该具备哪些语法、内建命令和行为。而 Bash 在完成“符合 POSIX”这个基本要求之后，额外加了一大堆自己的扩展特性：[[ ]]、关联数组、进程替换、let、source、$'...' 转义、&> 重定向……这些好东西让日常操作极其顺手，但副作用是，你的脚本一旦用上了它们，就不再是严格意义上的“POSIX shell 脚本”。
有一个很形象的类比：POSIX 定义的是“标准普通话”，Bash 是带着大量方言的普通话。你在日常交流里说方言没问题，但如果你拿着方言稿子去参加全国播音员考试，评委们大概率会给你打叉。POSIX 就是那位评委。sh（在 Ubuntu 上是 dash，在不少 UNIX 发行版上是其他实现）只会念标准普通话，它读不懂你的方言，于是你在 bash 里跑得好好的脚本，换到 sh 一执行，满屏 not found。
这个关系决定了你写脚本时的决策路径：如果你的脚本只在 bash 环境下运行，且你控制运行环境，那尽管用高级特性；但如果你想让它能在任何 POSIX 兼容系统上跑起来，你就必须学会“在 bash 里自动切换成普通话模式”。Bash 官方考虑到这种需求，专门提供了一种兼容模式，也就是这一节的核心——POSIX mode。理解这个模式，等于同时理解了 Bash 的两幅面孔。
还有一层关系容易被忽视：Bash 在不少系统上会被调用成 sh。比如在 macOS 上，/var/select/sh 可能指向 bash；在基于 systemd 的许多 Linux 发行版里，/bin/sh 指向 dash；但在某些没装 dash 的系统上，/bin/sh 就是 bash 的一个符号链接。同样一个可执行文件，用不同名字被调用时，会采取截然不同的启动行为和语法规则。这就是为什么你在脚本第一行写 #!/bin/sh 和写 #!/bin/bash，可能跑出完全不同的结果——不是内核在作怪，而是同一个 bash 程序在检测到自己被叫成 sh 后，主动收敛了方言。
1.1 Bash 不是 POSIX shell 的“克隆”，而是一个超集
如果从零开始看这个问题的初学者，建议先建立一个三维模型：
- 第一维：POSIX 规范规定了一套最小功能集。比如
for循环、case、while、函数定义、变量展开、重定向、管道等，这些是任何自称兼容 POSIX 的 shell 都必须支持的。 - 第二维：Bash 实现了这套功能集，并且几乎全部兼容。理论上，一个符合 POSIX 规范的脚本，拿到 bash 里执行，基本不会出问题。
- 第三维：Bash 在实现之上叠加了大量扩展。这些扩展就是“方言”，它们不属于最小集，但在 bash 里用着非常爽。
也因为这样，Bash 被视为“POSIX 超集”。它不跟 POSIX 竞争，而是高于它、扩展它。同样的道理，zsh、fish 这类现代 shell 也是超集，不过它们扩展的方向不同。你不需要在 Bash 和 POSIX 之间二选一，你需要的是：了解哪些能力来自 POSIX 的“标准层”，哪些来自 Bash 的“扩展层”，然后根据需要决定到底用哪一层。
1.2 你在 Linux 上跑的 Bash，和 POSIX 有什么关系
很多人在 Linux 上敲 bash，根本没想过背后还有标准。Linux 本身并不强制要求某个 shell 必须符合 POSIX，但你运行的大多数系统脚本、init 脚本、软件的安装脚本，都默认 shell 具备 POSIX 规定的行为。比如 Debian 体系里 /bin/sh 指向 dash，而 dash 就是一个坚持 POSIX 的最小化 shell，它不搞花活，所以系统启动脚本才能在任何环境下稳定执行。
Ubuntu 上 sh 显示为 dash 这个设计不是拍脑袋想出来的，它恰恰是为了“避免 Bash 扩展语法混进系统基础脚本”。你想，如果 /bin/sh 是 bash，那么系统维护者或者第三方开发者写启动脚本时，很容易偷懒用上 [[ ]]、数组这些 bash 特性，一旦哪天底层换成别的 shell，整套系统就崩了。把 /bin/sh 固定成一个严格 POSIX 的轻量级 shell，等于从根上逼着大家写“标准普通话”。
所以，聊 Bash and POSIX 绝不只是理论问题。它直接决定了你在什么场景下可以放心使用 [[ ]]，什么场景下必须退回去用 [ ]；决定了你在命令行里可以用进程替换，但写进某个通用安装脚本却可能被环境拒绝。理解这些边界，才能解释第 3 章里那些五花八门的报错到底从哪来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. POSIX 模式最容易被忽略的差异：一份基于实测的行为对照
Bash 提供了三种方式进入 POSIX 模式：
- 以
sh的名称启动 bash（自动进入 POSIX 模式）。 - 启动时加
--posix参数。 - 运行时执行
set -o posix。
进入之后，Bash 不会变成另一个程序，而是会调整一批默认行为，尽量减少与 POSIX 标准的差异。注意，它是一门“尽量兼容”而不是“完全等同”的语言。很多 Bash 扩展语法在 POSIX 模式下依然能用，因为它们的支持机制藏在词法分析器里，没法通过一个开关彻底关闭。真正可靠的可移植性检测，是把它拿到真正的 sh（比如 dash）下面跑一遍。
2.1 开启 POSIX 模式的方式与检测方法
用命令行直接测最直观。先看看当前 bash 版本和基本状态：
bash复制$ bash --version | head -n 1
GNU bash, 版本 5.2.21(1)-release (x86_64-pc-linux-gnu)
$ bash --posix -c 'echo "$0"'
bash
注意 --posix 模式下 $0 不会被篡改成 sh，除非你是通过符号链接调用的。想确认当前 shell 是否处于 POSIX 模式，可以在脚本里加一段：
bash复制if [ -n "$POSIXLY_CORRECT" ]; then
echo "当前处于 POSIX 模式（环境变量 POSIXLY_CORRECT 存在）"
else
echo "非 POSIX 模式"
fi
Bash 在进入 POSIX 模式时，会自动把 POSIXLY_CORRECT 环境变量置为非空。这是一个非常实用的探测手段。但我见过不少脚本用 set -o posix 来强行开启，这个过程不会自动导出 POSIXLY_CORRECT 到子进程，所以如果你要写一个需要感知模式的库函数，建议自己显式设置这个环境变量。
2.2 最影响日常脚本的五个行为差异
我整理了一张实测对照表，把最容易踩中的差异列在前面。注意，这里说的“POSIX sh”我用的是 Ubuntu 上的 dash 和 macOS 上的 sh（bash 3.2 的受限模式）代表“严格模式下运行错误”的结果。
| 功能/语法 | Bash 默认模式 | Bash POSIX 模式 | POSIX sh（如 dash） |
|---|---|---|---|
[[ 字符串 ]] 条件判断 |
支持，功能强大 | 语法上仍可被解析，但不再推荐；可能执行结果与预期不同 | 报 [[: not found |
function 关键字定义函数 |
function foo {} 可用 |
仍能解析，但生成警告 | 报 function: not found |
source 文件 |
可用，Bash 扩展 | 可用，但更推荐 . 文件 |
dash 支持 source，但其他 POSIX sh 不一定 |
进程替换 <(...) |
可用 | 可用（因为属于词法特性） | 报 Syntax error: "(" unexpected |
&> 重定向 |
可用 | 可用（同样属于重定向扩展语法） | 报 Syntax error: "&>" unexpected |
echo -n |
输出不换行 | 可能正常也可能不按预期，取决于系统 | 部分地区不支持 -n，行为未定义 |
八进制数算术展开 $((010)) |
按八进制解释为 8 | 按十进制解释为 10 | 按十进制解释为 10 |
case 中的 ;& 分支 |
可用 | 不支持，报错 | 不支持 |
$'...' 转义 |
可用 | 可用（仍是扩展，不建议用在严格模式） | 不支持，字面量输出 |
$RANDOM、$SECONDS |
可用 | 可用（仍是扩展） | 不存在 |
这张表就是我从踩坑记录里提炼的核心。你可以发现一个规律：真正导致“换个 shell 就炸”的，主要是语法层面的差异，而不是内建命令行为差异。比如 [[、function、<(...)、&> 属于词法解析阶段就被特殊处理的构造，dash 的词法分析器根本不认识它们，所以直接报语法错误。而 echo -n、八进制算术这些属于运行时的行为差异，dash 不会报错，但会给出不同的输出结果——这种“无声的错误”更可怕，因为脚本退出码依然为 0，你根本察觉不到结果已经被悄悄改掉了。
2.3 用实际命令感受差异
光看表格不够直观，我把几个典型命令的执行输出贴出来，你可以在自己的机器上复现这段测试流程。
bash复制# 1. 测试 [[ 在 dash 下的表现
$ dash -c '[[ -n "hello" ]] && echo yes'
dash: 1: [[: not found
# 2. 测试 function 关键字在 dash 下的表现
$ dash -c 'function foo { echo hi; }; foo'
dash: 1: function: not found
# 3. 测试进程替换在 dash 下的表现
$ dash -c 'cat <(echo hi)'
dash: 1: Syntax error: "(" unexpected
# 4. 测试 &> 重定向在 dash 下的表现
$ dash -c 'echo hi &> /dev/null'
dash: 1: Syntax error: "&>" unexpected
# 5. 测试 $((010)) 在不同模式下的结果
$ bash -c 'echo $((010))'
8
$ bash --posix -c 'echo $((010))'
10
$ dash -c 'echo $((010))'
10
看到第 5 条，是不是背后一凉？同一个算术表达式，在 bash 默认模式里算出 8，在 POSIX 模式下算出 10。原因在于 POSIX 标准规定，算术展开中的数字默认按十进制解释，不认前导 0 的八进制语义。所以如果你写脚本时，习惯性地用 010 表示八进制 8，一旦脚本被某个坚持 POSIX 语义的环境执行，结果就会悄然改变。我早年就因为在脚本里用 $(( 08 )) 想表示八进制，结果在 macOS 上直接算出个奇怪值，排查了整整一个下午，最后才发现是这种细碎差异。
这种“输出不同但退出码为 0”的行为差异，比明晃晃的语法错误更难捉摸。所以我建议，任何涉及数值计算、日期时间处理的脚本，一定要明确标注数值进制，别依赖 shell 的默认解释。
3. 热搜词背后的真实问题：Permission Denied、cannot exec、syntax error 的排查思路
我把这几个网络上的高频热搜词串起来，当成一组真实案例来拆解。它们表面上风马牛不相及，但深挖之后，背后都是 Bash 与 POSIX 边界、执行环境差异、文件格式问题在作祟。
3.1 bash: /home/xtest/.bashrc: permission denied 到底卡在哪一步
这个报错信息你会经常刷到：用户执行交互式 shell 时，Bash 启动流程会依次加载系统级启动文件、~/.bashrc、~/.bash_profile 等。如果某个文件对你没有读权限，Bash 会打印一行令人费解的 permission denied。
排查思路不能停留在“我看看文件权限”这一步，要按下面的链路走：
bash复制# 第一步：看文件本身的权限
ls -l /home/xtest/.bashrc
# 第二步：看文件所有者和当前用户
id
stat -c "%U %G %a" /home/xtest/.bashrc
# 第三步：逐级检查父目录权限，特别是家目录的写权限
namei -l /home/xtest/.bashrc
比较反直觉的一点是：Bash 读 .bashrc 时，需要的不是执行权限，而是读权限。如果文件权限是 0400 或 0600，自己读没问题；但如果所有者和组都错了，或者家目录被设成 000，那文件就算写着 0644 也进不去。另一个隐藏非常深的情况是：家目录所在的文件系统被以某种方式挂载，比如 FAT 分区不支持 Unix 权限位，所有文件看起来都是 0777，却因为挂载参数里带了 noexec 或 umask=077 而表现异常。
Git Bash 用户也经常会遇到类似错误，因为 Windows 文件系统默认不区分 Unix 权限，Git Bash 会模拟一套权限映射。如果你把 .bashrc 放在一个受 Windows 用户账户控制（UAC）保护的目录里，Git Bash 在读取时可能会因模拟出来的“权限不足”而拒绝。这时候优先到 Windows 侧检查文件属性里的“只读”勾选，而不是在 Linux 权限位上调半天。
3.2 npm 全局安装的 CLI 出现 cannot exec，真正的病灶在文件结构
再来看这条热门搜索词：形如 bash: /c/users/用户名/appdata/roaming/npm/claude: cannot exec。这种报错在 Windows + Git Bash + npm 环境里非常典型。核心症状是：Bash 找到了一个可执行文件，尝试执行它，但内核返回“无法执行”。
排查链路：
bash复制# 第一步：查看文件类型
file /c/Users/用户名/AppData/Roaming/npm/claude
# 第二步：查看前几行原始内容
head -n 5 /c/Users/用户名/AppData/Roaming/npm/claude
# 第三步：检查文件的行尾符，看是否有 CRLF
file --mime-encoding /c/Users/用户名/AppData/Roaming/npm/claude
cat -A /c/Users/用户名/AppData/Roaming/npm/claude | head -n 2
cannot exec 的常见原因有三个：
- 文件没有 shebang 行，或者 shebang 行指向的解释器路径不存在。Bash 看到文件没有可识别的魔法字节，命令本身又没被识别为内建命令，只能尝试把文件当 ELF 二进制执行，失败后返回
cannot exec。 - 文件是 UTF-16 编码，比如某些工具在 Windows 下生成脚本时默认存成 UTF-16 LE，文件开头带了 BOM，导致 bash 无法识别 shebang。
- CRLF 行尾导致 shebang 变成
#!/usr/bin/env node\r，bash 找不到名为node\r的解释器，直接报错。
我自己处理过一个类似案例：某个全局 CLI 工具在 npm 安装时，生成的是 Unix 换行的 shell 脚本，但 Windows 上的编辑器自动把它转换成了 CRLF，于是在 Git Bash 里就炸了。解决办法很简单：用 dos2unix 转一下，或者用 sed -i 's/\r$//' 去掉行尾。更彻底的做法是配置 npm 的全局安装脚本别做任何换行转换，但这属于环境定制，不在当前话题范围内。
3.3 curl 管道安装脚本报 syntax error，多数不是网络问题
下面这条热搜也极具代表性：curl -fssl https://某地址/install.sh | bash，结果 bash 立刻报 line 1: syntax error near unexpected token ...。
这里最容易误判的是“以为是网络下载了空文件”。实际上，当管道给 bash 的脚本第一行就报语法错误时，优先级最高的嫌疑是脚本本身带有 Windows 行尾（CRLF）。bash 面对 CRLF 行尾时，会把 \r 当成命令的一部分，所以第一行如果是 #!/bin/bash\r，bash 会尝试执行一个叫 #!/bin/bash\r 的命令，落在命令行上就是错误的 token。
还有一个低频但确实存在的原因是：脚本开头包含了 UTF-8 BOM（\xEF\xBB\xBF），bash 不认 BOM，把它当成一个命令名，于是报 line 1: \ufeff#!/bin/bash: No such file or directory 或语法错误。
排查方法很简单：
bash复制# 先下载到本地，不要直接管道执行
curl -fssl -o install.sh https://某地址/install.sh
# 检查文件类型和行尾
file install.sh
sed -n '1,3p' install.sh | cat -A
如果每行结尾看到 ^M$，基本可以断定是 CRLF 了。处理方法是 sed -i 's/\r$//' install.sh 或者 dos2unix install.sh，然后再执行。这提醒我们一个重要习惯：从网络拉脚本管道给 bash，永远先下载到本地检查再执行。不只是安全考虑，光是格式问题就能帮你排除一大半莫名其妙的语法报错。
3.4 telnet: command not found，其实是在教你理解 PATH 和命令查找
telnet: command not found 这种报错看起来太基础了，但它背后其实是 Bash 处理外部命令搜索的完整机制。Bash 接收到一个命令后，查找顺序是：别名（alias）→ 关键字（keyword）→ 函数（function）→ 内建命令（builtin）→ 外部命令（通过 PATH 搜索）。
command not found 意味着前四步都没匹配到，然后 PATH 里的所有目录里也没找到对应的可执行文件。这里的隐藏知识点是：bash 用 PATH 查找外部命令时，不会因为找不到就自动尝试其他目录。很多初学者以为“我明明装了 telnet 客户端，怎么还找不到”，其实大概率是装进了 /usr/local/bin，而 PATH 里没有包含这个目录，或者当前 shell 的环境变量还没有刷新。
排查步骤：
bash复制# 查看当前 PATH
echo "$PATH"
# 找到命令的绝对路径
command -v telnet
type -a telnet
# 手动尝试常见目录
ls -l /usr/bin/telnet /usr/local/bin/telnet
# 临时追加目录测试
PATH="/usr/local/bin:$PATH" telnet 目标IP 端口
从这个热搜进入，其实能挖出更实用的一课：不要在脚本里依赖某个不一定存在的命令，更不要在脚本开头不做检查。如果脚本需要 telnet，应该先 command -v telnet 判断，缺失时给出友好提示并退出。这既是可用性问题，也是 Bash 脚本健壮性的基本素养。
4. Git Bash、macOS 自带 Bash 与 Linux 系统 Bash：三个完全不同世界的兼容性陷阱
同样是 bash，在不同平台上的版本、行为、默认选项差距非常大。这一节主要解决一个热点问题：为什么我的脚本在 Linux 上好好的，拿到 Git Bash 或者 macOS 自带终端里就跑不对。
4.1 三大环境的 Bash 版本现实
| 环境 | 默认 Bash 版本 | 典型特征 |
|---|---|---|
| Ubuntu 22.04 / Debian 11+ | Bash 5.1 / 5.2 | 完整支持关联数组、** globstar、$EPOCHSECONDS 等新特性 |
| macOS（直到 Ventura） | Bash 3.2 | 功能老旧，缺失大量新特性，甚至不支持 mapfile、globstar |
| Git Bash（Windows） | 随 Git 版本变动，目前多为 Bash 5.x | 基于 MSYS2，模拟 Unix 层，PATH、文件权限、进程模型与原生环境有差异 |
| 较老红帽/CentOS 7 | Bash 4.2 | 介于 3.2 和 5.x 之间，关联数组可用但部分语法受限 |
初学者最容易踩的坑，是在本机（Git Bash 或较新 Linux）里写脚本，用上了 mapfile、关联数组等高级特性，然后部署到一台 macOS 或者老旧服务器上，直接 syntax error。macOS 到现在还默认带 Bash 3.2，原因是 Bash 4.x 开始使用 GPLv3 许可证，苹果不愿引入这个授权变更，所以一直停留在 3.2。想升级得自己用 Homebrew 装新版本 bash，但装完之后你还是得显式修改用户默认 shell，不然终端一开还是老版本。这也是为什么“mac 升级本地 bash”会成为一个常驻热搜关键词。
4.2 一份脚本三处跑：从错误中学会的适配方法
我给你展示一段典型脚本，它在 Ubuntu 上跑得很顺，但到 macOS 和 Git Bash 上各有各的问题：
bash复制#!/bin/bash
mapfile -t lines < "config.txt"
for line in "${lines[@]}"; do
echo "$line"
done
- 在 macOS 自带的 Bash 3.2 上，
mapfile不存在，直接报command not found。 - 在 Git Bash 上，如果
config.txt是 CRLF 行尾，mapfile会把所有行存成带\r的字符串，输出时每行后面多一个回车，肉眼几乎看不到，但一旦拿去拼接路径、比较字符串，必炸。 - 在同一份 Linux 上，如果
config.txt是从 Windows 上传的，同样存在 CRLF 问题。
适配的思路不是“我不用新特性”，而是“先检测版本，再决定分支实现”：
bash复制#!/bin/bash
if [[ ${BASH_VERSINFO[0]} -ge 4 ]]; then
mapfile -t lines < "config.txt"
else
while IFS= read -r line; do
lines+=("$line")
done < "config.txt"
fi
这种写法虽然啰嗦，但兼顾了新老 bash。真正的可移植脚本高手，会一边追求最小特性集，一边用版本检查做降级适配，而不是一刀切不用新语法。
4.3 脚本首行用 #!/bin/bash 还是 #!/bin/sh，决定你的脚本宿命
很多人写脚本时，第一行只是随手抄来的，并没有认真想过它对整个脚本的命运有多大的主导作用。#!/bin/bash 意味着你明确要求“请找一个名叫 bash 的解释器来执行我”，如果系统没有 bash，哪怕脚本内容完全符合 POSIX，也会直接 not found。#!/bin/sh 则是要求“请用系统默认的 POSIX shell 解释器”，在 Ubuntu 上它是 dash，在 CentOS 上它是 bash（以 sh 模式启动），在 macOS 上它是 bash 3.2 的 POSIX 模拟层。
所以，这是一个典型的“选择决定未来”：
- 如果脚本里用了 bash 专属语法，第一行必须写
#!/bin/bash，同时你要接受它不适用于某些精简容器环境。 - 如果脚本追求最大兼容性，第一行写
#!/bin/sh，但脚本本体就要迁就 POSIX 语法，不能用关联数组、不能用[[、不能用进程替换。
我的建议是：能写 POSIX 兼容就写 POSIX 兼容，不能的话就明确声明 bash 依赖，并且在使用前检查解释器是否存在。这两种态度都算专业，最怕的是明明用了 [[ 和数组，还写 #!/bin/sh，然后一脸无辜地说“我在自己电脑上跑是好的啊”。
5. 把脚本写得两头通吃：我常用的 POSIX 兼容写作与测试方法
这一节是你打开搜索引擎搜“Bash POSIX”时最希望看到的内容——具体怎么做。我从自己维护脚本的实际经验里，挑几条最好用的方法分享出来。
5.1 先定方言边界：在脚本头部显式声明“我用到的最低特性”
我写脚本的第一件事就是定边界。这个脚本要跑在什么环境？只有 bash 5.x？还是需要考虑 macOS 3.2？还是极有可能被塞进某个精简 Docker 镜像里当 sh 执行？根据答案选择语法层级。
一个实用的做法是：项目根目录建一个 script_style.md 或者在每个脚本头部注释里写明允许使用的特性等级。
bash复制#!/usr/bin/env bash
# 特性等级：bash-only
# 允许：关联数组、mapfile、进程替换、[[ ]]
# 禁止在 /bin/sh 下运行本脚本
如果你在维护一些要进入系统标准启动链路的脚本，那就直接在头部声明为 sh 兼容，同时约束自己不使用任何 bash 专属语法。这个约束刚开始很难受，习惯了反而觉得写出来的脚本更干净。
5.2 用 ShellCheck 做静态检查，让机器替你抓语法雷
ShellCheck 是 Bash 脚本静态分析工具，强烈建议每个写 Bash 的人都装上。你能想象它连“这条命令在 POSIX 模式下是否可移植”都能给你提示吗？举个例子：
bash复制#!/bin/sh
[[ -n "$1" ]] && echo "参数存在"
在 ShellCheck 里运行，它会直接报：
code复制SC3010: In POSIX sh, [[ ]] is undefined.
看到没有，它甚至会根据你脚本首行的 #!/bin/sh 自动切换到 POSIX 规则检查模式。如果你写 #!/bin/bash，它就会换成 bash 规则集。这个工具的价值在于：你不需要自己去背 POSIX 规范里所有语法边界，让机器在提交代码之前就把问题拦下来。
安装方式根据不同系统：
bash复制# Ubuntu / Debian
sudo apt install shellcheck
# macOS
brew install shellcheck
# 或者直接从 GitHub 下载二进制
在 CI 流程里加一步 shellcheck script.sh，比任何代码评审都管用。它能抓到的低级错误包括未加引号的变量、误用 test 语句、在 POSIX sh 里用 bash 专属语法等。
5.3 同时在 bash 和 dash 下跑一遍，是最便宜的兼容性测试
除了静态检查，我每次发布脚本前还会做一轮动态验证。核心思想是：用两种解释器分别执行同样的脚本，对比输出。
bash复制# 用 bash 跑
bash script.sh
# 用 dash 跑（如果脚本首行写了 /bin/sh，直接 sh script.sh 即可）
dash script.sh
如果脚本里有 bash 专属语法，dash 会立刻报错。如果只是行为差异，输出结果对比也能肉眼发现。这个方法成本极低，但能有效拦截 80% 以上的兼容性 bug。
如果你写的是 bash-only 脚本，那至少要在两个不同版本的 bash 下跑：本机新版 + 老版本。可以用 Docker 快速拉一个老镜像：
bash复制# 在旧版 CentOS 环境里测试
docker run --rm -v "$PWD:/app" -w /app centos:7 bash /app/script.sh
macOS 用户则可以直接用系统自带的 bash 3.2，它天然就是一个“老版本兼容性测试器”。你在新版 bash 上写的新特性，拿过去一跑，立刻知道有没有用错。
5.4 单独排查由版本差异引发的隐性问题
有几个非常隐蔽的行为差异，即使你脚本写得完全符合 POSIX，跨平台还是容易踩：
printf的%b扩展：POSIX 规定printf可以处理%b，但某些 shell 对该格式的支持程度不同，格式化符号解释也可能不同。建议字符串输出尽量少依赖%b。echo的行为不确定性：POSIX 标准没有明确echo是否支持-n等选项，所以在可移植脚本里，输出一律用printf。local关键字：dash 支持local，但 POSIX 标准并不包含它。如果目标环境是某个严格 POSIX 的 shell，可能在函数里声明局部变量会直接报错。保险写法是使用 POSIX 规范之外的变量命名习惯，或者不做本地变量声明。
5.5 处理文件路径和换行符的跨平台细节
这是最后一个但非常重要的一点。跨平台 Bash 脚本的隐形杀手，一是 CRLF，二是路径分隔符，三是不区分大小写的文件系统。
Git Bash 里，/c/Users/xxx 和 C:\Users\xxx 是同一个东西的两种表达，但如果你在脚本里硬编码了 Linux 风格的路径，拿到 Windows 上用就会出问题。最好办法是尽量用相对路径，或者用环境变量动态拼路径，比如 $HOME、$USERPROFILE。
CRLF 的处理我前面已经强调过。在 Git Bash 里，默认可能会把文件的 LF 转成 CRLF 再读入。你可以在仓库根目录放一个 .gitattributes 文件规定换行策略，也可以在每个脚本执行前做一轮防御性清理：
bash复制# 在脚本开头强制把配置文件里的 CRLF 去掉
sed -i 's/\r$//' config.txt
不过，对于你要读取的文本文件，不要轻易用 sed -i 原地修改——它可能破坏文件编码。更稳妥的是在读取时过滤：
bash复制while IFS= read -r line || [ -n "$line" ]; do
line=${line%$'\r'}
# 进一步处理
done < config.txt
${line%$'\r'} 这个参数展开可以从行尾去掉一个 CR 字符，兼容 bash 3.2 以上的所有版本。注意，$'\r' 在 POSIX sh 里不是标准写法，所以如果你要完全兼容，可以写 line=${line%$(printf '\r')}，或者直接依赖 IFS 去除尾部空白。每个细节都得根据脚本的目标运行环境来决定取舍，这正是 Bash and POSIX 这个话题最迷人也最折磨人的地方。
写到这里，关于 Bash 和 POSIX 的关系、POSIX 模式的细节差异、以及跨平台脚本的兼容性实践，该覆盖的坑基本都覆盖到了。我在实际项目里维护过上万行、跨三个操作系统的 Bash 代码库，最大的体会就是：不是让你放弃 bash 特性，而是让你清清楚楚知道自己用了哪些“方言”。每一种方言的引入，都要把它当成一条明写的依赖。能做到这一步，你写出来的脚本就不再是“碰巧跑了一次成功”的玩具，而是真正可以交付到任何环境里稳定运行的工程产物。