macos中legacy脚本执行报错主因是系统升级后环境变更：catalina起默认shell切为zsh、/bin/bash仅含旧版3.2、/usr/bin下命令被移除或受限、sip阻止系统级操作，以及apple silicon架构不匹配导致二进制失败。
macos中legacy脚本执行报错，通常不是因为“系统架构迁移”本身（如intel转apple silicon），而是因macos版本升级后移除了对传统shell脚本运行环境的支持，或脚本依赖的底层工具、路径、权限模型发生了变化。尤其在macos catalina（10.15）起，默认shell从bash切换为zsh，且系统完整性保护（sip）、文件权限机制、/usr/bin路径限制等全面收紧，大量旧脚本会因此失败。
检查脚本是否仍在支持的Shell环境中运行
很多Legacy脚本以#!/bin/bash开头，但在macOS Catalina及之后，/bin/bash是旧版bash（3.2），不支持现代语法；而系统自带的/usr/bin/bash已被移除，新安装的bash需通过Homebrew等手动部署。
- 运行
echo $SHELL确认当前Shell类型 - 用
which bash和bash --version检查可用bash路径与版本 - 若脚本依赖bash 4+特性（如关联数组、
[[增强判断），需改用#!/opt/homebrew/bin/bash（M1/M2）或#!/usr/local/bin/bash（Intel），并确保已通过brew install bash安装
修复路径与命令不可用问题
macOS自10.15起将许多系统命令从/usr/bin移至只读的系统卷，同时禁用对/usr/sbin等目录的直接调用；部分Legacy脚本硬编码了已失效路径（如/usr/bin/python、/usr/bin/grep）。
- 避免使用
/usr/bin/python：该路径在macOS 12.3+已彻底删除，应改用/usr/bin/python3或python3（需brew install python） - 检查
grepsedawk等命令是否被重写或受限：可临时用brew install grep sed gawk获得GNU版本，并在脚本中显式调用ggrepgsed等 - 用
command -v xxx验证每条命令是否存在，而非仅靠which
绕过SIP与权限拦截
Legacy脚本若尝试修改系统目录（如/etc/paths、/Library/LaunchDaemons）、挂载磁盘或调用csrutil相关操作，会被SIP阻止，报错如“Operation not permitted”或“Permission denied”。
- 不要关闭SIP——这是高危操作；应改用用户级替代方案，例如将PATH配置写入
~/.zshrc而非/etc/paths - 需要系统级服务时，改用
launchctl bootstrap gui/$UID加载用户域plist，避免写入/Library - 涉及磁盘操作（如
diskutil）的脚本，需提前授予“完全磁盘访问”权限：系统设置 → 隐私与安全性 → 完全磁盘访问 → 添加终端或脚本所在应用
适配Apple Silicon兼容性细节
若脚本调用二进制工具（如自制编译的curl、ffmpeg），在M1/M2 Mac上可能因架构不匹配（x86_64 vs arm64）而静默失败或报Bad CPU type in executable。
- 用
file /path/to/binary检查目标程序架构 - 在Rosetta终端中运行x86脚本：右键终端App → 显示简介 → 勾选“使用Rosetta打开”
- 更稳妥方式是统一用Homebrew安装arm64原生版本：
arch -arm64 brew install xxx
