Laravel 13 Cloud Facade 怎么判断托管队列：hosted 与 usesManagedQueues 的边界

同一套 Laravel 13 应用同时跑在本地、普通服务器和 Laravel Cloud 时，业务代码不该到处判断部署环境。新的 Cloud Facade 把这件事收口成三个入口：hosted() 判断是否托管在 Laravel Cloud，usesManagedQueues() 判断是否使用托管队列，queue() 在已配置时提供对应的队列连接。

先把判断边界分清楚

这三个方法看起来都与云环境有关，但问题完全不同。应用可能由 Laravel Cloud 托管，却没有使用托管队列；因此不能用 hosted() 代替队列能力判断。反过来，业务层也不应该直接依赖云平台细节，只需要知道最终应使用哪条队列连接。

use Illuminate\Support\Facades\Cloud;

if (Cloud::hosted() && Cloud::usesManagedQueues()) {
    $queue = Cloud::queue();
    // 在已确认托管队列可用的分支中使用连接
}

这里别急着把所有发送逻辑塞进条件块。先把部署判断写对，再把连接选择封装成单一入口，后续测试和回退都会轻很多。

三个方法分别回答什么

从结构上看，业务代码只访问 Cloud Facade；Cloud Facade 再暴露 hosted()、usesManagedQueues() 与 queue()。前两个是判断入口，最后一个连接 Laravel Cloud 提供的队列能力。图中的分组刻意把“环境判断”和“连接获取”拆开，避免把布尔状态当成连接对象。

把托管差异收口到运行时适配层

更稳妥的项目结构是让控制器只调用队列适配器。队列适配器通过 Cloud Facade 选择托管队列或默认队列，业务层不认识平台 API。配置测试也只覆盖队列适配器：分别构造托管能力成立与不成立的配置，确认路由结果，而不是让每个控制器重复判断。

封装后的接口可以保持很小，例如让适配器只提供 connection() 或 dispatch()。这样将来托管能力变化时，只改一处；本地开发和传统部署仍走框架原有的默认队列配置。

运行检查与失败回退

• 先检查环境：记录 hosted() 的结果，但不要据此直接认定托管队列存在。
• 再检查能力：只有 usesManagedQueues() 成立，才进入 queue() 分支。
• 保留默认连接：普通服务器、本地开发或未启用托管队列时，继续使用项目既有的默认队列。
• 隔离平台代码：控制器、领域服务和任务类不要重复调用 Cloud Facade，统一经过队列适配器。

这套检查不等于替代监控。上线后仍要观察任务积压、失败任务和处理延迟；Cloud Facade 解决的是运行时能力识别，不负责证明队列消费已经健康。

常见问题

hosted() 返回 true，就一定能调用 queue() 吗？

不能这样推断。托管环境与托管队列是两个条件，应继续检查 usesManagedQueues()，再在配置成立的分支中取得队列连接。

普通服务器上的 Laravel 13 项目需要使用 Cloud Facade 吗？

不需要强制使用。若项目没有 Laravel Cloud 与普通环境并存的需求，继续使用原有队列配置更直接；混合部署时再通过适配器集中处理差异。