最可靠方式是readlink -f "$0"，需加双引号并注意环境兼容性；不支持-f时用(cd "$(dirname "$0")" && pwd -P)兜底，二者均能正确解析软链接和相对路径。
直接结论：用 readlink -f "$0" 是最可靠的方式，但必须加双引号、注意环境兼容性；若目标系统不支持 -f（如 Alpine、BusyBox 或 macOS），改用 cd "$(dirname "$0")" && pwd -P 子 shell 写法。
为什么 $0 不能直接当路径用
执行脚本时，$0 只保存调用时的原始字符串：可能是 ./run.sh、mylink（软链接名）、甚至只是 script（来自 $PATH）。它不解析软链接，也不补全相对路径。直接对 $0 做 dirname 或 cd，在软链接、相对路径或空格路径下极易出错。
常见错误现象：
-
dirname $0遇到含空格路径（如/path/to/my script.sh）会拆成两个参数，报错dirname: extra operand -
cd $(dirname $0)在软链接调用时进入的是链接所在目录，而非目标脚本所在目录 -
pwd返回的是当前工作目录，不是脚本所在目录——两者完全无关
readlink -f "$0" 的正确用法和限制
它能一次性完成三件事：补全相对路径、递归解析所有软链接、返回目标文件的真实绝对路径。但有两个硬约束：
- 必须用双引号包裹
"$0"，否则路径含空格时失效 - 部分精简环境（如 Alpine Linux 默认 busybox、某些容器镜像、macOS）不支持
-f选项；macOS 需装coreutils并用greadlink -f
获取目录而非完整路径时，别写成 dirname $(readlink -f $0)（没引号），而应写：
SCRIPT_DIR=$(dirname "$(readlink -f "$0")")
注意：如果脚本是被 source 加载的，<p>注意：如果脚本是被 <code>source 加载的，$0 是 shell 名（如 -bash），此法彻底失效——此时只能靠调用方传入路径，或改用 ${BASH_SOURCE[0]}（仅 Bash 且仍需 readlink 配合）。
-bash），此法彻底失效——此时只能靠调用方传入路径，或改用 ${BASH_SOURCE[0]}（仅 Bash 且仍需 readlink 配合）。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
不依赖 readlink 的纯 Bash 兜底方案
当无法确认目标系统是否支持 readlink -f 时，用子 shell 执行 cd + pwd -P 是最广泛兼容的替代：
SCRIPT_DIR=$(cd "$(dirname "$0")" && pwd -P)
这个写法的关键点：
-
cd在子 shell 中执行，不会污染父 shell 当前工作目录 -
pwd -P强制解析软链接，返回物理路径（-L才跟随链接，但默认就是-L，所以必须显式写-P） - 依然要双引号包裹
"$(dirname "$0")"，防空格断裂
性能影响几乎可忽略；但要注意：如果脚本所在目录本身是软链接（比如 /opt/app → /srv/real-app），该方案返回的是 /srv/real-app，不是 /opt/app——这正是“真实路径”的本意，但业务若依赖链接路径（比如日志写到 /opt/app/logs），就得另做判断。
容易被忽略的边界情况
真正出问题的地方，往往不在常规路径，而在这些细节：
- 脚本被硬链接调用时，
readlink -f和pwd -P行为一致，没问题；但硬链接本身极少被意识到 - 脚本内容依赖同目录下的
config.yaml，而你用source ./common.sh加载它——此时$0完全不可信，${BASH_SOURCE[0]}是唯一可用入口，但仍得配readlink - 在 systemd service 或 cron 中运行脚本时，当前工作目录通常是
/或/root，pwd完全没用，必须靠$0衍生路径
没有银弹。选 readlink -f 还是子 shell cd && pwd -P，取决于你控制得了运行环境，还是必须向最小公分母妥协。
