php利用高阶函数消除递归，解决递归栈溢出问题

微信小程序推送服务通知需要收集足够的formid，使用过程中发现如果formid大量失效，在使用递归从redis从获取可用formid的时候会导致栈溢出问题，下面方法是使用php的高阶函数来消除递归，完美解决问题，记录之：

<php

class A

{

public static function factorial($n, $accumulator = 1) {

if ($n == 0) {

return $accumulator;

}

return function() use($n, $accumulator) {

return self::factorial($n - 1, $accumulator $n);

};

}

public static function trampoline($params) {

$result = call_user_func_array('self::factorial', $params);

while (is_callable($result)) {

$result = $result();

}

return $result;

}

public static function run()

{

var_dump(self::trampoline(array(500)));

}

}

A::run();

微信小程序的虚拟定位功能可以通过模拟GPS信号实现，具体步骤如下：

1 打开微信小程序，进入需要进行虚拟定位的页面。

2 在微信小程序页面中，点击屏幕右上角的“”按钮，打开小程序菜单。

3 在小程序菜单中，找到“开发者工具”选项，并点击进入开发者工具界面。

4 在开发者工具中，找到左侧菜单栏中的“调试”选项，并点击进入调试页面。

5 在调试页面中，找到右上角的“位置模拟”按钮，并点击打开位置模拟窗口。

6 在位置模拟窗口中，输入需要模拟的经度、纬度、高度等信息，并点击“添加位置”按钮。您可以添加多个模拟位置，以模拟移动轨迹。

7 在位置模拟窗口中，勾选“开启位置模拟”选项，然后点击“确定”按钮保存设置。

8 返回微信小程序页面，刷新页面即可看到虚拟定位的效果。

需要注意的是，在使用虚拟定位功能时，可能会影响小程序的正常使用，建议仅在开发和测试阶段使用。同时，虚拟定位功能需要在微信开发者工具中进行设置，实际上线时无法使用虚拟定位功能。

订阅消息分为 一次性订阅 和 长期订阅 ， 长期订阅 就不说啦，不是个人号可以染指的。

而 一次性订阅消息 本质和 模板消息 差不多，包括看了文档，接口基本上也比较相似。

一次性订阅消息 最大的优势就是不再受到 七天有效期 的限制，同时省去了生成 formId 的动作，而劣势在于必须用户主动允许，且允许一次只能发送一条信息。mo

这样的方式其实对用户是友好的，对于自己不想要的服务通知消息都可以屏蔽，而对于自己需要的消息可以允许发送，甚至可以选择 总是保持，不再询问 。

而对于小程序的开发和运营来说，就要考虑订阅消息的质量，是否能让用户心甘情愿的去 点击允许 ，并能 不再询问 。

拿 mini-blog 做试验，准备在提交评论的时候让用户选择是否可以接受评论消息提醒。

但有点可惜的是现有模板中没有最契合这种场景的消息模板，所以只能拿 留言通知 这个模板凑合用了「自己申请评论提醒的模板多数是被拒的」。

至于接入，还是比较简单的，文档比较详细的。

首先通过wxrequestSubscribeMessage这个API来唤起订阅消息界面。注意一定要用户发生点击行为或者发起支付回调后，才可以调起订阅消息界面。

用户 *** 作后回调结果会告诉你该模版用户是否同意订阅「值包括 accept 、 reject 、 ban 。 accept 表示用户同意订阅该条id对应的模板消息， reject 表示用户拒绝订阅该条id对应的模板消息， ban 表示已被后台封禁」

所以当用户 accept 之后，你就发送该模板的订阅消息了，用户会收到。

发送订阅消息可以通过云调用的方式「但现在看文档貌似找不到了，不懂什么情况」

不出意外，服务通知里就能收到消息了。

订阅消息大致流程其实和模版消息差不多，但坑还是挺多的，这里总结下，避免大家接入的时候踩坑。

小程序本身的服务类目决定你只能选择该服务类目下的订阅消息模板。公共模板库只出现绑定的类目下的模板。

订阅消息只能通过真机调试，开发者工具不支持。

即时用户选择了 不再询问 ,wxrequestSubscribeMessage后台还是会默认调用，只是没有d框,也不会生成 formID ，这样对于我们来说不知道用户点了几次，相对的，我们也不知道可以给用户发送多少条成功的订阅消息「所以，以前是记录formID，现在依旧要记录用户点击次数，本质没差」

这也是比较坑，原本我的评论提交按钮是通过表单提交，但无法唤起订阅消息的d框，逛了社区才知道不支持，只能改为 bindtap事件 。

这个也好奇葩，在测试 留言通知 这个消息模板的时候，发现偶尔会提示 dataname1value invalid 的错误，一直匪夷所思，明明都已经赋值，且日志打出来也有的，怎么会报这个错误呢，后来发现我的昵称是 Bug生活2048 ,当我把 2048 去掉之后就成功发送了。

后来仔细看了文档才发现，订阅消息参数值的内容有严格限制，其中姓名 dataname 是不能包含数字的。

订阅消息使用场景还是很多的，后面可以利用它慢慢丰富我的小程序。

文档一定要仔细看，不然小坑不断，很浪费时间。

一、推送的重要性

推送是消息触达与用户召回的重要通道，推送通道能力的触达率、推送消息的点击率绝决定了推送的覆盖度，我们用一个公式来衡量推送效果： 推送效果=推送目标数推送触达率推送点击率用户转化率 1 推送目标数： 即将要推送的人数。那是不是推送目标量越多越好呢？——否！如果推送到非目标人群，会打扰到正常用户，甚至可能卸载APP或投诉模板消息，后果就比较惨了。所以建议还是选择合适的目标群，在优化部分会给出简单的小建议~ 2 推送触达率： 推送触达率主要是衡量消息通道的健壮能力的指标，一般来说，APP推送可尝试使用效果较好的三方渠道；微信内推送应建立适当的推送时间避免Formid过期。据了解，APP的推送触达率在75%左右， 微信 的触达率在90%左右。 3 推送点击率： 这个和推送人群、推送时间、推送素材紧密相关，后面做详细说明。 4 用户转化率： 这就是运营的能力，根据业务自行判断，不做赘述。

二、微信体系的消息推送

1 微信推送消息的介绍（详见微信官方文档）

基于微信的通知渠道，公众号/小程序提供了高效出大用户的模板消息能力，以便实现服务的闭环并提供更佳的体验。

模板推送位置：服务通知

模板下发条件：用户本人在微信体系内与页面有交互行为后触发

模板跳转能力：详情仅能跳转下发模板的该帐号的各个页面

模板推送流程：

有心的小伙伴可以看到，相较于APP推送，微信推送需要选择合适的模板ID。为了方便推送内容的规整与管理，微信体系下的推送（微信公众号推送、模板消息推送）必须要选择相关的模板标题，在模板下更替内容即可，具体模板内容可参考模板消息管理。

2 模板消息的规则与限制

介于模板消息建立在微信生态内，当然为了用户体验及生态健康，微信也是设置了较多的规则与限制： 21 下发规则 211 推送位置：服务通知。

212 推送下发能力：用户本人在微信体系内与页面有交互行为后触发，当然也是有时间的限制。微信公众号的服务通知限定在交互72小时内可以主动下发消息，小程序模板消息限定在交互7天内可以下发模板消息（小程序下发模板消息需要收集Formid，Formid的有效期是7天）。 22 限制与惩罚 221 贴一下官方给出的违规说明（请认真对待，不要以为是吓唬你或是开玩笑。身为腾讯干儿子的我们真的被严格的封过！是！真！的！）：

222 一般官方给出的惩罚原因比较模糊，我结合具体被封过的例子简单解释一下以及我踩坑过来的一些小tips：

1）

官方解释：不允许恶意诱导用户进行触发 *** 作，以达到可向用户下发模板目的

话外解读：不能以利益刺激引导用户点击、不能引导用户做和订单/消息无关的行为反面案例，比如点击领钱、砍价等等

Tips：

利益点表述的委婉些：比如“点击可领1元”可改为“你有一份惊喜待查看”。

常规行为让用户选择是否需要提醒：比如签到提醒给用户设置开关，让用户选择是否需要提醒。

2）

官方解释：不允许恶意骚扰，下发对用户造成骚扰的模板

话外解读：把消息下发给了无关的人群、你的模板消息被用户举报了，比如给女性用户下发了无人机/游戏手柄等相关的内容。

Tips：认真做好用户分层，并且控制好推送频率。

3）

官方解释：不允许恶意营销，下发营销目的模板

话外解读：你把模板消息当做营销工具使用了，并且被用户举报了，比如有事儿没事儿搞个促销轰炸一通。

Tips：不要用模板消息推营销活动，早点囤些流量到公众号里推吧。

除了这些，没事儿常拜一拜小龙爸爸，祈祷不要被封。

3 推送后台的设计

在公司里我们作为基础部门，承接着各个业务方提过来的推送需求，以我们为例，推送后台应承载的功能主要有以下几块：

31 推送能力支持主要涉及到模板维护、推送申请与流量分发、A/B测能力支持、数据查询等基础功能。 32 防打扰策略 根据产品不同防打扰策略的设计会有差异，以电商平台为例，可以分为以下三类推送：

基础类：与核心业务直接相关的消息提醒，没有就会对业务产生影响或用户体验大打折扣，比如：订单消息提醒、买卖双方消息提醒等；

提醒类：不会影响正常的产品流程，有可能提升产品活跃或促进复购的消息提醒，比如：订单过程中的漏斗节点提醒、签到提醒、基于业务场景的提醒（降价通知、到货通知等）；

营销活动类：主要是运营使用，为用户创造需求的一类提醒，比如：大促活动提醒。

基于以上三种类型，对于用户的防打扰可以设计为底层防打扰、业务防打扰两个层面。底层防打扰用户保证消息通道“不轰炸”且有“存在感”，业务防打扰保证“推对人”“不泛滥”。

防打扰条件可以从防打扰时间、防打扰频次、防打扰场景等多个维度拆分，根据业务不同自行设计，不详细展开。 33 资源竞争&智能匹配 简单来说，这个课题要解决的问题是：A、B、C多个业务方都想给小明们推送，那么A、B、C三个业务推送的用户群的重合度有多少？到底应该由哪个业务方推给小明们呢？

我的解法主要是用户分层体系（主要是RFM模型）的应用，写起来也是比较多，感兴趣的话记得点赞留言，我得空了单独整理一篇。

三、消息推送的优化

这里讲的消息主要针对于 微信 模板消息推送，底层逻辑和APP推送是一致的，只是一些表现或者样式有些微调，我简单整理了一张表格对比一下，各位看官自行分辨取精去粕。

按照消息推送的过程，可以分为推送前的准备、推送中的监控、推送后的复盘三个过程，按照三个过程分别提供一些优化建议。

1 推送前准备

1）选择推送人群

这点非常考察产品运营同学的数据敏感度，以及公司底层的数据系统的搭建。中大型的公司会有严密的用户分层及用户行为监控，方便运营。比如推送双十一营销消息会根据用户去年参与情况、消费金额、近一年/近半年消费频次、最近一次消费的时间等因素划分不同的用户群，每个用户群组织不同的素材（可参RFM模型及用户运营策略）。

但是，数据不完整的小公司怎么推送呢？

简单来说，可以通过用户系统版本、用户性别、用户年龄、活跃行为、消费行为等做简单的推送即可。

2）选择推送时间 一般情况下，常规推送最好能够固定时间或行为后立即触发，营销类推送可选择通勤时间段、饭点儿或休息时间进行推送，以下几个时间段仅供参考：7:30~9:30、12:00~14:00、18:00~22:00。

3）设定推送文案 推送文案直接影响着点击率，这也是运营同学长久积累的功底，我就不班门弄斧了。说几个我写过的点击率还比较高的方向吧：热点事件、红包奖励、朋友介绍等等，欢迎补充。

4）制作landingpage

千万不要忽视落地页，不可一概而论，即使做不到千人千面，也要根据用户分群做一些区分。比如，对价格敏感的用户就一定要放优惠券；女生用户就要尽量打“占便宜”“少女感”这些点。

2 推送中监控

推送的过程中要实时监控两个点：推出的数据是否正常、 微信 后台是否有投诉消息，一旦发现有情况，立刻马上停掉后面的推送！

3 推送后的复盘

1）数据复盘 我会按照漏斗去看目标推送量、推送成功量、点击量、转化量、转化用户的留存这些数据。 2）防止被举报的小技巧 在与小伙伴交流时发现被封真的是一个很正常的现象，还是有一些“小技巧”是可以尝试的：可以在推送内容增加一条“回复DT不再推送”或者在文末增加“伪投诉”入口。

不是的。

这个可能是社交红包类的小程序+小程序通知。要满足这个功能，需要保证收到小程序通知的用户先进入过小程序并通过点击获取了formId才能下发成功。小程序给用户发红包的两种方式：

第一种调用小程序红包接口和领取红包接口这种场景为扫码打开小程序，适合线下推广。

第二种调用关联微信支付的微信付款到零钱接口，现金可直接打到微信用户的零钱帐户。

许多做产品的同学经常会有这样的疑问：计划开发的移动端产品到底是用 H5 好还是用小程序好？甚至很多开发同学也搞不清楚这两者在具体使用中的优劣。那么相信读完此篇，便可让你对二者之优劣利弊了然于胸，再也不必纠结。

大体上讲，H5和小程序并不具备什么可比性。只是很多移动端的场景下，这两种选择都能实现产品的大部分功能，加之其各领风骚好几年，就更难抉择了。

我们经常说的 H5 是一种不标准的叫法，可以理解为只是一种技术，大家说得最多的 H5 主要是指用在移动端的网页，其实 PC 电脑版也一样可以使用 H5 技术。而小程序，这里特指微信小程序，是在微信 APP 基础上支持的一种应用形式，完全依赖于微信 APP 环境。

以上，是大概念上的区分，下面，我们就来详细对比一下其他方面。

一、运行环境

这里的 H5 既然是网页，那么依赖的外壳主要是浏览器，因此只要有浏览器，就可以使用。比如手机内置的浏览器，APP 的 web-view 组件，以及小程序提供的 web-view 组件，都可以打开 H5 页面。

注意，小程序的 web-view 可以打开 H5，但并不是小程序“跳转”到了 H5 页面，这个 H5 还是小程序的外壳内，仍然有很多限制。

前面说了，小程序只能依赖微信客户端，也就是说只能在微信里打开。那么，如果你的产品需要通过短信通知用户带上访问地址，就无法用小程序实现了。而 H5 页面，则可以在短信正文中直接用手机内置浏览器打开。

但是，微信本身是跨平台的，因此无论是安卓上的微信，苹果上的微信，都是可以使用小程序的。甚至 QQ 浏览器也支持了部分小程序的入驻。

二、系统权限

这里的系统权限，可以理解为隐私级别比较高的，如通讯录，或能调用硬件的，比如蓝牙功能等。从这个角度看，H5 本身可以说几乎是没有什么系统权限的。虽然也有摄像头之类的接口，但是重度依赖浏览器能力，兼容性有限。

而小程序，由于依赖微信客户端本身，所以微信小程序团队将客户端的很多能力开放给了小程序环境，当然，前提是你给微信也授权了相关的能力，比如允许访问麦克风，允许访问相册等。

所以，如果你的产品重度依赖这些能力，那小程序一定是不二之选，因为 H5 很难做到这些，对于很多小程序提供的能力，H5 是根本没有可能实现的。

三、能力限制

前面提到了系统权限层面的差异，其实也是一种能力限制。除此之外，还有一些能力是微信本身的策略限制的，比如 H5 在微信里可以直接分享朋友圈，而小程序目前就只能转发好友或群。对于朋友圈，就只能生成带小程序码的发到朋友圈。

而对于分享到好友或群，小程序又提供了卡片式的分享界面，看起来很高端，信息也多，并且能追踪用户行为。这一点，H5 又无法做到。

再比如支付能力，小程序只支持微信支付，而 H5 里可以选择使用其他支付平台提供的支付方式。

四、用户体验

分享卡片看上去比普通的 H5 链接分享体验要好；而朋友圈的 H5 分享形式，和识别小程序码的形式到底哪个好也不好说。不过，如果你的产品被判定有违规行为，那么 H5 的链接是很容易匹配屏蔽的，可以直接导致分享 H5 页面只能自己可见，别人看不到。

但是，小程序的分享图虽然不太可能封禁，但小程序是微信的呀，那还不是分分钟就关掉。 所以在抗风险方面，二者各有千秋。如果是 H5，那就多准备几个域名；如果是小程序，就直接多上线几个小程序，保证封禁时损失降到最低。

除了形式上的体验差异，性能上也是有差异的。小程序基于微信客户端实现，对解析进行了优化，并且一旦首次打开小程序，可以直接缓存很多资源。因此，在使用小程序时可以明显感觉很流畅，接近原生 APP 的体验。

而 H5 本质上还是网页，跟之前在 PC 上浏览网页没区别，每次要请求各种样式资源，在浏览器内核里渲染，因此体验会差一些。

五、访问入口

在访问入口这个点上，H5 的核心竞争力就是能在微信之外玩，不依赖微信本身。而小程序的优势，就是有 50+ 微信提供的场景入口，并且聊天界面顶部的“最近使用”和“我的小程序”这个入口，相对 H5 来说是有绝对优势的。

用户关闭之后，H5 页面如果想继续访问，可能会通过收藏入口，或者转发给“文件传输助手”等聊天界面保存，还可以缩小到图标稍后阅读等等。本质上还是跟 PC 时代的浏览器收藏夹差不多，需要有个地方把 H5 的链接地址保存下来，方便下次访问。如果没有保存，下次就很难找到了。

至于微信内的搜索，是可以同时搜索 H5 和小程序的，可以根据 H5 的名字和内容、小程序的名字和介绍来搜索。这里 H5 有个天然优势就是，只要你的链接在各大搜索引擎提交过，那么使用其他的搜索引擎也能搜出这个 H5，比如百度搜索。

六、用户触达

H5 本身是没有用户触达能力的，如果用户关掉了页面，页面就再也没有办法主动触达该用户了。因此，传统的营销方式都是采用邮件营销或短信营销等来触达用户。

后来，我们有了微信服务号，就多了服务号模板消息的触达方式。不管是哪种方式，都是想方设法把链接地址推送给用户，用户点击时再通过手机内置浏览器或微信内置浏览器访问页面。

而小程序天然支持模板消息，虽然有一周的推送时间限制，但是常规的业务已经足够了。只要用户使用你的小程序，你就可以通过某种 *** 作收集 formid，然后即可在一周之内的任意时间触达用户。

七、开发成本

对于简单功能，H5 和小程序的开发成本是差不多的，开发模式和语言风格也类似。而对于前面说到的系统能力，可能就只有小程序才能实现，H5 根本做不了。此外，小程序自成体系，因此也有一些现成的组件可以使用，如果刚好覆盖了你的产品功能就能提升效率。

虽然 H5 也有很多框架组件可以用，但由于过于庞杂，有选择成本，且技术栈和 UI 五花八门，可能还有融合和修改的成本。而小程序组件的 UI 大部分已经确定，只有很少的部分可以修改，所以一旦认定使用小程序，这部分成本会低很多。

总体上来讲，我觉得还是可以认为小程序的开发成本更低一些。

八、迭代周期

开发成本低，未必迭代周期就短。对于 H5 我们可以随时发布上线，不用受任何牵制。而小程序的特点，就是每次提交版本都要经过微信方面的审核，且审核时间的长短很随机，着急上线的项目就很无奈了。

至于其他速度，取决于开发人员技能熟练程度，系统复杂度，对基础能力的依赖等，就不好估算了。

九、外部限制

由于小程序依赖微信平台，因此微信平台要对内容安全等事项负责，比如你想搞个有 UGC 的产品，用 H5 可能还可以趁着监管宽松无证裸奔一阵，或者说做大了再补证。

而小程序，就很可能完全不能过审，根本上不了线。比如试听类，社交类，都有对应的资质，而这个资质还可能很难获得。

类似的，H5 页面可以不用搞 >

以上就是关于php利用高阶函数消除递归，解决递归栈溢出问题全部的内容，包括:php利用高阶函数消除递归，解决递归栈溢出问题、微信小程序虚拟定位怎么做的、[mini-blog]订阅消息的踩坑记录等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！