如何在Quasar+Vue.js+Capacitor构建的混合应用中实现推送消息功能？

为什么之前的Service Worker方案失效 #

Capacitor打包的移动端应用运行在原生WebView容器中，移动端WebView对Service Worker的生命周期限制极强，且系统级推送通道的优先级远高于Web层服务，纯Web侧的Firebase Service Worker方案天然不支持移动端混合应用场景，仅能在桌面浏览器环境生效。

最优实现路径 #

第一步：接入原生推送插件实现基础消息接收 #

使用Capacitor官方维护的原生推送插件，在系统层面对接FCM/APNs通道，稳定性最高：

• 安装插件：

  npm install @capacitor/push-notifications
  npx cap sync
  

• Firebase配置：分别在Firebase控制台生成Android端的google-services.json、iOS端的GoogleService-Info.plist，放到对应原生工程的根目录
• 前端注册监听逻辑：

  import { PushNotifications } from '@capacitor/push-notifications';
  
  // 注册推送权限
  const initPush = async () => {
    const permStatus = await PushNotifications.checkPermissions();
    if (permStatus.receive === 'prompt') {
      await PushNotifications.requestPermissions();
    }
    if (permStatus.receive !== 'granted') return;
    await PushNotifications.register();
  }
  
  // 监听前台收到的推送
  PushNotifications.addListener('pushNotificationReceived', (notification) => {
    // 自定义前台消息处理逻辑
    console.log('收到前台推送', notification);
  });
  
  // 监听用户点击推送通知的动作
  PushNotifications.addListener('pushNotificationActionPerformed', (res) => {
    // 自定义点击跳转逻辑
    console.log('推送被点击', res.notification);
  });
  

• 额外配置：iOS端需要在Xcode中开启「Push Notifications」和「Background Modes - Remote notifications」权限。

第二步：对接自有RabbitMQ消息代理 #

根据业务场景可以二选一：

方案1：RabbitMQ转FCM中转（推荐，稳定性最高）

后端新增中转服务，消费RabbitMQ队列中的目标用户消息，调用FCM服务端接口推送到对应设备的FCM Token，最终通过原生推送通道触达用户。

• 优势：依赖系统原生推送通道，不需要应用保活，哪怕应用被杀死也能正常收到通知，消息到达率最高。
• 适配要点：服务端维护用户ID和设备FCM Token的映射关系即可，无需修改移动端现有逻辑。

方案2：后台长连接直连RabbitMQ

如果需要应用活跃时的低延迟实时消息，可以接入@capacitor/background-runner插件，在原生后台进程中运行RabbitMQ AMQP长连接客户端。

• 注意：Android高版本对后台长连接的保活限制较多，需要申请忽略电池优化权限，应用被杀死后长连接会自动断开，仅适合非必达的实时消息场景。

常见排查点 #

• 移动端收不到推送优先检查原生工程的Firebase配置文件是否放置正确，权限是否开启
• iOS端开发环境和生产环境的推送证书不能混用
• 不要尝试在WebView层依赖Service Worker实现移动端推送，原生插件是唯一稳定的实现方案

内容的提问来源于stack exchange，提问作者MyNameIsLinuxx