锁屏通知无法真正“一直固定不被清除”——这是android/ios系统级限制，uni-app无api可绕过；android可通过priority:2+ongoing:true+前台服务逼近常驻，ios则完全禁止且无法恢复已清除通知。
锁屏通知栏无法“一直固定不被清除”——这是操作系统级限制，uni-app 本身没有 API 能绕过 Android/iOS 的通知生命周期管理。所谓“固定”，只能通过高优先级 + 前台服务 + 持久化通知样式来逼近效果，但系统仍可能在内存压力、省电策略或用户手动清除时移除它。
Android 端如何让锁屏通知保持常驻（非自动清除）
Android 不允许普通应用的通知永久驻留，但可通过以下组合提升存活率：
- 使用
uni.showNotification发送通知时，必须设置priority: 2（最高优先级）和ongoing: true（持续性通知），否则系统会视作普通通知并允许用户滑动清除 - 需搭配前台服务（
plus.android.foregroundService）启动一个带 Notification 的 Service，仅靠uni.showNotification无法维持长期可见性 - 在
AndroidManifest.xml中声明权限：<uses-permission android:name="android.permission.FOREGROUND_SERVICE"></uses-permission>，并添加android:foregroundServiceType="specialUse"（Android 12+ 必须） - 避免使用
setTimeout或 JS 层轮询重发通知——后台 JS 会被挂起；所有保活逻辑必须下沉到原生层或通过 uni-app 的nativePlugin实现
iOS 端锁屏通知无法真正“固定”的根本原因
iOS 完全禁止应用自行保持通知常驻。即使调用 UNUserNotificationCenter.current().add(…) 注册通知，也只影响是否允许推送，不控制锁屏界面的展示时长或是否可清除：
- 用户手动左滑清除后，该通知即销毁，无法恢复
- 系统会在一定时间（通常数小时）后自动清理未交互的通知，且无 API 可延长
-
interruptionLevel: .timeSensitive（iOS 15+）仅提升横幅优先级，不影响锁屏列表是否保留 - uni-app 无法调用
UNNotificationRequest的threadIdentifier分组聚合，故多条通知会各自独立、各自可删
微信小程序端根本没有锁屏通知栏概念
小程序运行在微信宿主内，不拥有独立进程，也不具备发送系统级锁屏通知的能力：
-
uni.showNotification在小程序平台不可用，会直接报错showNotification is not a function - 能触发的只有
wx.getWeRunData类接口返回的“服务通知”，但该通知由微信统一管理，开发者无法控制其锁屏行为、展示时长或是否可清除 - 所谓“全局提醒”，只能退而求其次做页面内顶部横幅（如用 Pinia 管理队列 + 自定义组件），它跟锁屏无关，只在小程序前台活跃时可见
容易被忽略的关键点
很多开发者试图用“不断重发通知”模拟固定效果，结果被系统标记为骚扰行为，导致整机通知权限被降级甚至禁用。真正可控的边界是：Android 可设 ongoing: true 防止误滑清除，但无法阻止用户长按通知 → “关闭此应用通知”；iOS 连这个都做不到。任何宣称“uni-app 一行代码实现锁屏通知永驻”的方案，本质都是对系统机制的误读。
