Linux cron 环境变量和交互式 shell 为什么不同

同一条命令，手工在终端执行成功，放进 Linux cron 却提示找不到命令或找不到文件，通常不是 cron 没有执行，而是它启动的 shell 环境与登录后的交互式 shell 不同。cron 不会自动复刻你的交互式启动文件；任务使用的 SHELL、可执行文件搜索范围 PATH、HOME 和当前目录 PWD 都应该按任务需要显式确认。

排查 cron 环境时，先记录任务实际看到的 PATH、SHELL、HOME 和 PWD，再在 crontab 中显式设置 PATH，并用 cd 和绝对路径固定工作目录与脚本位置。

一、先区分 cron 和交互式 shell 的启动边界

登录 shell 和 cron 都能启动命令，但来源不同。交互式 shell 可能根据启动方式读取登录启动文件，随后继承用户在终端里配置的变量；crontab 则由 cron 守护进程组装任务环境。常见实现会设置 SHELL、HOME 和 LOGNAME，而 SHELL、HOME 可以在 crontab 中覆盖。PATH 的默认值与发行版、cron 实现和系统配置有关，不要把某一台机器的默认路径当成 Linux 统一规则。

还要把“解释器”和“环境变量”分开看：SHELL=/bin/sh 表示命令由哪个 shell 解释，不代表它会加载 Bash 的交互式配置；PATH 只影响 report 这类裸命令的查找，不会替你切换工作目录。PWD 记录任务当前目录，但它不是可靠的项目定位方式，任务应主动 cd 到目标目录。

二、用 PATH、SHELL 和工作目录复现差异

不要先把任务改成加载整份个人配置。先做一个只记录环境的最小脚本，把 cron 的真实输入保存下来，再和手工执行脚本时的结果对照。

#!/bin/sh
# 只记录 cron 任务真正看到的四个关键边界
{
  printf 'PATH=%s\n' "$PATH"
  printf 'SHELL=%s\n' "$SHELL"
  printf 'HOME=%s\n' "$HOME"
  printf 'PWD=%s\n' "$PWD"
} >> /var/tmp/cron-env.txt

保存为 /srv/app/bin/print-cron-env.sh 后赋予执行权限，并暂时使用绝对路径放进用户 crontab：

# 让脚本可以被 cron 直接执行
chmod 755 /srv/app/bin/print-cron-env.sh

# 每分钟记录一次，确认环境而不是猜测环境
* * * * * /srv/app/bin/print-cron-env.sh

一分钟后查看 /var/tmp/cron-env.txt。如果 PATH 比终端短，裸写的 node、go 或自定义命令就可能失败；如果 PWD 不是项目目录，相对路径如 ./config.yml 也会指向错误位置。这个记录脚本只用于确认边界，正式任务应删除或改为受控日志。

三、给 cron 任务补齐可控的环境边界

修复时优先把任务需要的边界写在任务附近，而不是依赖某个用户恰好拥有的交互式配置。下面的示例把解释器、命令搜索范围、主目录、工作目录、脚本路径和日志路径全部写明：

# 明确 cron 使用的 shell、命令搜索范围和主目录
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
HOME=/home/app

# 先进入项目目录，再用绝对路径运行并记录标准输出和错误
*/5 * * * * cd /srv/app && /srv/app/bin/report >> /var/log/report.log 2>&1

这里的 PATH 是示例值，实际应按目标发行版和服务安装位置收敛；如果程序依赖虚拟环境、Go 工具链或自定义目录，就把必要目录明确加入，而不是整段复制个人配置。cd /srv/app 解决的是相对路径基准，/srv/app/bin/report 解决的是脚本定位，/var/log/report.log 解决的是输出落点，三者分别对应不同故障。

四、检查日志、shell 语法和相对路径

任务仍失败时按四个问题复查：第一，PATH 是否包含命令所在目录；第二，脚本语法是否真的适用于 SHELL，例如把 Bash 专属语法交给 /bin/sh；第三，是否在任务命令中明确 cd；第四，重定向目标的父目录和权限是否存在。

检查脚本语法可以在目标 shell 下执行：

# 用任务声明的解释器检查语法，不依赖当前交互式 shell
/bin/bash -n /srv/app/bin/report

# 查看脚本和日志目录是否存在，避免把路径错误误判成环境变量错误
test -x /srv/app/bin/report && echo 'script-ok'
test -d /var/log && echo 'log-dir-ok'

如果日志完全没有产生，先看重定向目录和任务用户权限；如果日志出现 command not found，对照记录下来的 PATH；如果报配置文件不存在，优先检查 PWD 与 cd。不要用加载完整 .bashrc 作为万能修复，它可能引入交互提示、别名、副作用或与 cron 不兼容的输出。

常见问题

cron 会自动读取 ~/.bashrc 吗？

不能这样假定。cron 启动的是非交互任务，是否读取某个文件取决于你显式调用的 shell 和启动方式。更稳妥的做法是把任务所需变量写清楚，并使用绝对路径。

SHELL 设置成 /bin/bash 就能得到完整终端环境吗？

不能。它只改变命令解释器；PATH、HOME、PWD 以及启动文件是否读取仍要分别处理。需要 Bash 语法时声明解释器，需要变量时显式设置变量。

为什么手工执行 ./report 成功，cron 却失败？

最常见是手工执行时已经位于项目目录，而 cron 的 PWD 不同。用 cd /srv/app && /srv/app/bin/report 同时固定目录和脚本位置，通常比依赖相对路径可靠。