PHP脚本不能直接开机自启，需通过systemd等外部机制托管；推荐用systemd管理长时PHP进程，脚本须含shebang且主流程常驻（如while(true)循环）。
PHP 脚本本身不能“嵌入式开机自启”——它不是系统服务，没有守护进程能力，必须依赖外部机制托管。直接用 php /path/to/script.php 启动后脚本退出，无法持续运行；若想长期驻留并随系统启动，得把它包装成系统服务或用进程管理工具兜底。
用 systemd 服务管理 PHP 长时脚本（推荐）
Linux 发行版（如 Ubuntu 22.04+、CentOS 7+）默认用 systemd，这是最稳定、可控的方式。关键点不是“运行 PHP”，而是让 systemd 管理一个持续存活的 PHP 进程（比如用 while(true) 循环 + sleep，或监听 socket 的 CLI 服务）。
- 脚本开头必须有可执行 shebang，例如：
#!/usr/bin/env php
- 避免脚本自行
exit或执行完就终止；需保持主流程常驻，例如： - 服务单元文件（如
/etc/systemd/system/php-daemon.service）内容示例：[Unit] Description=PHP Background Daemon After=network.target [Service] Type=simple User=www-data WorkingDirectory=/var/www/myapp ExecStart=/usr/bin/php /var/www/myapp/daemon.php Restart=always RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target
- 启用并启动：
sudo systemctl daemon-reload→sudo systemctl enable php-daemon.service→sudo systemctl start php-daemon.service - 验证状态：
sudo systemctl status php-daemon.service，日志查journalctl -u php-daemon.service -f
为什么不用 crontab @reboot？
@reboot 只触发一次，适合初始化任务（如写个时间戳文件），不适合需要长期运行的脚本。常见错误是写成：@reboot php /path/to/script.php & —— 这样进程会脱离 session，在 systemd 环境下极易被 cgroup 杀掉，且无重启兜底、无日志追踪、用户环境变量（如 $PATH）可能缺失。
- 如果坚持用 cron，至少加完整路径和重定向：
@reboot /usr/bin/php /opt/app/loop.php >> /var/log/php-loop.log 2>&1 & - 但依然不推荐：无法感知崩溃、无法限制内存/CPU、systemd 不会将其纳入服务生命周期管理
PHP 脚本自身要注意的坑
CLI 模式和 Web 模式差异很大，很多隐性依赖在开机时会失败。
立即学习“PHP免费学习笔记（深入）”；
- 禁用超时：
set_time_limit(0)必须显式调用，否则默认 30 秒中断 - 忽略用户中断信号：
pcntl_signal(SIGTERM, SIG_IGN)和pcntl_signal_dispatch()配合，防止被 systemd kill 时异常退出（仅当pcntl扩展启用时有效） - 工作目录不可靠：开机时当前路径可能是
/，务必用chdir(__DIR__)或绝对路径操作文件 - 数据库/Redis 连接要带重连逻辑：服务（如 MySQL）可能比 PHP 脚本启动慢，首次连接失败不能直接 exit
- 不要依赖
$_SERVER变量：CLI 下多数为空，改用getenv()或配置文件
真正难的不是“怎么启动”，而是“怎么稳住”——PHP 不是为长时运行设计的语言，没内存回收压力测试、没信号优雅退出、没自动 reload 机制。如果业务逻辑复杂，建议迁移到 Swoole、Workerman 或改用 Python/Go 写守护进程；若只是轻量轮询，systemd + 简单 while 循环已足够，但务必加上日志、重试、资源限制（MemoryLimit=128M 可加在 service 文件的 [Service] 下）。
