【微信小程序】订阅消息的一次性订阅 vs 长期订阅?其实一次性订阅也能实现长期发布订阅消息


前言

为何要订阅消息 & 订阅的好处

相信你也曾被微信的服务通知所骚扰过(bushi)…

没错,微信的订阅消息会发送到用户的服务通知处;

服务通知不同于公众号/服务号等通知;

“服务通知”:属于强提醒,会以大红点的形式出现,而且还会在手机/电脑提醒消息

“公众号/服务号”:属于弱提醒,只会以小红点的形式出现,不会在手机/电脑中提醒。

如图(对比):

在这里插入图片描述

因此,订阅消息的好处就不言而喻了,最显然的就是:提高用户的转化率


一、一次性订阅 & 长期订阅

一次性订阅:用户订阅后,在任意时间发一次消息给用户,不能发第二次。

长期订阅:用户订阅后,可长期发送多条信息。(但是这个要求行业和资质高,只有特定的几个类目才能选)

那么如何实现一次性订阅也能长期发送多条消息呢?

如图:

当你调用wx.requestSubscribeMessage接口时(最多可传入3个模板id),就会触发授权弹窗。

注意!细节来了!

弹窗授权为发送一次以下消息(即一次性订阅);
而下方的总是保持以上选择是默认的选择项(字体这么小而且还是灰色的,是不是不容易发现0.0);

简单来讲:授权发送一次以下消息 + 总是保持以上选择 = 只要你授权一次,我就可以无限次发订阅消息

但是需要用户手动开启授权模板,如下图留言通知/榜单更新通知/新活动通知的授权按钮默认是关闭的

虽然说是这么说,但是可以通过诱导(引导)用户来开启,如:不开启可能会导致功能无法使用…
(懂的都懂)

在这里插入图片描述

二、操作步骤

接下来是简单的代码实现,具体的可以自己添加更多的业务逻辑

1. 创建模板

进入微信小程序后台—“基础功能”—“订阅消息”,进入"公共模板库"挑选合适的模板后,得到模板ID。

在这里插入图片描述

2. 前端授权订阅消息

微信官方文档:小程序订阅消息(用户通过弹窗订阅)开发指南

使用 uni.requestSubscribeMessage 发起授权,传参为模板ID,若有多个则需要传数组。
(最多授权3个模板ID)

注:开发时使用了uni-app框架,微信官方的API为 wx.requestSubscribeMessage,效果是一致的。

代码如下(示例):

Tip:可以在关键业务按钮埋下授权订阅消息代码让用户授权,但也要注意用户体验。

// 创建问题
const createQuestion = async () => {
   
  // 检查模板消息订阅权限
  try {
   
    const subscribeResult = await uni.requestSubscribeMessage({
   
      tmplIds: [
        '模板ID-1xxxxxx',
        '模板ID-2xxxxxx',
      ],
    })
    if (subscribeResult.errMsg === 'requestSubscribeMessage:ok') {
   
      // 用户同意了订阅或已经订阅过,继续创建问题
      await handleCreateQuestion()
    } else {
   
      // 用户拒绝了订阅,显示提示后继续创建
      uni.showModal({
   
        title: '订阅提醒',
        content: '为了及时接收回复通知,建议您开启订阅消息',
        confirmText: '确定',
        success: async (res) => {
   
          if (res.confirm) {
   
            // 用户点击确定,继续创建问题
            await handl
这个错误信息表明,在尝试向数据库插入数据时,提供的日期值 `'12830-08-01 00:00:00'` 超出了 MySQL 中 `DATETIME` 或 `TIMESTAMP` 类型的有效范围。 ### 原因分析 1. **MySQL 的有效日期范围** - 对于 `DATE`, `DATETIME`, `TIMESTAMP` 数据类型,有效的日期范围通常是: ``` 1000-01-01 到 9999-12-31 (对于 DATE/DATETIME) 1970-01-01 到 2038-01-19 (对于 TIMESTAMP) ``` 提供的日期 `'12830-08-01'` 远远超出了上述范围,因此无法存储到列 `end_date` 中。 2. **输入验证不足** 如果未对用户输入或程序生成的数据进行严格的校验,则可能导致这种无效日期进入数据库操作流程。 --- ### 解决方案 #### 方法一:修正数据源中的非法日期值 检查并修改导致该问题的具体记录。例如,如果你发现某个字段被误设为未来的极端年份(如12830),可以将其调整为合理的数值(比如当前时间或其他合法值)。示例 SQL 修改命令如下: ```sql UPDATE your_table_name SET end_date = '9999-12-31' WHERE id = problematic_id; ``` #### 方法二:在应用层添加数据验证逻辑 确保所有传递给数据库的操作都经过合法性检查,避免类似超出范围的情况发生。可以在代码中加入条件判断: ```python import datetime def validate_date(date_str): try: # 尝试解析字符串为标准格式,并限制最大日期不超过指定范围 dt_obj = datetime.datetime.strptime(date_str, '%Y-%m-%d %H:%M:%S') max_allowed_date = datetime.datetime(9999, 12, 31) # 最大允许日期设置 if dt_obj > max_allowed_date or dt_obj < datetime.datetime(1900, 1, 1): # 可选最小日期设置 raise ValueError("Date out of valid range") except Exception as e: print(f"Invalid date {date_str}: {e}") return False return True # 测试函数 test_dates = ["12830-08-01 00:00:00", "2024-05-20 12:30:00"] for d in test_dates: is_valid = validate_date(d) print(f"{d} -> {'Valid' if is_valid else 'Not Valid'}") ``` #### 方法三:更改表结构以适应更大范围的需求 如果业务场景确实需要处理非常遥远未来的时间点,考虑使用更大的容器替代默认的数据类型——将现有 DATETIME 改成 BIGINT 来直接保存 Unix 时间戳形式表示的大整数即可支持任意大小数字代表无限延伸时刻。 不过需注意这会牺牲掉一部分查询便利性标准化规范优势! --- ### 总结建议 优先从源头解决问题,即保证正确的原始数据质量;其次增强系统健壮性的措施也很关键,包括但不限于前端界面提示、后端API接口约束以及SQL脚本层面的安全防护机制等多方面努力共同防范此类异常的发生概率降至最低限度之内。
评论 12
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值