Laravel 12任务调度不支持开机自启，本质是依赖系统Cron每分钟触发schedule:run命令；需确保cron服务开机自启，并以运行项目的用户（如www-data）在crontab中添加对应执行行。
Laravel 12 的任务调度本身**不直接支持“开机自启”**，因为它依赖的是外部定时触发机制——不是服务进程，而是一条每分钟运行的 schedule:run 命令。所以“让 Laravel 调度开机自启”的本质，是**确保系统 Cron 守护进程（cron 或 crond）开机自动运行，并且你的 crontab 条目已正确写入**。
确保系统 Cron 服务开机自启
这是前提，没有它，schedule:run 根本不会被调用。
- Ubuntu/Debian：
sudo systemctl enable cron
sudo systemctl start cron - CentOS/RHEL/AlmaLinux：
sudo systemctl enable crond
sudo systemctl start crond
验证是否生效：
sudo systemctl is-enabled cron（或 crond）应返回 enabled；
sudo systemctl status cron 应显示 active (running)。
把调度命令写进用户级 crontab
不是写进 /etc/crontab，而是用当前运行 Laravel 的用户（如 www-data、nginx 或部署用户）执行 crontab -e，添加这一行：
* * * * * cd /var/www/myapp && php artisan schedule:run >> /dev/null 2>&1
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
注意：
• 替换 /var/www/myapp 为你的实际项目绝对路径；
• 确保该用户对项目目录有读写权限，且能执行 php；
• 不要用 sudo crontab -e，否则命令会以 root 身份运行，可能引发权限或环境变量问题。
别混淆：不是启动 Laravel 进程，而是启动调度“触发器”
Laravel 调度不是常驻后台的服务（像 schedule:work 那样），它靠的是“被动触发 + 主动检查”。
• schedule:run 是一个瞬时命令，执行完就退出；
• 真正的“调度逻辑”在 PHP 代码里（app/Console/Kernel.php），由这条 cron 每分钟拉起一次来判断该跑什么；
• 所以你不需要、也不应该用 systemd 去守护 schedule:run —— 它本来就不是长期进程。
特殊情况：想用 schedule:work（需 systemd 守护）
如果你明确选择 schedule:work（毫秒级精度、避免 Cron 1 分钟延迟），那它才是一个需要长期运行的 Artisan 进程，此时才需 systemd 自启：
- 创建
/etc/systemd/system/laravel-schedule.service：
[Unit]
Description=Laravel Schedule Worker
After=network.target
[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/php /var/www/myapp/artisan schedule:work
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
- 启用：
sudo systemctl daemon-reload
sudo systemctl enable laravel-schedule
sudo systemctl start laravel-schedule
但注意：这属于进阶替代方案，标准生产环境仍推荐 schedule:run + 系统 cron，更轻量、更符合 Laravel 设计初衷。
