部署后确认 artisan 命令正常需三步：先运行 php artisan tinker 验证环境与 autoload；再执行 php artisan db:table 检查数据库连接（注意 db_host 用 127.0.0.1 而非 localhost）；最后查看 storage/logs/laravel.log 是否有类未找到等错误。
Laravel 部署后怎么确认 artisan 命令能正常跑
部署完 Laravel 应用，第一步不是急着开监控，而是确保基础命令通——artisan 本身是否可执行、环境变量是否加载、数据库连接是否就位。很多“监控没反应”其实是 php artisan schedule:run 直接报错退出，但日志里只显示“exit code 1”，根本没进监控逻辑。
实操建议：
- SSH 登录服务器，在项目根目录下手动运行
php artisan tinker，能进交互式终端说明 PHP 环境、autoload、.env 加载基本 OK - 接着跑
php artisan db:table（或php artisan migrate:status），验证数据库连接是否真实可用；注意有些部署环境的DB_HOST写的是localhost，但 MySQL 实际走 socket，得改成127.0.0.1 - 检查
storage/logs/laravel.log最新几行，有没有类似Class 'App\Jobs\CheckDeployment' not found这种 autoloader 失败——常见于部署后没跑composer dump-autoload --optimize
用 telescope 监控部署行为要注意什么
laravel/telescope 是最贴近部署场景的可视化工具，但它默认不记录 artisan 命令执行过程，也不抓部署脚本里的 shell 调用，容易误以为“没数据”是配置问题，其实是它压根不监听这个层面。
实操建议：
- 在
config/telescope.php的watchers数组里显式打开CommandWatcher::class，并确认'enabled' => env('TELESCOPE_COMMAND_WATCHER', true)在 .env 中设为true - 部署脚本中如果用
php artisan down/up，这些命令本身会被记录，但中间的git pull、npm run build不会——别指望 telescope 替你审计整个部署流水线 - Telescope UI 默认只存 24 小时数据，生产环境部署频率低，可能刚点进去就“查无此命”，需要调大
prune_frequencies或关掉自动清理
自己写部署钩子时怎么让监控真正生效
很多人在 deploy.sh 末尾加一行 php artisan event:fire --event=DeploymentCompleted，以为这样就能触发监控，结果事件监听器根本没跑——因为 artisan 命令是在部署用户（如 deploy）下执行的，而队列、监听器常依赖当前用户有权限读取 storage/framework/cache 或写日志。
ApiPost是一个支持团队协作，支持模拟POST、GET、PUT等常见请求，并可直接生成文档的API调试、管理工具，ApiPost是后台接口开发者或前端、接口测试人员的工作必备工具。快速生成、一键导出API文档。感兴趣的朋友快来下载吧。软件说明ApiPost官方版是一款十分出色的接口调试与文档生成工具，ApiPost官方版界面美观大方，功能强劲实用，支持团队协作，支持模拟POST、GET、PUT等常见请求，是后台接口开发者或前端、接口测试人员的工作必备工具。软件特色更方便支持接口调试的同时快速生成、一键
实操建议：
- 所有部署脚本中的
php artisan命令，统一加上--env=production，避免因环境识别错误加载了本地配置 - 如果用了队列（比如发 Slack 通知），别在部署脚本里直接 dispatch，改用
php artisan queue:work --once同步触发一次，否则任务卡在 Redis 里等 worker，而 worker 可能还没重启 - 关键路径加日志：在钩子开头写
echo "$(date): Starting deploy hook" >> /var/log/myapp-deploy.log，比依赖 Laravel 日志更可靠——毕竟日志通道本身可能依赖刚更新的配置
horizon 和 supervisor 对部署监控的影响
Horizon 本质是带 UI 的 Supervisor 封装，但它不感知“部署动作”。如果你用 supervisor 管理 horizon 进程，每次部署后不 reload supervisor，新代码里的 job 类不会被 horizon 加载，导致监控看到的仍是旧逻辑。
实操建议：
- 部署脚本末尾必须包含
sudo supervisorctl reread && sudo supervisorctl update && sudo supervisorctl restart horizon，三步缺一不可；只restart不reread会导致配置未刷新 - Horizon 的
memory_limit默认 64M，部署后首次运行大量 job（比如批量刷新缓存）容易 OOM 退出，表现为 Horizon 进程消失、Web UI 显示 disconnected——要同步调高config/horizon.php里的memory值 - Supervisor 日志（
/var/log/supervisor/horizon-*.log）比 Laravel 日志更早暴露进程级问题，比如ERROR (spawn error)往往是 PHP 路径写错或扩展缺失
部署监控真正的复杂点不在工具本身，而在于它横跨了 PHP 运行时、系统进程管理、文件权限、环境隔离四层。任何一个环节的隐式依赖没显式声明，都会让“看起来启动了”的监控变成盲区。
