linux运行php脚本

凌晨三点，脚本服务器报警邮件把我从床上拽起来。脚本登录上去一看，脚本PHP进程占满了CPU，脚本日志里躺着一堆超时错误。脚本同事写的脚本爬虫脚本本该每小时跑一次，结果它自己循环起来了，脚本停都停不住。脚本这种破事在Linux上跑PHP时太常见了——脚本本身没问题，脚本但没人告诉它该怎么被系统管着。脚本

最直接的脚本运行方式谁都会：php /path/to/script.php。终端里敲一下，脚本输出就出来了。脚本但真实生产环境没这么天真。脚本你得让脚本变成守护进程，脚本或者交给cron定时调度，还得处理输出日志、环境变量、用户权限这些破事。

拿crontab举例。你写个*/5 * * * * php /data/jobs/sync.php，以为就完事了？错。cron的环境变量和登录shell完全不一样，PATH可能都不包含php的安装目录。更坑的是，脚本里要是用了相对路径，cron的工作目录默认是用户家目录，文件找不到直接报错。我见过太多人栽在这上面——脚本手动跑得好好的，一进cron就废。

正确做法是写个shell包装脚本，把环境变量、路径、日志重定向全部处理好。比如：

#!/bin/bash export PATH=/usr/local/bin:/usr/bin:$PATH cd /data/jobs php sync.php >> /var/log/sync.log 2>&1

然后把cron指向这个shell脚本，而不是直接调php。这样出问题也好排查，日志全在一个文件里躺着。

再往深了说，用systemd管理PHP长驻脚本是更现代的选择。写个service单元文件，定义好ExecStart、Restart=always，系统崩溃了自动拉起。这比nohup加&强一万倍——至少你能用systemctl status看到进程状态，而不是满服务器找PID。

有个细节很多人忽略：PHP脚本里的内存限制。CLI模式下memory_limit默认是-1，也就是不限制。但某些发行版会编译成128M。处理大文件或跑队列的时候，内存爆了直接Segmentation fault，连错误提示都不给你。跑之前先php -i | grep memory_limit确认下，别等崩了才后悔。

还有个真实案例。去年我帮朋友调一个电商库存同步脚本，每五分钟跑一次，但经常出现两个实例同时执行——上次没跑完，cron又触发新的。数据全乱套了。解决办法是用flock命令加锁：

flock -n /tmp/sync.lock -c "php sync.php" || echo "已有实例在跑"

这玩意儿简单粗暴，但比你自己写PID文件判断可靠多了。

最后说个容易踩的坑：时区。PHP默认时区是UTC，如果你的业务面向国内用户，日志时间戳看着总差八小时。在php.ini里设date.timezone = Asia/Shanghai，或者脚本开头date_default_timezone_set('Asia/Shanghai')。别小看这个，排查线上问题时候差八小时能让你抓狂到怀疑人生。

Linux跑PHP脚本，说白了就是跟系统打交道。你得懂点shell、懂点systemd、懂点文件权限。别指望PHP自己处理所有事——它只是个语言，不是操作系统。把脚本当孙子一样伺候好，给它明确的环境、明确的调度、明确的日志，它才给你稳定输出。不然就是凌晨三点的报警邮件，等着你。