把一个在终端里手动执行完全正常的Node.js脚本，挂到crontab里通过PHP的exec()去调用，结果发现任务根本没有执行成功——这种问题几乎每个做过后端和运维的人都遇到过。最让人头疼的是，cron环境下往往看不到任何报错，日志一片空白，仿佛脚本从来没被运行过。其实这类问题的根源绝大多数都指向同一个方向：cron的执行环境和你登录shell的环境完全不是一回事。本文就来系统地分析原因并给出可落地的解决方案。
一、为什么手动执行正常，crontab里就失败
要解决问题，先要理解cron的运行机制。crontab执行任务时，并不是在你的登录shell里跑命令，而是由cron守护进程fork出一个极简的环境。这个环境通常只有几个最基本的变量，比如PATH往往只有/usr/bin:/bin这样的取值，远不如交互shell里完整。
而Node.js通常安装在/usr/local/bin/node、/opt/node/bin/node，或者通过nvm安装在用户目录下（例如/root/.nvm/versions/node/v18.x.x/bin/node）。这些路径都不在cron默认的PATH里，于是当你写下exec("node script.js")时，系统根本找不到node命令，PHP返回的输出为空，退出码也不是0。
另一个常见原因是工作目录。cron执行任务时的工作目录通常是用户家目录，而你的PHP脚本里如果使用了相对路径去引用Node.js脚本，比如exec("node ./tasks/sync.js")，那么实际查找的文件路径就是错的，自然执行失败。此外，nvm管理的Node在非交互shell下不会自动加载nvm.sh，这是最容易被忽视的一个坑。
二、排查：让错误信息先暴露出来
很多人遇到cron任务失败后第一反应是反复改代码，其实正确的做法是先把错误信息挖出来。第一步，在crontab里把标准输出和错误输出都重定向到日志文件：
*/5 * * * * /usr/bin/php /var/www/html/cron/task.php >> /var/log/mytask.log 2>&1
注意结尾的2>&1，它把stderr合并到stdout，很多报错信息（比如node找不到模块、权限拒绝）都走的是stderr通道，不加这个重定向你将什么都看不到。
第二步，在PHP代码里不要只调用exec就完事，要把执行结果和退出码都拿到：
<?php
$cmd = '/usr/local/bin/node /var/www/scripts/sync.js 2>&1';
exec($cmd, $output, $exitCode);
echo "退出码: " . $exitCode . "\n";
echo "输出: " . implode("\n", $output) . "\n";exec()的第二个参数$output按行收集命令输出，第三个参数$exitCode是命令退出码。0表示成功，127表示命令未找到，126表示无执行权限，1通常是脚本自身抛出了异常。拿到退出码，问题范围一下子就缩小了。还可以用which node在交互终端确认node的真实路径，用echo $PATH对比cron环境下的PATH差异。
三、解决方案：从绝对路径到环境变量完整配置
1. 使用node的绝对路径
最简单直接的办法是放弃依赖PATH查找，直接写绝对路径。先在终端执行which node拿到路径，然后在PHP中硬编码：
<?php
$node = '/usr/local/bin/node'; // which node 的结果
$script = '/var/www/scripts/sync.js'; // 脚本也用绝对路径
exec("$node $script 2>&1", $output, $code);如果node是通过nvm安装的，绝对路径会类似/root/.nvm/versions/node/v18.19.0/bin/node。建议为这个路径做一个软链接到/usr/local/bin/node，这样升级版本时也不用改PHP代码：ln -s /root/.nvm/versions/node/v18.19.0/bin/node /usr/local/bin/node。
2. 在crontab中显式声明PATH
也可以在crontab文件顶部直接声明环境变量，这对该文件中的所有任务生效：
SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin */5 * * * * /usr/bin/php /var/www/html/cron/task.php >> /var/log/mytask.log 2>&1
如果脚本依赖nvm，还可以让cron通过登录shell的方式执行，强制加载用户配置：
*/5 * * * * source /root/.bashrc && /usr/bin/php /var/www/html/cron/task.php >> /var/log/mytask.log 2>&1
注意这种写法要求crontab的SHELL设置为bash，某些精简系统默认是sh，可能不支持source。
3. 处理NODE_PATH与全局模块问题
Node.js脚本如果依赖全局安装的npm包（npm install -g方式），在非标准环境下运行时可能报Cannot find module 'xxx'。这是因为全局模块的查找路径依赖NODE_PATH变量或者npm的安装前缀。解决办法是在执行时显式传入：
<?php $cmd = "NODE_PATH=/usr/lib/node_modules /usr/local/bin/node /var/www/scripts/sync.js 2>&1"; exec($cmd, $output, $code);
更推荐的做法是尽量把依赖装到项目本地，用npm install装在脚本所在目录的node_modules里，这样脚本会自动向上查找依赖，彻底摆脱对环境变量的依赖，部署到任何机器都更省心。
四、权限、用户与超时等容易被忽略的细节
除了环境问题，还有几个细节需要逐项检查。首先是执行用户：你的crontab属于哪个用户，PHP就会以哪个用户身份调用node。如果Node.js脚本要写入某些目录，而cron用户没有写权限，脚本会静默失败。用crontab -e编辑的是当前用户的任务，root的任务和www-data的任务是相互独立的，确认你编辑的是正确的那个。
其次是PHP自身的限制。exec()函数依赖safe_mode_allowed_exec_vars等历史配置早已废弃，但disable_functions中如果禁用了exec，调用会直接报错，检查php.ini确认该函数未被禁用。另外如果PHP以FPM方式运行且有max_execution_time限制，Node.js脚本耗时较长时，PHP进程可能先被杀掉，此时应考虑用nohup把Node脚本放到后台异步执行：
<?php $cmd = 'nohup /usr/local/bin/node /var/www/scripts/sync.js >/dev/null 2>>/var/log/sync.err &'; exec($cmd);
最后建议为整个链路建立日志习惯：PHP侧记录退出码，Node侧用fs.appendFileSync写运行日志，crontab侧重定向标准输出。三层日志齐全后，任何一次失败都能在一分钟内定位到具体环节。排查这类问题的通用心法可以总结为一句话：不要相信环境，一切路径用绝对路径，一切输出都落到日志，一切结果都检查退出码。做到这三点，cron调Node.js脚本的稳定性就有了基本保障。
PHP exec crontabNode.js脚本crontab环境变量修改时间：2026-09-15 05:51:25