CentOS中crontab调用bash脚本及批量运行带参数PHP页面的最佳方式

嘿，刚好处理过类似的批量定时任务场景，给你拆解下问题里的各个点：

为什么别直接加50个Crontab任务？ #

• 维护噩梦：想象下crontab里堆50条几乎一样的任务，后期要改路径、加参数，得一条条找，很容易漏改或者改错。
• 资源炸锅风险：每分钟同时启动50个PHP进程，服务器CPU、内存瞬间被占满的概率极高，轻则其他服务变慢，重则直接宕机。

推荐方案：单Crontab任务+Bash脚本批量管控 #

用一个Crontab任务调用Bash脚本，在脚本里处理50个页面的执行，优势拉满：

• 集中管理：所有页面列表和执行逻辑都在一个脚本里，增删改查超方便。
• 可控并发：可以给每个PHP执行之间加个短暂延迟（比如1秒），把瞬间压力平摊开，服务器负载更平稳。

示例Bash脚本（比如命名为run_php_jobs.sh） #

#!/bin/bash
# 用数组存所有要执行的页面，带查询参数也完全没问题
target_pages=(
    "/var/www/your-site/page.php?id=1"
    "/var/www/your-site/page.php?id=2"
    # ... 这里补全剩下的48个页面
    "/var/www/your-site/page.php?id=50"
)

# 遍历数组执行每个任务，间隔1秒避免并发过高
for page in "${target_pages[@]}"; do
    # 两种执行方式可选：
    # 1. 直接用PHP CLI执行（适合不需要Web环境的脚本）
    /usr/bin/php "$page"
    # 2. 如果依赖Web服务器的环境变量/重写规则，用curl发起HTTP请求
    # curl -s "http://your-domain.com$page" > /dev/null 2>&1
    
    # 加1秒延迟，根据服务器性能调整
    sleep 1
done

关于?id=1这类查询参数的注意点 #

能不能用分两种情况：

• PHP CLI模式：直接写php page.php?id=1是没用的，CLI不会自动解析HTTP查询参数。这时候得改成CLI参数，比如php page.php 1，然后在PHP代码里用$argv[1]获取；或者在脚本里设置环境变量让PHP读取。
• HTTP请求模式（curl/wget）：完全没问题，直接写curl "http://your-domain.com/page.php?id=1"，Web服务器会正常解析参数，和你在浏览器里访问一样。

CentOS中让Crontab调用Bash脚本的步骤 #

操作很简单，按顺序来：

1. 给脚本加执行权限：

   chmod +x /path/to/run_php_jobs.sh
   

2. 编辑Crontab任务：
   执行crontab -e打开编辑界面，添加这一行：

   * * * * * /bin/bash /path/to/run_php_jobs.sh >> /var/log/php_cron_tasks.log 2>&1
   

   解释下各个部分：
   • * * * * *：代表每分钟执行一次（Crontab的时间规则：分 时 日 月 周）
   • /bin/bash：指定用Bash解释器执行，避免系统默认shell差异导致脚本跑崩
   • >> /var/log/php_cron_tasks.log 2>&1：把脚本的输出和错误都写到日志文件，方便后期排查问题
3. 保存退出：按Ctrl+O保存，Ctrl+X退出，Crontab会自动加载新任务，不用重启服务。

额外提醒 #

• 脚本里所有路径都用绝对路径！Crontab的默认PATH很窄，相对路径大概率找不到文件（比如PHP的路径，用which php查绝对路径，比如/usr/bin/php）。
• 先手动执行脚本测试：/bin/bash /path/to/run_php_jobs.sh，确保没有报错再加到Crontab里，避免定时任务跑崩了才发现问题。

内容的提问来源于stack exchange，提问作者MrMax