企业官网建设流程全解析

HarmonyOS 7 代理提醒最多 64 条：提醒响过了，为什么新增仍提示额度不足？

给习惯打卡或课程提醒做“每天一次”的代理提醒时，开发者很容易把“今天已经响过”理解成“这条任务已经结束”。页面显示还有空位，下一次publishReminder却失败。这里先别急着把旧提醒全部清掉：响过、用户点了关闭、提醒失效，是三件不同的事。

华为 2026-09-09 更新的代理提醒指南写明：API 26.0.0 及以上，单个普通应用最多保留 64 条有效/未过期提醒；API 25 及以下是 30 条。但“64”不是所有设备和所有应用都可无条件使用。手机、平板、PC/2in1 的代理提醒能力受管控，应用类别、使用场景、开放能力、权限与通知授权必须先满足要求。营销预约、抢券之类的场景不在申请支持范围内。

先查有效数，不要用业务列表行数猜

getValidReminders()返回的是当前应用仍有效的代理提醒。业务数据库里“今天已执行”的状态，并不能代替系统里的有效数。

import { reminderAgentManager } from '@kit.BackgroundTasksKit'; async function inspectCapacity(): Promise<number> { const valid: Array<reminderAgentManager.ReminderRequest> = await reminderAgentManager.getValidReminders(); console.info(`当前有效提醒数: ${valid.length}`); return valid.length; }

诊断时先把页面计数和这里的返回值并排记录。如果业务页面显示 59 条，系统返回 64 条，应查已删除的业务记录是否还留着系统提醒，而不是先扩大前端列表上限。

案例一：单次提醒响了，但用户没有点关闭

准备一条非周期的日历提醒，约定在一分钟后触发。通知到达后不要点击关闭/CLOSE，再调用getValidReminders()。按官方说明，此时它仍属于有效/未过期提醒。若先前已有 63 条有效提醒，加上这条恰好是 64 条；此时继续新增，可能因为额度已满而失败。

再点击该通知上的关闭按钮，重新读取有效列表。只有系统确实把这条移出有效集合后，才能把它当作已释放额度。不要用“通知出现过”或“用户看过页面”替代这一步。

案例二：每天重复的提醒响过了，仍一直占一个名额

创建一个每天固定时间的周期提醒，等待它第一次弹出并关闭通知，然后再读有效列表。官方明确说明：周期性提醒不因一次触发或关闭而失效。这正是“每天都响过，为什么有效数不降”的常见原因。

当用户明确关闭“每天提醒”功能时，应用应使用创建时保存的提醒 ID，取消那一条，而不是调用cancelAllReminders()清空当前应用全部提醒。取消后再读回系统列表，检查有效数是否变化。

import { reminderAgentManager } from '@kit.BackgroundTasksKit'; async function addReminder( request: reminderAgentManager.ReminderRequest ): Promise<number> { // 先完成开放能力、PUBLISH_AGENT_REMINDER 与通知授权检查。 const before = await reminderAgentManager.getValidReminders(); if (before.length >= 64) { throw new Error('有效代理提醒已达 64 条；请先让用户选择要停用的提醒'); } // 这里的预检不能替代平台最终结果；并发发布仍可能抢同一空位。 return await reminderAgentManager.publishReminder(request); } async function stopReminder(reminderId: number): Promise<number> { await reminderAgentManager.cancelReminder(reminderId); const after = await reminderAgentManager.getValidReminders(); return after.length; }

调用addReminder前，应由具备权限的应用构造真实的ReminderRequest，并为新增操作做防重复点击和本地串行化。即便前置查询显示 63 条，另一个请求也可能先占用最后一个名额，所以必须处理publishReminder的失败结果；不能把预检写成“保证发布成功”。publishReminder返回的数字 ID 要与业务任务建立映射，之后才能准确取消。

为什么不直接把旧提醒批量删掉

批量删除看似能立刻腾位置，但可能把用户仍需要的闹钟、课程或打卡提醒一并移除。更稳妥的顺序是：

1. 查看getValidReminders()的数量，确认是否真的触及本应用有效数上限。
2. 若未满额，优先排查开放能力、ohos.permission.PUBLISH_AGENT_REMINDER、通知授权和设备管控，不把所有失败都归因于“64 条”。
3. 若已满额，让用户选择不再需要的周期任务，凭保存的 ID 调用cancelReminder(id)，读回数量后再新增。
4. 记录发布失败原因和对应业务任务，不要只展示“添加失败”。

还要注意：API 26 的单应用 64 条和系统整体有效提醒总数是两层限制。官方还列出 API 10 起所有应用总计不超过 12000 条，不能把单应用空位理解成系统一定有空位。

复现与版本边界

可以在已经获批代理提醒能力、配置权限并取得通知授权的 API 26 工程里，先创建两类提醒：一条非周期日历提醒、一条每天重复的提醒。依次记录创建前、弹出后、关闭通知后、调用cancelReminder(id)后的getValidReminders().length。还应在 63/64 条边界测试两次快速点击，验证应用是否阻止重复提交并正确显示平台错误。

本文的额度、周期有效性、管控和接口依据华为 2026-09-09 更新的官方文档。以上是可执行的检查流程和接口调用片段；当前环境未完成获批应用的 API 26 SDK 编译与真机提醒实验，因此不把示例观察表述成实测结果。申请资质和设备管控不满足时，不能仅靠复制代码复现成功提醒。

官方依据：代理提醒（ArkTS）。