PHP定时任务不能仅用@抑制错误，因其不阻止脚本中断且仍写日志；应结合set_error_handler、try/catch、显式exit(0)、超时设置、独立日志及crontab重定向实现真正静默。
PHP定时任务报错为什么不能直接用 @ 抑制
加 @ 前缀看似能“静音”错误，但实际只是屏蔽了错误显示，error_log 仍会记录、display_errors=Off 下也照常写日志，更关键的是——它不阻止脚本中断。比如 @file_get_contents("https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39") 超时或 DNS 失败，照样抛出 Warning 并可能让 cron 认为任务异常退出（返回非 0 状态码），触发告警或重试。
真正安静的定时任务：捕获 + 静默退出
核心是让脚本无论发生什么都稳定返回 0，并且不向 stderr/stdout 写任何东西。推荐组合：try/catch 捕获异常 + set_error_handler 拦截警告 + 显式 exit(0)：
set_error_handler(function($severity, $message, $file, $line) {
// 什么也不做，彻底静默
}, E_ALL);
try {
// 你的业务逻辑，比如 file_get_contents、PDO 查询、curl_exec
$data = json_decode(file_get_contents('https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39'), true);
} catch (Exception $e) {
// 也什么都不做
}
exit(0); // 强制成功退出，cron 不报警
- 必须在脚本开头注册
set_error_handler，否则E_WARNING类错误进不了回调 -
file_get_contents的超时需显式设stream_context_create(['http' => ['timeout' => 5]])，否则默认 60 秒阻塞，cron 可能 kill 掉进程 - 如果用了
curl，记得关掉CURLOPT_FAILONERROR和CURLOPT_VERBOSE，避免 curl 自己往 stderr 输出
日志要留痕，但不能吵
“安静”不等于“没发生”。建议把错误写入独立日志文件，而非系统 syslog 或 PHP 错误日志（后者常被监控盯住）：
立即学习“PHP免费学习笔记（深入）”；
$log = fopen('/var/log/my-cron-job.log', 'a');
fwrite($log, date('Y-m-d H:i:s') . " ERROR: " . $e->getMessage() . "\n");
fclose($log);- 路径确保 cron 运行用户（如
www-data或root）有写权限，否则日志写失败本身又成新错误 - 避免用
error_log()，它默认走 PHP 配置的error_log，容易和其它服务混在一起，干扰监控 - 日志文件建议按天轮转，或用
rotatelogs配合 cron，不然单文件越滚越大
crontab 本身也要配静默
cron 默认把 stdout/stderr 邮给用户，即使 PHP 脚本不输出，PHP 启动错误（如扩展没装）或 shell 层问题（如找不到 php）仍会发邮件。在 crontab 条目末尾加 > /dev/null 2>&1：
* * * * * /usr/bin/php /path/to/script.php > /dev/null 2>&1
- 注意：必须用绝对路径调用
php，cron 的$PATH很窄，which php结果未必可用 -
2>&1要写全，漏掉&会导致2>1（重定向到名为 “1” 的文件），不是合并流 - 首次部署后，手动跑一遍该命令，确认无 permission denied、command not found 等 shell 层报错
真正的安静不是让错误消失，是让它只出现在你主动查看的地方。最常被跳过的一步：忘了检查 crontab -e 编辑后是否生效（有些系统要 sudo systemctl restart cron），以及日志文件权限是否随系统更新被重置。
