cron 报 command not found，终端却能执行：先区分 PATH 与任务隔离环境

脚本在终端运行正常，cron 中却提示 wget: command not found、node: not found。先检查任务自己的 PATH 和执行账户；cron 不会自动获得交互终端里拼装好的全部环境。

但如果改成 /usr/bin/wget 仍提示文件不存在，问题已经超出简单 PATH 范围。面板任务可能运行在受限或隔离的文件系统里，管理员终端能看见这个路径，不代表任务也能看见。

以下例子采用 Linux 用户 crontab 的五字段格式。/etc/crontab 和 /etc/cron.d 还需要用户字段，面板也可能分别配置时间和命令，不能整行照搬。

先记录任务看到的环境

终端中的 command -v wget 只能反映当前终端。可临时添加下面这条诊断任务，/home/app 应替换成任务账户实际可写、且位于任务环境里的目录：

* * * * * /bin/sh -c 'echo "PATH=$PATH"; command -v wget' >> /home/app/cron-path.log 2>&1

它每分钟只记录 PATH 和命令查找结果，不运行下载任务。确认日志出现后立即移除这条临时任务，保留正常业务计划；日志权限按需要控制。不要输出完整 env，其中可能包含秘密。

如果连 /bin/sh 或日志目录都不存在，先检查任务账户、面板隔离模式和路径可见性。日志没生成也可能是输出目录权限或任务未触发，不能直接判断 wget 不存在。

PATH 缺少命令所在目录时，在 crontab 中明确列出所需的可信系统目录，例如：

SHELL=/bin/sh
PATH=/usr/local/bin:/usr/bin:/bin
0 3 * * * /home/app/bin/nightly-job >> /home/app/nightly-job.log 2>&1

这是示例计划，需保留自己的真实执行时间和任务路径。路径选择以实际安装位置为准，不必加入无关目录；避免把其他用户可写的目录放在系统目录前面。脚本中继续使用的命令也会依赖这个 PATH。

绝对路径能消除查找差异，但不是安装命令

如果任务环境里存在 /usr/bin/wget，可以让脚本使用这个明确路径。程序装在其他位置，就使用实际安装位置。/usr/bin/env wget 仍会依赖 PATH，不会自动知道交互终端中的配置。

别名、shell 函数以及登录后加载的版本管理器，不一定是真正的可执行文件。使用 nvm 等工具安装的程序时，应为任务选择明确的可执行路径或受控初始化脚本，并确认版本升级后该路径仍有效。不要把整个交互 .bashrc 当作 cron 必须加载的配置，它可能包含仅终端可用的操作或提前返回逻辑。

此外，cron 常用 /bin/sh 执行命令行。脚本需要 Bash 特性时，应保证它的解释器声明及执行方式匹配，不能仅通过改 PATH 修复 shell 语法错误。

绝对路径仍不存在时，找任务的文件系统边界

若面板报 /usr/bin/env: No such file or directory，而管理员确认宿主机存在它，继续核对面板是否设置了 chroot、受限 shell、容器或其他执行限制。完整路径消除了搜索过程，却没有穿透这些边界。

处理应在任务实际运行环境中安装或提供需要的程序，或让管理员将任务安排到允许执行它的环境；原有安全边界按业务评估，不为一个命令直接关闭整个隔离。

文件看似存在但执行仍报不存在，也要检查脚本解释器或程序加载器是否在该环境中。若错误是 Permission denied，则检查执行权限、挂载限制或策略，这与 command not found 又是不同分支。

等到下一次计划执行，再判断是否修好

修改前保存现有 crontab 和脚本；一次只调整必要的环境或路径，避免误删其他任务。恢复时将本次修改的环境与任务行改回，诊断日志按维护要求保留或清理。

成功标准是按真实计划触发的任务使用预期程序版本、没有查找错误，并产生正确业务结果。手动在交互终端执行成功不足以验收 cron。若任务可能重叠或写入数据，验证时遵循原有防重入措施，不额外添加会重复执行业务的高频任务。