根本原因是环境不一致：PATH、权限、glibc版本、/bin/sh指向（dash/bas）、SELinux上下文、临时目录挂载选项等差异导致脚本或服务行为异常，需逐项验证。
为什么脚本在测试机跑通，一上生产就挂？
根本原因往往是环境不一致，而不是脚本本身有 bug。Shell 脚本极度依赖运行时上下文，PATH、用户权限、glibc 版本、甚至 /bin/sh 指向的解释器（dash vs bash）都可能让同一份脚本行为迥异。
- 用
ls -l /bin/sh确认默认 shell —— Debian/Ubuntu 默认是dash，不支持[[ ]]或数组，而 CentOS 通常是bash - 在脚本开头强制指定解释器：
#!/usr/bin/env bash，避免隐式依赖系统默认 - 别信“PATH 一样”，执行
echo $PATH对比两台机器；更稳妥的是所有命令写绝对路径，比如用/usr/bin/curl而非curl - 检查 glibc 兼容性：
ldd --version | head -n1，若生产环境版本更低，编译好的二进制或 Java 程序会直接报GLIBCXX not found
服务启动成功了，但 curl 不通？查这三处
自动化部署常卡在“看似成功，实则不可用”阶段。启动命令返回 0 不代表服务真在监听、可响应、能连数据库。
- 确认端口监听：
ss -tlnp | grep :8080，不是netstat（已逐步淘汰），且必须带-p看属主，避免被其他进程占坑 - 验证本地连通性：
curl -v http://localhost:8080/health，别只看systemctl is-active—— 它只管进程是否存活 - 检查依赖服务状态：比如 Tomcat 依赖数据库，要单独验证
mysql -h 127.0.0.1 -u app -p appdb -e "SELECT 1"，不能只等应用日志报错才行动
权限问题不是 chmod 777 就完事
盲目加权限反而掩盖真实问题，还引入安全风险。Linux 权限失败的核心，其实是“谁在操作、对什么路径、以什么上下文”三者不匹配。
