专业小程序设计开发——助力新电商新零售

电话+V：159999-78052，欢迎咨询微信小程序下单提示重新下单什么意思啊呢，[小程序设计与开发]，[小程序投流与推广]，[小程序后台搭建]，[小程序整套源码打包]，[为个体及小微企业助力]，[电商新零售模式]，[小程序运营推广及维护]

一、微信小程序下单成功能够提示到公众号吗?

微信小程序的订单完成之后，公众号可以通过配置好的模板消息，向相关用户推送消息提醒。这需要先在微信公众平台设置好消息模板，并获取模板ID。当用户在小程序中下单并成功后，开发者可以通过调用微信提供的API接口，发送模板消息给用户，用户便能在微信中接收到相应的订单完成提醒。

实现该功能需要以下步骤：

1.申请模板消息权限：在微信公众平台中，进入小程序后台，申请订阅消息模板，填写模板标题和内容，提交审核，通过后获取模板ID。

2.授权用户接收消息：在小程序中，通过调用`wx.requestSubscribeMessage`API获取用户的订阅授权。

3.发送模板消息：使用获取到的模板ID和用户的openid，通过微信API接口发送订阅消息。

二、小程序订单是什么意思?

1.什么是小程序订单

小程序订单是指用户在微信小程序中下单并支付的行为，商家将根据订单里指定的商品或服务向用户提供商品或服务。

2.如何查看小程序订单

在微信小程序中，用户可以通过以下两种方式查看订单：

在小程序的首页或“我的”页面中找到“订单”或“我的订单”，点击进入订单列表页面，即可查看所有已经下的订单。

如果商家有开通消息提醒功能，用户可以在微信中收到订单付款成功的通知消息，点击进入消息中的订单号即可查看订单详情。

3.如何管理小程序订单

商家可以通过以下方式管理小程序中的订单：

在小程序后台管理系统中查看订单列表，包括待处理订单、已发货订单、已完成订单等，可以根据需求对订单进行处理。

商家可以在小程序中开启订单提醒，当有新订单生成时会收到推送消息，方便及时处理订单。

商家还可以对订单进行修改、取消、发货、退款等操作。

4.小程序订单注意事项

下单时需要填写正确的收货地址、联系人和电话等信息，以免影响发货和收货。

支付完成后，系统会自动将订单状态变为“支付成功”或“待发货”状态，商家需要及时查看订单并处理订单。

5.小程序订单的优化建议

为提高用户体验和订单转化率，商家可以采取以下措施进行优化：

页面设计简洁明了，方便用户查看和下单。

提供在线客服和售后服务，方便用户咨询和解决问题。

页面加载速度快，避免等待时间过长影响用户体验。

合理设定优惠活动、满减等营销策略，吸引用户下单。

6.总结

每日必抢小程序下单总结

在数字化时代背景下，电商平台不断拓展其触达用户的边界，而“每日必抢小程序”正是这一趋势下的产物。本文深度剖析了这款小程序如何在支付宝、夸克等非淘宝App端为用户提供近似淘宝App的购物体验，通过整合营销、搜索、交易等核心电商能力，实现在多平台的无缝衔接。

背景

每日必抢小程序是指在非淘宝App端上面向消费者提供电商服务的小程序，具备的营销、搜索、交易、履约、客服等核心电商能力，基于淘宝App提供的能力底座，让消费者可以在非淘宝App端享受到接近淘宝App的线上购物体验。

在支付宝上做的小程序叫每日必抢，在夸克上叫省钱集市。

?下单

小程序下单的产品能力是依托淘宝的交易底座，搭建了一条小程序的链路。

?产品架构

产品能力上主体跟淘宝一致，同时延伸了一些特色业务场景，比如会员购，花呗购和商家积分购(下图橙色框)，这些新的业务场景也给我们带来了一些挑战。

演进历史

?1.0:DX方案

DX全称DinamicX，它用XML的语法来描述视图UI，广泛用于手淘App客户端，比如首页，下单和购物车等场景，解决在不发版的情况下动态下发UI布局，以及部分逻辑能力来支持业务的快速更新迭代，提升工作效率。

由于历史原因，小程序1.0使用DX来写的，然后将DX构建成JSON形式组件树，小程序从DX平台拉取组件树后映射到小程序组件后进行渲染，渲染过程包括：处理DX样式属性，数据属性和绑定事件等，具体流程见下图：

可以看到渲染阶段会有一个拉取DX组件树模版的过程，会影响首次渲染的速度，需要内置模版来解决。而且这是一套运行时的方案，需要在小程序侧动态解析组件树并递归渲染，同时由于样式和数据都是动态设置的，运行性能上会有一些影响。

每一个DX原子组件都需要有一个小程序组件对应，同时每一个DX组件的属性都需要有对应的小程序实现。举个例子，DX上有一个InputView的DX组件，然后它支持一些样式属性，数据属性以及事件属性，我们需要写一个对应的小程序InputView组件来实现：

1.每一个样式属性都需要写一个映射函数转化为css的属性（this.setStyles）

2.每一个数据属性都需要手动设置（this.setData）到data里使用，

DX的InputView组件：

<InputView<!--样式属性-->height="46np"width="match_parent"<!--数据属性-->text="测试"placeholder="这是一个文本"<!--事件属性-->onAppear="@appearExpose{@data{subSection.home.subSection.searchBox}}"//事件/>

小程序InputView的实现：

Component({methods:{triggerChange(e){this.dinamicXEventHandler({type:'onChange'，value:deepGet(e，'detail.value')});}，onChange(propValue){this.events.onChange=propValue;}，text(propValue){this.setData({value:propValue});}，placeholder(propValue){this.setData({placeholder:propValue});}，textColor(propValue){this.setStyles({color:Dinamic.colorParser(propValue)});}}})

一个简单的InputView都需要这么多胶水代码，更别说有更复杂属性的自定义组件了。

DX诞生于客户端技术，由于客户端的发版频率受限，DX可以很好满足了“动态化”的诉求，这也是之前选择DX的最主要原因。不过在小程序侧，发版相对比较自由，DX的优势就不存在了，反而带来了编码成本和性能损耗的问题，于是我们在考虑放弃DX的方案。

?2.0:Rax方案

后端需要做应用迁移，我们也准备一起升级前端的架构，选择Rax主要原因是它拥有跨小程序端的特性，满足跨端诉求（上面提到的支付宝和夸克），同时语法层面相比DX是前端更加熟悉的，所以选择了这套方案。

方案对比

DX小程序

Rax小程序

是否支持跨小程序端

否

是

DSL

DX前端相对不熟悉

类似React，前端比较熟悉

是否在同一个IDE开发

否

是（可以在小程序IDE内完成）

方案类型

视图层方案（视图渲染动态解析渲染组件，渲染的组件还是原生小程序组件）

应用层方案（整个项目是一个类React的项目，打包构建成小程序项目）

编译时还是运行时

运行时

运行时（编译时会有很多限制，官方推荐运行时）

Rax体验还是比较好的，没有DX版本的动态模版加载过程，页面可以做到直出。当时我们也是跑了一段时间，不过随着业务个性化需求的逐渐增多，发现支付宝上一些新的小程序特性无法支持，因为Rax目前处于维护状态，不新增新功能。

同时我们发现Rax这套方案会有构建体积过大的问题，包体积可以达到600KB，同等规模原生小程序只需要200KB，影响加载性能。同时由于它是一个应用层的方案，上层用JSX，然后会转换为vdom，然后将vdom的变化通过setData同步给原生小程序，存在vdom转换到小程序视图的性能损耗。

来源自掘金文章《Rax小程序运行时方案解密与思考》--逆葵

开发体验也会有一些问题，比如二次构建（Rax构建成小程序的JS文件，小程序JS自身的构建）速度慢，每次保存都要等待一会儿才能看效果。

基于以上问题，我们开始考虑是否可以直接迁移到原生小程序。

?3.0:原生小程序方案

Rax不再维护，其实我们是可以换一个跨端框架的，比如Uni-App，Taro，不过经过团队的讨论，最后我们还是选择原生小程序方案。

为什么是原生而不是跨端框架？

首先，小程序是没有一个标准化的组织，随着时间推移，各家小程序（微信，支付宝、抖音等）的差异肯定是越来越大，像Rax这类的跨端框架需要“抹平”的成本会越来越高。而且抹平一般会采用交集的方式进行抹平，会导致我们无法利用到各个小程序平台的最全能力。跨端框架拥有“WriteOnce，Runeverywhere”的好处，对于0到1探索阶段的项目比较适合，可以快速铺到各个市场，但是无法适用于每日必抢这类对性能、体验、深入融合各端生态有着高要求的项目，基于此我们还是决定拥抱原生建设下单方案。

奥创协议

在介绍下单方案之前先了解下奥创协议，它的作用是用来描述前端页面的渲染协议，它提供了一套机制，让前端开发只关心渲染，业务逻辑统一收敛到后端，同时它统一了前后端交互的三种方式，render（首屏渲染）、async（异步刷新）和submit（提交）。?

这套方案非常适合下单，购物车这类业务逻辑复杂的表单型页面。

举个例子，用户在下单页购买数量加1需要重新计算价格，如果这个逻辑放在前端，后端需要下发限购规则、优惠规则、库存等数据，前端需要按照限购规则判断是否可以加，还需要按照优惠规则重新计算价格，提交的时候后端还需要算一遍，意味着前后端需要写两份相同的逻辑。

随着业务逻辑越来越复杂，两份逻辑需要保持一致变得越来越难做到，将逻辑收敛到后端，前端只关心渲染成为了大势所趋。有了奥创协议，前端只需要按照协议渲染即可，业务逻辑可以收敛到后端。

技术架构

基于奥创协议，自建的一套原生小程序下单方案。原生小程序方案大致分为三层架构：

1.奥创协议搭建层：搭建下单页布局和模型，产出页面schema。

2.后端服务层：基于页面schema，组装业务数据，产出符合奥创协议的数据。

3.小程序页面层：基于奥创协议数据渲染页面，具体分为如下四个模块：

渲染逻辑模块：继承奥创渲染SDK，负责符合奥创范式的渲染逻辑，后面会详细介绍。服务模块：负责跟服务端的数据交互，定义请求和返回处理逻辑业务逻辑模块：处理用户行为触发后的副作用逻辑，比如触发async方法，触发submit方法，组件联动。视图模块：视图层，只负责UI的渲染。

前端奥创渲染SDK

奥创渲染SDK主要是提供一个通用的基于奥创的渲染SDK，下单、购物车等场景可以使用这个SDK快速搭建页面，分为两个主要模块：

1.渲染逻辑模块：一方面负责页面初始化，处理跟后端交互逻辑，比如发送首屏请求；另外一方面是监听奥创数据变化从而渲染页面。

2.主控制模块（Context）：提供跟奥创相关的业务逻辑API，包含协议操作，状态管理以及日志管理等模块。

业务集成奥创渲染SDK，同时注册业务逻辑控制模块和服务模块，然后可以利用Context开放的API可以进行奥创数据进行修改。

业务效果

迁移到原生小程序方案后，性能的提升也非常明显，首先包体积降低了66.6%，同时录屏来看加载性能也提升不少。iPhone14打开速度提升38%。

业务挑战

由于业务逻辑收敛到后端，前端基本不会有业务逻辑，不过跟支付宝合作会员购的项目打破了这个规则。?

由于后端无法直接调用支付宝查询积分接口，需要从前端来调用，然后拿到积分之后需要在价格区域加上积分信息，如下图红框的积分区域是支付宝积分接口返回的。

?方案1：会员购组件内处理

会员购场景会下发会员购组件，一个想法就是在会员购组件通知更新组件数据，可以让逻辑收敛到会员组件里，可以让业务逻辑高内聚。

不过这个方案存在异步接口竞态问题，由于会员购组件查询积分是异步的，如果在异步查询过程中用户行为触发了异步接口，不好控制积分查询异步接口和async接口的返回顺序，如果积分查询接口先返回，async接口后返回，就会出现覆盖积分信息的问题。

?方案2：查询积分放到请求返回之后做

为了解决上面竞态问题，我们把积分查询逻辑放到请求返回之后做，这样子避免了积分查询数据被覆盖的问题。

随着后续场景的接入，在服务模块处理数据成为了一个研发范式。比如下面支付宝红包也是调用支付宝接口查询的，调用时机是在render和async接口返回之后。

开放扩展点（建设中）

未来可预见的问题：

1.类似会员积分、支付宝红包等功能场景会越来越多，这些场景都会同时修改一份奥创协议，如何管理好功能点的执行顺序成了比较大的问题。

2.同时随着更多端接入，每一个端功能点诉求不一致，如何做到功能点快速可插拔也是需要考虑的问题。

解决思路：

提供扩展点，让这些功能点可以通过能力包的方式注册进来。一来通过能力包让功能点的逻辑收敛，更内聚，二来这套下单的范式不受小程序端DSL的影响，后续可以方便应用到其他端。

扩展点主要可分为两个：

1.业务逻辑处理模块：支持注册不同能力包，能力包包含两部分，一个是组件，一个是组件对应的业务逻辑（核心是联动逻辑）。

2.服务模块：提供一些生命周期钩子比如请求开始，返回结束，数据渲染完成后等，同时管理各个能力包的执行顺序（可以在能力包里面声明执行优先级）。

具体见下图红色框区域的部分：

结语

本文详细回顾了每日必抢小程序的下单系统演进历程，着重介绍了各阶段的技术选型、架构设计、遇到的挑战及解决方案。展望未来，其核心在于构建开放扩展点机制，旨在通过能力包注册的方式，灵活应对日益增多的功能场景与不同端的个性化需求，进一步提升系统的可维护性与扩展性。这一系列技术革新与实践，不仅为每日必抢小程序的持续优化与创新提供了强有力的技术支撑，也为业界在小程序开发领域的探索提供了宝贵经验与启示。

参考资料

《Rax小程序运行时方案解密与思考》：https://juejin.cn/post/6890428926540283918

团队介绍

我们是淘天集团用户场景营销技术-大前端团队，一支拥有极致用户体验追求的技术团队，负责淘宝秒杀，淘宝特价版App和小程序等业务场景。我们深入了解业务场景与用户，通过不断探索和实践新的技术，探索创新场域导购产品，持续提升用户的购物体验，同时持续完善供给能力的建设，赋能商家、商品成长打爆链路。

【WINDRISES MINIPROGRAM PROMOTION】尊享直接对接老板

电话+V： 159999-78052

专注于小程序推广配套流程服务方案。为企业及个人客户提供了高性价比的运营方案，解决小微企业和个体拓展客户的问题