写在最前面 之前曾写过“自定义交易组件相关接入指引”，广受好评，解决了很多开发者接入时遇到的问题，当然，其中也不乏一些喂不饱的白眼狼，得到便利还反咬一口，无耻至极，内容如有错误请指正，请文明交流！ 本文会尽可能跟随官方功能迭代而更新内容 有问题可以跟帖回复，尽可能的给你解决（解决不了也没办法🤷‍♀️） 良言一句三冬暖，恶语伤人六月寒。 腾讯在2024年8月12日发布公告：腾讯计划自08月25日起，正式支持商家将视频号小店升级成微信小店。公告原文->点我查看 本文主要介绍24版的“微信小店”的升级内容及对接过程中各流程的注意事项与易错点（暂不包含新店开店流程），文档篇幅较长，如无需查看完整文档可以使用浏览器自带页面搜索功能进行关键字搜索（快捷键Ctrl+F ）。 本文更新日志（后续会对本文变动内容进行标注） 2024.09.06 更新微信小店关联账号数量新规则 2024.08.27 小程序内嵌入商品跟佣问题修复 2024.08.26 更新客服、小程序内嵌入商品跟佣相关内容 2024.08.25 本文发布 1、“原视频号小店”升级“24版微信小店”后新增内容： 1.1 店铺管理新增“主页管理”入口 升级“微信小店”后，在管理后台->店铺管理会新增一个“主页管理”，相当于店铺有了一个首页，目前支持配置精选展示位、商品商品分类、主页背景图以及推荐商品排序 “小店”主页商品排序 调整店铺主页销售中商品的默认展示顺序，可以按照序号排序，数字越小越靠前；同时也支持对单个商品进行置顶或隐藏（图一为后台操作排序，图二圈中部分为对应排序展示） [图片] [图片] 注意事项及其他说明 最多可以置顶50个商品 后序置顶商品会在前序置顶前展示 “小店”主页商品分类 可以在主页创建分类并关联商品，当前支持2级分类 [图片] 注意事项及其他说明 1）分类目前只支持上移/下移排序，暂不支持置顶操作 2）单个分类不能超过10个汉字，支持emoji（这个好评） 3）一二级分类暂未测试到数量上限，不过不建议单个一级分类下配置二级分类过多，有可能会影响其他分类展示，尤其是该分类在第一位的时候 4）分类名称会有内容审核，敏感词及平台不允许发布的内容无法进行创建 5）一个商品是支持挂在多个分类下 主页背景图 可配置一张主页背景图，会按16:9比例展示在主页顶部（自己店铺上传的还在审核，先放官方示意图） [图片] 注意事项及其他说明 1）图片仅支持JPEG、JPG、PNG、BMP格式，大小不超过10M 2）背景图片需审核，带二维码、违反公序良序及其他违反法律法规的内容会被驳回 精选展示位 在主页店铺信息下展示推荐内容，目前支持配置展示商品、指定视频号视频、单篇公众号内容三种内容，样式目前只有大图和小图两种展示方式。 用户端展示商品内容示例-小图模式： [图片] 用户端展示视频号内容示例-小图模式 [图片] 用户端展示公众号内容示例-小图模式 [图片] 用户端展示商品内容示例-大图模式 [图片] 用户端展示视频号内容示例-大图模式 [图片] 用户端展示公众号内容示例-大图模式 [图片] 注意事项及其他说明 1）图片仅支持JPEG、JPG、PNG、BMP格式，测试图片可以超过10M（后续是否会改不清楚，不过图片过大加载是真的慢） 2）展示内容会根据展示内容拉取对应商品首图、视频号视频封面以及公众号文章封面，也可以自行上传图片，这里需要注意的点是即使你的图片在商品可以过审核，但在主页推荐不一定能过审核，两者审核尺度不同 3）小图模式至少配置3个展示位才可以保存，而大图模式配置1个展示位就可以，最多允许配置5个展示位 4）商品仅支持配置自己店铺内商品，视频号内容支持配置任意视频号博主任意公开视频，公众号内容支持选择任意公众号任意公开内容 5）无论大图模式还是小图模式，目前仅支持配置1:1的图片，后续是否优化暂不可知 1.2 客服由企业微信客服切换为小店客服 类似原小程序客服，可通过网页和手机端接收、处理客户咨询。目前已支持查询咨询客户下单信息，向咨询用户发送商品、订单消息，配置快捷短语等，基础功能可以满足大部分用户需求，终于可以不用再去付费买三方客服应用了，这个要👍。 注：这里截图不放自己店铺了，涉及用户隐私太多，图示为官方示意图 1.2 PC端： [图片] 1.2 移动端： [图片] 注意事项及其他说明 客服功能存量商户升级指引"->点我查看"（需升级为微信小店后操作） 1.3 新增店铺关联账号 关联账号可以直接售卖小店内的商品，目前支持关联5个视频号与5个公众号，分别可设置1个对外展示账号。 对外展示账号样式-示例图（目前不会显示视频号、公众号名称，只有入口） [图片] 注意事项及其他说明 1）对外展示账号可以进行修改，每种对外展示类型账号每年3次修改机会。 2）配置关联账号后，该账号可在视频号带货中心>橱窗管理中管理带货商品 3）关联账号详细说明及要求：“->点我查看” 4）如果在电脑上打开了客服网页版且在活跃中，当前手机上是不会重复接收到消息推送，预计9月份会有客服PC端和手机APP推出 5）若微信小店店铺开店满30天，且近30天内DSR均大于等于4.6分，关联账号数量可提升至视频号和公众号各10个。（2024.09.06更新） 2、小程序侧新增能力 2.1 小程序支持内嵌微信小店首页，展示小店首页，并进行跳转交易 store-home 开发文档地址：->点我直达 小程序嵌入微信小店首页组件样式 [图片] 注意事项及其他说明 1）基础库需要3.5.5，否则真机调试不显示，可以在开发者工具选择3.5.5版本进行推送 [图片] 2）支持任意升级微信小店后的任意微信小店APPID 3）内嵌入微信小店首页时会有一个“小店”文字显示在下方，可以通过下述方式屏蔽， .wx_store_home .wx_store_home_img_desc { display: none; } 4）第3点中的代码同时也支持屏蔽组件其他类型信息 wx_store_home_info wx_store_home_img_box wx_store_home_info_logo wx_store_home_img_box wx_store_home_info_title wx_store_home_info_title_text wx_store_home_info_history 2.2 小程序内嵌微信小店商品，展示小店商品，并进行跳转交易且支持小店优选联盟带货跟佣功能。 store-product 开发文档地址：->点我直达 小程序内嵌微信小店商品组件样式 [图片] 注意事项及其他说明 1）基础库需要3.5.5，否则真机调试不显示 2）支持任意升级微信小店后的任意微信小店商品ID，这里需要使用微信小店商品id，不支持商户自定义商品ID 3）如果商品违规下架，内嵌商品会直接显示商品违规下架 4）商品组件也可以参考店铺主页代码，屏蔽对应组件内容信息 5）跟佣还未测试，稍后补充 2.2.1 小程序内嵌微信小店商品优选联盟带货跟佣 2024.08.26 14:00:00 目前带货跟佣测试不通，视频号助手API接口实际请求返回无“product_promotion_link”参数，接口返回参数“promotion_key”值类似“product_promotion_link”，疑似为“product_promotion_link”信息。 在小程序前端测试中，store-product组件包含“product_promotion_link”参数时，无法展示对应小店商品，改为“promotion_key”可以正常显示。 目前测试来看小程序侧并不会校验跟佣信息是否正确，建议自己开发测试时一定要慎重一下此处… 2024.08.27 17:30:00 跟佣测试成功，视频号助手API接口实际请求返回无“product_promotion_link”参数，接口返回参数“promotion_key”即为store-product组件的product_promotion_link参数。 注意：文档写的是product-promotion-link,实际应为product_promotion_link，如果使用product-promotion-link，在前端是不会展示对应商品的。 3、搜一搜新增“小店”分类 截止文章更新，目前只支持根据关键词搜索到店铺，暂不支持搜索到商品 [图片] 持续更新中…

Titan解决方案融合引擎 随着微盟微信小程序业务的拓展，尤其是微盟OS（SaaS新云2.0）的建设，已有的微盟微信小程序SaaS新云1.0开发框架逐渐难以支撑业务形态的拓展。为了解决这个问题，我们设计了允许业务通过开发产品包的模式在新的DSL（Domain Specific Languages）下进行开发。 以下为整体设计架构： [图片] 我们之所以做出这样的设计是因为： 1、由于微信小程序分包之间无法相互存在种种限制，为了开发便捷，在SaaS新云1.0的微信小程序原生开发框架下业务模块依赖往往放置在主包内。 我们需要一种开发模式，让业务开发人员明确的知晓使用的依赖是某种公共能力、还是实际上只是当前业务模块所需要的能力。在开发过程中就从技术层面做出合理规划，梳理业务架构逻辑，把相似功能的页面、组件归纳如一个package，并且通过声明的方式，明确其使用的公共能力（platform）。 2、由于在微信小程序内任意一个模块内都可以对全局的对象（如wx、app等）内的数据、函数进行挂载和修改，在开发层面各个业务模块都有可能干扰小程序整体、或其它模块。 我们需要一种开发环境，能够有效的隔离每个业务模块的运行时环境。在package或platform内，开发者通过声明的方式明确其对外暴露的页面、接口（如果是platform，还有组件）。 3、由于在一个微信小程序分包内调用一个还未加载的分包时会发生报错，业务开发往往在调度另外一个分包内的能力时，往往需要做复杂的逻辑编写。 我们需要一种开发框架，能够自动处理分包的加载和接口调度时完成对所依赖的目标分包的调度机制。 4、由于组件内的结构文件（wxml）和样式文件（wxss）在微信小程序内只能被当前分包内的其它组件或页面引用，或安置在主包内是可以被所有分包引用，无法放入主包的大型组件只能通过手动复制粘贴代码的方式在不同分包内进行维护。 我们需要一种代码编译器，能够在编写过程中维护一套组件代码，在构建过程中自动通过依赖的声明将组件代码分发到所需的各个packages内。 5、由于微信小程序的主包空间有限，而微信原生的导航栏（tabBar）必须声明为主包内的页面时才能够展示，在SaaS新云1.0的微信小程序原生开发框架下，面对日益增加的主包，只能选择放弃微信原生的tabBar，而开发一套满足和微信原生导航栏体验、性能、功能相类似的导航栏技术门槛很高，因此实际产品形态中我们见到的替代品往往是在页面底部加上样式和主导航类似，但是点击后实际上是打开新页面的“伪导航栏”能力。 我们需要一种代码编译器，能够通过声明商户选用的导航栏内容，自动分析提取对应的页面，如果可以在主包内放置下这些页面，则自动编译为含有微信原生导航栏能力的小程序，否则，我们将构建一种虚拟环境，将对应的页面放入分包内，再通过构建一个虚拟的导航栏页面容器，将原有的页面构建为组件嵌入该页面内，并且实现原生导航栏中包括下列刷新、页面切换后的生命周期、保留页面滚动位置和状态、允许使用位置滚动（scrollTop）和固定定位（position:fixed）等一系列功能，进而来实现和原生导航栏相同的用户体验。 6、由于原有的各个解决方案的代码是一个“死”的功能集合，因此在业务架构设计保留了大量给业务开发将各个模块耦合的机会（很多情况下耦合可以提升开发、运行时效率），这就导致如果我们需要灵活组合各个业务功能时存在很大的难度。 我们需要一种开发标准和工程化能力，在开发过程中明确定义每个模块所暴露的接口和获取依赖的逻辑，并且在打包过程中将各种依赖、组件根据合适的标准分发至小程序的主包或模块所对应的分包内。这样我们才能做到自由的模块插拔从而实现微盟商家操作系统的构思。 7、由于早期SaaS微信小程序和之后的多渠道开发框架都是将工程能力暴露给了开发者，这就导致不同现有开发团队的工程化能力都多少被修改。不同的构建方式和配置逻辑，导致多个不同开发团队之间的模块难以同时被处理，并且对统一的持续集成、发布系统也造成了效率上的负担。 我们需要一种开发命令行工具，仅允许开发者按照标准的配置逻辑对项目进行工程化配置。同时我们采用了基于go编写的esbuild作为底层编译器（较目前常用的webpack 5构建速度提升150倍）对项目进行构建。这样大幅度提升了编译效率，为支撑数万商户独立构建、发布做出了准备。 框架内部逻辑说明 Titan框架的抽象思路和核心构建逻辑是通过现在平台（公共、中台）能力对最为原子化的通用能力进行提取，得到最为精简、高效的代码以后，将这些必不可少的通用能力放入platform-main（对应微信小程序的主包）中。 [图片]同时，在一些多个不同业务模块能可以被使用的页面、组件、和APIs中，我们添加了一种platform-extensions的设计逻辑。这些能力由平台能力团队维护（如装修能力组件），但是其代码可能比较沉重，如果放置在主包，可能会导致主包内容过大。并且，这些能力可能并不是每一个业务模块都需要依赖使用。因此，我们的设计是，它们会在构建编译时，通过业务模块对其的依赖，按需打包入对应的业务分包内。如此，就能够对通用的代码逻辑进行统一的管理，但是又避免了主包内珍贵的空间被这些不高频使用的通用逻辑所占据。也因为这些逻辑并不是放在主包内，而是进入分包以加载所特别声明的依赖，故而提升了代码逻辑的加载执行效率。 最后，由于微信小程序内，原生底部导航栏（tabBar）仅可承载主包内的页面，但是我们在开发过程中并不能得知商户自由选择的底部导航上的页面（还有其对应依赖的组件、APIs等）是否会导致主包内的代码超过限制大小（2MB）。因此我们会在构建编译过程中，对商户所选择的底部导航所需的页面进行提取和分析，如果编译结果是底部导航所需的页面和其它主包内的文件之和能够小于或等于限制大小，则自动修改app.json的配置，并把代码打入主包内；如果编译结果是底部导航所需的页面和其它主包内的文件之和大于限制大小，则我们会通过一个虚拟的运行时环境构建一个和原生底部导航栏提议相似的多页面切换环境，并且将该环境放入一个单独的分包内，然后将各个所需的页面合并打入该分包。至此，我们就能够实现一个完整的支持自定义业务能力插拔、动态生成底部导航的微信小程序编译和构建流程。 [图片]除了代码的构建以外，微信小程序还对代码中使用的能力进行了配置化声明。比如，如果需要调度获取地理位置的API，则需要在app.json内声明scope.userLocation，并附上获取地理位置时弹窗内的文案。这样，各个平台、业务模块可能都会需要在app.json内声明相同的选项（如地理位置），但是其对应的配置内容又可能不相同。为此，我们设计的逻辑是，有一个项目全局的配置，如果该配置存在时，则优先采用全局的配置选项，如果全局配置不存在时，为了保障对应的模块能够正常运转，我们会优先取平台能力的声明，再取业务模块的声明。如果同时存在多个平台或业务模块的声明，则优先取构建优先级较高的模块（构建优先级为全局配置内的数组，因此优先级是唯一的，不存在优先级冲突）。 最后，我们来看下在构建、运行时部分Titan框架的简易流程。 其中编译时的逻辑如下： [图片] 运行时逻辑如下： [图片]

老规矩，看完记得点赞+收藏 一、重大利好 1.1 原收款用户账户限制功能下线 即取消原有单个用户单日付款10次次数限制，改为单日向单用户最高可转2万元（不可提高），收款次数无限制 图为原收款用户账户限制功能 [图片] 1.2 由原单笔最低付款限额0.3元调整至最低单笔付款限额为0.1元，一个字：“省钱”！ [图片] 1.3 取消原开通90/30天限制，改为按场景提交申请 [图片] [图片] [图片] 二、用户侧主要改动 总结就一点：当商家单笔转账给用户金额<0.3元时，转账到账通知为简化版消息 [图片] 三、商家侧主要改动 3.1 api改动 3.1.1 发起商家转账接口新增transfer_scene_id字段，用于指定该笔转账使用的转账场景ID，场景ID在商家转账开通后可以获取到，新规则生效后开通“商家转账”产品功能该字段必传，规则前开通“商家转账”产品功能暂时不强制传该参数，建议还是去商户后台及时添加付款场景避免后续变动对自身业务带来影响 [图片] 3.1.3 单个批次转账的明细数量提升至最多支持1000笔，建议对数据进行兼容，避免后台页面发放后通过API拉取信息时出现报错 3.2 业务侧改动 3.2.1 取消原有统一的单笔、单用户付款额度与次数限制，新增以用户转账的不同场景维度对应不同的单笔、单日限额，单个商户号最多可申请添加三个使用场景 [图片] 3.2.2 单笔付款最低金额由原0.3元/笔调降为0.1元/笔 注意：小于0.3元的付款单不支持实名校验及申请电子回单 [图片] 3.2.3 商户号默认单日最高转账额度为10万元，自主申请最高可调整至100万元；商户号单日向单用户最高转账额度为2万元，不再支持提高。 注：提升额度需要先提升账户安全等级，可在账户中心->安全中心进行操作 [图片] 3.2.4 转账给员工与转账给合作伙伴场景需要在商户平台->「商家转账到零钱」添加收款用户openid及姓名，仅可向列表中已添加且姓名一致性校验通过的用户转账。 注意：若不添加或实名不通过，则无法转账成功。商户在进行转账以及转账校验前，应确保所收集及传输的第三方信息已合法获得用户授权。 [图片] 3.2.5 商家转账提供了全新升级的安全防控体系，商户可以针对付款出资验密确认、付款资金专款专用（基本账户收款，运营账户出资），满足合规及安全需求 注意：当前每日付款出资验密确认只可以下发50次，针对小额高频及夜间出款等情况可设置合理的免密额度，设置后在免密额度内的无需确认即可出资。请谨慎选择提高免密金额，在免密金额内仍有可能因平台安全监测发起验密，转账后需留意验密消息。 3.2.6 开通要求 暂时不支持小微商户、个体工商户 商户号历史无风险行为 开通环节需提交转账场景证明资料，并签订转账场景真实性承诺函 3.2.7 账单查询调整 支持下载5年内账单，支持下载2年内电子回单。业务账单格式优化（如下图）。 [图片][图片] 四、其他问题 4.1 申请开通描述写的很详细为什么还会一直被驳回？ 你所认为写的详细≠满足业务审核所要求的“详细”，大概率你写的是一堆废话 可以参考页面示例根据自己业务场景进行详细描述 转账场景与实际业务场景不匹配 所提供业务场景无法核实 4.2 无法通过基本账户出资以后，如何实现自动向运营账户充值？ 在产品中心开通「转账充值」产品，开通后可以得到一个与主体同名的银行卡号，然后使用银行的自动划拨或者定期付款产品，配置对应规则转账到该账户即可，对应功能不同银行产品叫法不同，具体可咨询自己开户银行是否支持该业务 看到这里，你不扫个码？ [图片]

由于无法正常拿到企业微信管理员权限，没法访问后台开启Web开发工具使用，目前只能借助Fiddler工具抓包来调试，请问还有其他工具调试吗？

文档地址：「请求分账（直连）」、「请求分账（服务商）」 Q1：调用请求分账接口返回”非分账订单不支持分账“是什么原因？ A1：请按照以下几点检查： 微信订单号填写错误，请检查确认统一下单时未上传分账标识（profit_sharing=Y）的订单，是不支持分账的 Q2：调用请求分账接口返回”分账金额不足“是什么原因？ A2：请按照以下几点检查： 该订单已全额退款，没有资金可以分账在微信支付中，实际收款之后微信支付会收取一定的结算手续费，在减去手续费后剩余的钱才能分账，详情可参考订单结算手续费说明该订单已解冻，已无分账资金（普通商户分账订单默认冻结期是30天; 电商分账订单默认冻结期是180天）超过订单剩余可分账金额或者该订单已无可分账金额，请检查确认（可调用查询订单待分账金额API确认剩余可分账金额） Q3：调用请求分账接口返回”分账接收方关系不存在，请检查参数中每个接收方的关系“是什么原因？ A3：未添加分账接收方，分账接收方在分账之前需要调用“添加分账接收方接口”添加，请添加接收方后再调用请求分账接口。 Q4：调用请求分账接口返回“分账金额超出最大分账比例”是什么原因？ A4：请检查分账的金额是否超出在商户平台设置的允许分账的最大比例，设置路径如下： 普通直连商户设置分账比例路径：登陆商户平台-产品中心-分账-分账管理比例普通服务商商户设置分账比例路径：需要特约商户可以登录商户平台-产品中心-授权的产品-分账授权中进行设置比例。电商收付通商户设置分账比例路径：登陆服务商商户平台-产品中心-我的工具箱-电商收付通-供应链分账设置里设置连锁品牌分账商户设置分账比例路径：登陆服务商平台-产品中心-合作工具箱-连锁品牌工具箱-品牌专区-品牌交易-品牌供应链分账-供应链分账管理设置 Q5：调用请求分账接口返回”无分账权限“是什么原因？ A5：请按照以下几点排查： 1、未开通分账权限，请开通后再调用分账接口，可参考开通指引 2、请求参数错误，服务商用了普通商户的开发文档提交参数，检查确认 服务商模式请求分账文档 普通商户分账文档 Q6：分账调用“添加分账接收方接口”返回：微信用户姓名与实名不一致 A6：请求中传了字段“个人姓名name”，该字段传了之后会校验用户实名是否正确，请填写正确的用户实名（查看用户实名认证路径：微信-我-服务-右上角三点-实名认证-姓名） Q7：分账调用“请求单次分账接口”返回：分账接收方列表格式错误 A7：receivers中的参数amount类型错误，amount类型是int，请检查确认 Q8：分账接收方类型包括哪些？ A8：有以下几个类型： MERCHANT_ID：商户ID PERSONAL_OPENID：个人openid（由父商户APPID转换得到）PERSONAL_SUB_OPENID: 个人sub_openid（由子商户APPID转换得到） Q9：分账调用“请求单次分账接口”，为什么不返回分账结果 A9：分账是异步的，需要调用“查询分账结果”接口查询确认 Q10：分账调用“请求分账接口”返回：订单处理中，请稍后重试 A10：请按照以下几点检查： 请在订单支付成功1分钟后再调用分账接口未结算的订单，请在结算后再调用分账接口请求分账。查看结算周期路径：超级管理员使用电脑登录商户平台（pay.weixin.qq.com），通过【账户中心】->【商户信息】->【结算信息】进行查看老资金流商户的订单，不支持分账（旧资金流流水介绍、新资金流流水介绍）商户开通了收支分离但手续费账户余额不足（手续费账户最低余额要求是100元以上，在充值手续费账户1小时后，订单会正常结算，即可正常调用分账接口） Q11：分账调用“请求分账接口”返回：分账接收方与原请求不一致 A11：商户分账单号填写错误，调用“请求分账接口”多次分账，要生成新的“商户分账单号”，不能使用已经分过账的商户分账单号 Q12：分账调用“请求单次分账接口” A12：请按照以下几点检查： 签名类型错误，分账接口签名类型目前只支持HMAC-SHA256普通商户的分账订单，请使用普通商户分账接口，不能使用服务商分账接口系统超时，请使用原参数尝试再次掉调用API Q13：调用分账接口是否有额外的手续费 A13：没有，商户的交易订单，平台会正常的收取结算手续费。商户使用分账功能没有额外的费用 Q14：分账调用“请求分账接口”返回：分账接收商户全称不匹配 A14：请按照以下几点检查： 分账接收商户全称填写错误，请填写正确的商户全称，商户全称对应进件接口中的字段“商户名称merchant_name”字段值没有加密，该字段值需要加密后上传，请正确加密后再提交。上传的中文全称乱码，请检查接口编码是否正确，接口需要使用UTF-8编码 Q15：分账调用“添加分账接收方接口”返回：账户不存在 ，请先点击充值 A15：账户未开通，请接收方商户在商户平台点击“充值”创建账户（商户平台-交易中心-充值） Q16：分账如果有退款怎么处理，是否可以回退？ A16：需注意以下几点： 已分出去的资金，在商户接收方同意的情况下，可以发起分账回退。（接收方可在“商户平台-交易中心-分账-分账接收设置”中开启同意分账回退） 更多分账订单退款逻辑，请查看文档说明 [图片]   Q17：分账调用“请求单次分账接口”返回：签名错误 A17：请按照以下几点检查： 使用签名检查工具校验签名算法是否有误确认秘钥是否有误（服务商模式使用服务商商户号秘钥，秘钥是在商户平台配置，如果同一商户号调用其它接口成功可排除是秘钥问题）确认接口实际的请求参数与生成签名原串的参数一致，不能增加或缺少参数（可通过打印签名原串进行排查）确认参数的大小写，参数名与接口文档一致签名原串的参数值使用原始值，不需要encode接口需要使用UTF-8编码 Q18：分账添加接收方接口，是在分账前添加一次，如果接收方无变化，后续是否还需要调用接口再添加 A18：是的，如果接收方没有变化，只需要添加一次即可 Q19：分账调用“查询分账结果接口”返回的分账单状态有几种 A19：有以下几点状态： ACCEPTED—受理成功 PROCESSING—处理中 FINISHED—处理完成 CLOSED—处理失败，已关单  Q20：在商户平台设置了分账动账通知url，为什么收不到通知 A20：请按照以下几点排查： 未设置动账通知url，该链接是通过商户平台【交易中心-分账接收设置】中配置的通知url，必须为https协议。如果链接无法访问，商户将无法接收到微信通知。必须为直接可访问的url，不能携带参数。示例：notify_url：https://pay.weixin.qq.com/wxpay/123456789商户未设置加密的密钥，请登录商户平台操作！请参考什么是APIv3密钥？如何设置？只有分账接收方才能收到分账动账通知，分账方是不会有通知的 Q21：分账调用“请求分账接口”返回：对同笔订单分账频率过高 A21：同笔订单多次分账频率是1秒1次，请降低频率后重试 Q22：分账后资金到可提现是否有中间状态 A22：没有中间状态 Q23：分账后的资金什么时候可提现 A23：分账后钱已经到商户的账户了，可以立刻提现 Q24：分账调用“完结分账接口”的作用是什么 A24: 调用该接口，可以将不需要进行分账的订单金额解冻给商户，解冻后的资金商户可自行发起提现 Q25：分账调用“分账回退接口”返回：参数不正确，请检查参数 A25：return_account与mch_id不能填写为相同的商户号，分账方与接收方商户号一致时，不需要回退 Q26：分账订单调用“申请退款接口”返回：申请退款金额大于剩余未分账金额，请等待分账完成后再试 A26：订单有过部分分账，退款金额不能大于剩余未分账金额，请调用“完结分账接口”解冻剩余资金后再发起退款 Q27：查询分账结果接口里面分账单状态（status）字段，当值为ACCEPTED时是表示分账成功了吗 A27：分账单的状态是表示分账单是否受理成功，并不代表分账是否成功。查看分账是否成功，需要调用查询分账结果接口，查看返回参数“分账接收方列表”里面的字段“分账结果result=SUCCESS”才是分账成功。 Q28：调用“添加分账接收方接口”一次可以添加多个接收方吗 A28：不可以，一次只能添加一个 Q29：请求分账接口返回：分账接收方不允许为分账出资方 A29：请按照以下几点检查： V2接口，“请求单次分账接口”分账接收方不允许为分账出资方，“请求多次分账接口”分账接收方可以为分账出资方V3接口，finish为true的情况，“请求分账接口”分账接收方不允许为分账出资方（这种场景，直接调完结分账API就好）。finish为false的情况，“请求分账接口”分账接收方可以为分账出资方 Q30：调用“请求分账接口”，分账分给多个接收方，会出现分账既有成功又有失败的情况吗 A30：同一次分账请求，会出现有的成功，有的失败的情况。具体请调用“查询分账结果接口”，查看返回参数“分账接收方列表”里面的字段“分账结果result=SUCCESS”才是分账成功。 Q31：“请求分账接口”分账接收方列表中的参数description会体现在分账账单里面吗 A31：在分账方分账账单和资金账单、分账接收方的资金账单里面都会体现 Q32：分账调用“添加分账接收方接口”返回：请求正在处理中，请稍后重试 A32：商户请求并发导致，重新再请求一次即可 Q33：分账调用“添加分账接收方接口”返回：商户已添加的分账接收方个数过多。请先删除多余的分账接收方，并在24小时之后再尝试添加 A33：添加分账接收方的个数限制是2W个，超过这个限制，请按照提示处理 Q34：电商收付通分账调用“请求分账回退接口”返回：可用余额不足，请充值后重新发起 A34：“回退商户号”的账户可用余额不足，需充值后再原单重试才能回退成功。（充值指引：登陆商户平台【交易中心】->【资金管理】->【充值/转入】，根据指引充值即可） Q35：电商收付通分账调用“请求分账回退接口”返回：可用余额不足，请充值后重新发起。这个时候，调用“查询分账回退结果API”却返回：PROCESSING（处理中），这个逻辑是正常的吗 A35：是正常的，逻辑就是这样的。这种情况，商户可以按照提示要求，提醒“回退商户号”充值后再原单重试即可回退成功 Q36：电商收付通分账调用“请求分账回退接口”返回：PROCESSING（处理中），什么情况会返回这种状态 A36：请参考以下几点： 网络抖动导致请求中断商户账户资金转账频繁，导致回退在排队时超时 Q37：电商收付通分账调用“查询分账回退结果接口”返回：TIME_OUT_CLOSED A37：TIME_OUT_CLOSED是fail状态了，也就是处于最终态，是不需要重试的。状态是SUCCESS也同理，也是最终态，不需要重试。返回TIME_OUT_CLOSED时可更换一个回退单，重新分账回退一次即可 Q38：电商收付通分账调用“请求分账接口”返回：分账补贴还未到账，不能受理分账 A38：报这个错误，是因为支付的订单在统一下单里面传了参数“补差金额：subsidy_amount”，传这个参数后，需要调用“请求补差API”完成补差，然后再调用“请求分账接口”即可正常分账 Q39：一笔交易在分账完成之后，将接收方和分账账户的绑定关系解除（删除分账接收方），然后进行分账回退，会成功吗 A39：会回退成功，不受删除分账关系的影响 这里的逻辑有两个： 这笔单曾经分给过了这个商户，且分账成功这个商户开通了分账回退 Q40：分账调用“分账回退接口”返回：PROCESSING A40：过一分钟后原单重试即可 Q41：分账回退有时间限制吗 A41：从订单创建的时间算起，现在分账回退限制180天以内的分账请求 Q42：分账方添加接口，如果相同的分账方重复提交，会返回添加失败，还是覆盖之前的分账方信息 A42：如果系统检测到已经绑定，那么会保留原来的数据，不更新数据，直接返回成功 Q43：在商户平台-管理分账接收方中手动添加分账接收方报错：系统错误，请稍后再试 A43：这个报错的原因是：账户未开通，请接收方商户在商户平台点击“充值”创建账户（商户平台-交易中心-充值） Q44：免充值和预充值的代金券，分账的时候，可分账的金额判断逻辑是一样的吗？比如10-5，使用了免充值代金券，可分账金额是5，使用了预充值代金券，可分账金额是10元还是5元呢 A44：不一样，使用了免充值代金券，可分账金额是5，使用了预充值代金券，可分账金额是10 Q45：电商收付通请求分账接口返回：appid与openid不匹配 A45：请求分账接口里面的APPID必须传电商平台服务商的APPID，所以商户在添加分账接收方时获取的openid，也必须是这个电商平台服务商APPID获取的openid Q46：请求分账回退接口返回：分账指令不存在，请检查是否有对应的分账单 A46：请按照以下几点排查： 分账回退里面的商户分账单号out_order_no，必须是请求分账接口的商户分账单号out_order_no请先调用查询分账回退结果API确认分账是否成功，分账成功的分账单才能调用回退接口正常回退。从订单创建的时间算起，分账回退限制180天以内的分账请求，超过180天不支持回退 Q47：查询订单待分账金额返回：记录不存在 A47：请按照以下几点排查： 记录不存在，可能是单号拼错了，请检查确认订单未结算，请在订单结算后再查询非分账订单，请检查订单支付时是否传了分账标识，传了分账标识的订单，才能正确查询 Q48：商户号能正常完结分账，但是查询分账结果却提示“无分账权限”。是什么原因？ A48：分账权限被冻结，请登陆商户平台查看站内信，按照指引申诉处理。 能正常完结分账的原因是：完结分账，就是将这笔订单的剩余的可分账的钱，都解冻给自己，由于这笔钱本来就是自己的，所以分账完结是一个安全的操作（钱没有给其他人，也没有给服务商，给了自己），所以是不会做权限校验的。当前要分出去给到别人时，就会做相关的权限校验了。 Q49：请求分账接口，当提交请求后返回报错SYSTEM_ERROR，这个时候调用查询分账结果接口查询，每10分钟查询一次，共查询3次（共30分钟）。这样的情况下，是否可以不用原单重试？查询后是否可以换单再提交？ A19：请求分账返回SYSTEM_ERROR时，调用查询分账结果接口3次（30分钟）后，查询结果仍然是不存在的情况：如果商户能保证在30分钟的窗口期内都不会重试，这样做是安全的。 但我们建议在返回SYSTEM_ERROR 情况下，商户还是原单重试，这种最安全，也不用查询和等待一个窗口期。 Q50：一个微信支付单被退完款，还可以继续分账吗？ A50：不可以了，分账是针对该订单冻结的金额进行分账，如果退完款，就不能再分账了。 Q51：比如一个订单支付金额是100.1元，假如手续费是0.1元。分账前先退款了30元，默认分账比例是30%，现在可以分账的金额还是30元，这样理解没有问题吧？ A51：没有问题 Q52：比如一个订单支付金额是100.1元，假如手续费是0.1元。分账前先退款了30元，默认分账比例是30%，现在可以分账的金额还是30元，那就是说，可能出现100退了80，分出去30这种情况？ A52：不会， 两个相加不会超过订单金额的， 也就是说退款没有超过70元的话，可分账金额是30，超过70，可分账金额是剩下的钱。 Q53：普通服务商分账，添加分账接收方这个APPID，如果服务商商户号绑定了两个APPID“B”和"C"，需要分账的订单统一下单中传的APPID是B，这个时候，添加分账接收方中的这APPID可以是“C”吗？还是说必须是“B”？ A53：请注意以下两点： 添加分账接收方的时候，B下的openid，C下的openid都可以但是执行分账的时候，一次分账请求里，只能是同一个appid下的openid，不支持一次分账请求里的openid分别是俩appid下的 Q54：查询分账结果接口返回：记录不存在 A54：请按照以下几点排查： 记录不存在，可能是单号拼错了，请检查确认订单未结算，请在订单结算后再查询非分账订单，请检查订单支付时是否传了分账标识，传了分账标识的订单，才能正确查询订单未分账，所以没有记录，请在订单分账后再查询

README 基于此Postman-cn脚本完善了自定义交易组件当前已公开接口 好用记得点赞 导入方法 以下操作为MAC OS导入流程 1.打开postman，点击“Import” [图片] 2.点击“upload files” [图片] 3.选择下载好的json 脚本，点击“open” [图片] 4.点击“Import”进行导入 [图片] 配置方法 [图片] 脚本下载地址 下载地址：https://cloud.189.cn/web/share?code=IFVB7rzIBNZn（访问码：2ewk） 如下载地址失效请留言，看到后第一时间更新

本文不在更新，请看新版自定义交易组件接入指引 看帖不点赞，bug千千万 需要先申请开通“交易组件场景专用商户号”才可以完成新版交易组件场景接入（申请场景经营商户号这是必要条件），进行接入时一定要按照文档流程顺序进行接入，不要新旧接口混合调用，否则无法正常跑通完整流程，切记！切记！切记！ 先配个图证明新版接入已完成 [图片] 有新问题可以留言，有准确答案（方案）后补充更新 一、升级版自定义交易组件接入说明 1、组件介绍 若商家此前已经完成视频号接入小程序，在小程序中调用升级版自定义交易组件组件后，可在保留原有的界面、功能及交易链路的情况下接入微信视频号场景。通过调用商品上传、订单生成、状态同步等接口，实现在视频号场景中交易资金流、售后、交易纠纷、客服等能力的标准化。 2、功能特点 可在视频号场景实现商品展示和带货等功能 未来可支持更多直播营销玩法(券、 秒杀、预售等) 支持小程序客服组件，商家能更方便收到用户的客服咨询 订单中心显示更完善的订单信息，用户可自行查看订单状态 支持用户在视频号订单中心继续付款、发起售后 3、上线案例 升级版自定义交易组件为商户提供保障用户体验的直播电商全链路能力: 可以使用微信支付商户号，资金结算更规范。 小程序和视频号的订单进行了双向打通，用户可以任选在小程序或视频号订单中心处理订单，例如重新发起支付、确认收货等，大大提升用户体验。 通过打通小程序客服组件，增强了商家处理商品咨询的能力。 [图片][图片][图片] 4、接入流程及官方文档 注意:整个接入流程需要15-30个工作日不等，建议提前准备商品的品牌、资质、类目信息，与开发调试并行，避免延误直播带货计划。 详情见：接入视频号指引 5、关键流程逻辑 注意“橙色”为新加入部分: [图片] [图片] 二、接入过程中常见问题 有新问题可以留言，有准确答案（方案）后补充更新 Q1:新版交易组件需要重新申请商户号吗？是否可以使用原有商户号？ A1：不可以，新版交易组件必须要申请开通场景专用商户号 Q2:新版场景专用商户号费率是多少，是否有优惠，结算周期是多久？ A2：商户号费率为0.6%，无费率优惠，结算周期为7+7日，即用户收货后7天后结算。 Q3:申请新商户号时，最后一步签约遇到“微信实名信息与管理员信息不一致”是什么原因？ A3：申请新的场景专用商户号时，“超级管理员”这一项不支持修改，默认为小程序“超级管理员”实名信息，如需修改，需要为该用户前往成员管理为小程序绑定超级管理员。 Q4:申请新的商户号时，为什么不能修改主体信息? A4：“当前主体”这一项不支持修改，因为商户号主体必须和该小程序注册主体保持一致。 Q5:通过新版自定义交易组件申请的场景专用商户号是否对跨境类小程序（自助报关）有影响？ A5：会，二级商户当前暂不支持自助清关接口调用，留意后续更新通知 Q6:自定义交易组件“升级版”跟升级前的自定义交易组件有什么区别，哪些接口需要升级? A6: 新支付接口，必须走新商户号。 取消订单， 小程序(小程序内以及发现-小程序我的订单)和视频号双向可取消，之前只可以在小程序上取消，然后同步给视频号状态。 申请退款，小程序和视频号双向可申请退款。 申请退货退款,小程序和视频号双向可申请退货退款，之前只有小程序上操作。 未付款订单，小程序和视频号 可在各自订单中心重新支付，同步状态。 确认收货，小程序和视频号双向可确认收货。 同步发货状态接口更新。 Q7：自定义交易组件验收流程走完后, 在MP后台点击完成依旧提示"检测到你未完成此项步骤, 请确认后重试"是什么原因？ A7：需要通过调用新接口进行验收才可以通过。 Q8：调用自定义交易组件创建售后接口ecaftersale/add时报47001错误{“errcode”:47001,“errmsg”:"data format error "} A8：请检查“product_info”字段，注意对应类型为“object”。 Q9：调用自定义交易组件创建售后接口ecaftersale/add时报错2747002，参数错误{“errcode”:2747002,“errmsg”:"参数错误 "} A9：1.请检查“orderamt”参数，传参金额应不含邮费。 2.新旧接口不可混合调用，新接口不支持对旧接口生成的订单创建售后。 3.一个商品仅可以有一笔在流程的售后单，已创建或售后完结也会报次错误。 Q10：调用自定义交易组件“同意退货”接口ecaftersale/acceptreturn时报错“同意退货失败没有默认退货地址，需要在接口中传入” {“errcode”:9700210,“errmsg”:“errmsg” =>”同意退货失败没有默认退货地址，需要在接口中传入"} A10：需要调用“更新商家信息”接口，补充默认退货地址 Q11：调用自定义交易组件“添加商品”接口shop/spu/add时报错“该账号客服方式必须包含微信客服/小程序客服” {“errcode”:1040042,“errmsg”:"该账号客服方式必须包含微信客服/小程序客服”} A11:需要在MP后台配置微信客服/小程序客服后，然后通过“更新商家信息”接口更新商家信息[图片] 调用“获取商家信息”接口应返回一下内容才为成功，“service_agent_type”字段需要同时包含0，1，2三个值 [图片] Q12：调用自定义交易组件“创建订单”接口shop/order/add时报错“不支持的发货方式” {“errcode”:1010036,“errmsg”:"不支持的发货方式“} A12：视频号场景当前只支持“正常快递”方式，其他请留意后续更新。 Q13：自定义交易组件“创建售后单”接口中“refund_reason_type”字段 定义见枚举值定义 “emAfterSalesReason ”，“emAfterSalesReason”对应枚举值是什么？ A13:INCORRECT_SELECTION = 1; // 拍错/多拍 NO_LONGER_WANT = 2; // 不想要了 NO_EXPRESS_INFO = 3; // 无快递信息 EMPTY_PACKAGE = 4; // 包裹为空 REJECT_RECEIVE_PACKAGE = 5; // 已拒签包裹 NOT_DELIVERED_TOO_LONG = 6; // 快递长时间未送达 NOT_MATCH_PRODUCT_DESC = 7; // 与商品描述不符 QUALITY_ISSUE = 8; // 质量问题 SEND_WRONG_GOODS = 9; // 卖家发错货 THREE_NO_PRODUCT = 10; // 三无产品 FAKE_PRODUCT = 11; // 假冒产品 OTHERS = 12; // 其它 Q14:自定义交易组件“获取售后单详情”接口中“status”字段 定义见枚举值定义 “AfterSalesState ”，“AfterSalesState”对应枚举值是什么？ A14:AFTERSALESTATUS_INVALID = 0; USER_CANCELD = 1; // 用户取消申请 MERCHANT_PROCESSING = 2; // 商家受理中 MERCHANT_REJECT_REFUND = 4; // 商家拒绝退款 MERCHANT_REJECT_RETURN = 5; // 商家拒绝退货退款 USER_WAIT_RETURN = 6; // 待买家退货 RETURN_CLOSED = 7; // 退货退款关闭 MERCHANT_WAIT_RECEIPT = 8; // 待商家收货 MERCHANT_OVERDUE_REFUND = 12; // 商家逾期未退款 MERCHANT_REFUND_SUCCESS = 13; // 退款完成 MERCHANT_RETURN_SUCCESS = 14; // 退货退款完成 PLATFORM_REFUNDING = 15; // 平台退款中 PLATFORM_REFUND_FAIL = 16; // 平台退款失败 USER_WAIT_CONFIRM = 17; // 待用户确认 MERCHANT_REFUND_RETRY_FAIL = 18; // 商家打款失败，客服关闭售后 MERCHANT_FAIL = 19; // 售后关闭 Q15：自定义交易组件申请视频号专用商户号后，唤起支付报错: “商户号该产品权限未开通” A15:需要先调用“生成订单”接口，然后调用“生成支付参数”接口获取调取支付所需参数，不要调用微信支付统一下单接口获取调用支付参数 Q16：调用自定义交易组件“同意退款”接口shop/ecaftersale/acceptrefund时报错“同意退款失败” {“errcode”:9700209,“errmsg”:"同意退款失败 退款失败“} A：该问题是订单流转状态不对导致，请严格按照文档流程进行操作调用；新旧接口混合调用也会报此错误。 Q17：二级商户号订单支付流程与原有订单支付流程有什么区别？ A17:主要区别是：二级商户号订单调起支付所需参数是通过“生成支付参数”获取，无需同步支付结果；原流程调起支付是需要通过微信支付统一下单获取，需要同步支付结果。 Q18：调用自定义交易组件售后相关接口：“创建售后单”、“用户取消售后单”、“用户上传物流信息”、“获取售后单列表”、“获取售后单详情”、“同意退款“、”同意退货“、“拒绝售后”、“上传退款凭证”、“更新售后单”等接口时报错{“errcode”: 48001,“errmsg”: “api unauthorized”} A18:未开通视频号场景经营商户号，需要先开通场景经营商户号才可以调用。 Q19:自定义交易组件二级商户单调起支付时报错“JSAPI缺少参数total_fee” A19:生成支付参数失败，没返回正确的预支付 ID，重新调用生成支付参数接口获取新的支付参数即可 Q20：调用自定义交易组件接口报错{“errcode”:61007,“errmsg”:“api is unauthorized to component”} A20:没有完成服务商授权。 Q21：已经开通了自定义交易组件，调用接口还是报错48001 A21:接口鉴权有本地缓存，一般最多10分钟，请稍后再试。 Q22:调用自定义组件接口报错“json异常” A22:结构体比较复杂，请检查字段层级。划重点： json不支持注释！！！json不支持注释！！！json不支持注释！！！ Q23:调用自定义组件接口报错{“errcode”:1000000,“errmsg”:“订单状态流转异常”} A23: 订单严格按照：创建、支付、发货、收货的事件流转，如果已经取消，则不能继续流转。 Q24:调用自定义组件上传图片接口报错{“errcode”:1070008,“errmsg”:"获取图片失败，请使用流式上传 "} A24:一般是图片url在微信侧获取不刀，可能为图片cdn设置了白名单或者cdn服务商把微信出口ip 给“ban”了 Q25:调用自定义组件上传图片接口报错{“errcode”:1070001,“errmsg”:"文件/图片为空 "} A25:检查请求报文协议，需[代码]Content-Type: multipart/form-data[代码] Q26:调用自定义组件上传图片接口报错{“errcode”:1000035,“errmsg”:"无效链接 "} A26:请检查图片链接是否为有效链接 Q27:自定义交易组件接入后没有收到事件回调消息 A27:使用公众平台调试工具确保回调链路正常。事件消息如下 [图片] Q28:视频号橱窗管理获取不到对应小程序 A28:1、检查是否开通视频号场景；2、检查是否绑定了推广员（非小程序超管需要绑定推广员） 持续更新中～～～

各位开发者： 为确保小程序链接合理使用，自 2022 年 4 月 11 日起，URL Scheme 和 URL Link （以下统称为 “链接” ）接口能力规则将进行以下调整： 每个 URL Scheme 或 URL Link 有效期最长 30 天，均不再支持永久有效的链接、不再区分短期有效链接与长期有效链接；链接生成后，若在微信外打开，用户可以在浏览器页面点击进入小程序。每个独立的链接被用户访问后，仅此用户可以再次访问并打开对应小程序，其他用户无法再次通过相同链接打开该小程序；单个小程序每天生成链接数（URL Scheme 和 URL Link 总数）上限为 50 万条。 对于上述 1，在开发层面，相应的服务端接口 urlscheme.generate 和 urllink.generate 将进行以下调整： is_expire 值固定为 true，可不再传该值，若传值为 false 也与 true 一样会生成到期失效链接；若 expire_type 传值为 0，需注意 expire_time 传值的时间戳不超过 30 天，即该参数最长传值有效期为 30 天；若 expire_type 传值为 1，需注意 expire_interval 传值范围为 [1, 30]，即该参数最长传值间隔天数为 30。详细对比见下表： [图片] 已使用该后端接口的开发者可以不进行任何修改，不会出现返回异常。若传值超过新规则合法值，或声明使用永久有效的链接，则均会被赋最长有效期值（30天）；需注意以上新规则生效后的有效期和访问规则变化。 在本次规则调整生效前已经生成的链接，也将自动生效以下规则： 如果有效期超过30天或长期会被降级为30天有效，开始时间从调整日期开始计算；在调整生效后，只能被1个用户访问。 当前已使用微信云开发 静态网站H5跳小程序 与 短信跳小程序、微信服务平台短信服务为用户提供链接的功能不受影响，但同样适用以上规则。 微信团队 2022年3月9日 相关QAQ1：每天下发的短信量级超过50万条，不够用怎么办？ A1：可将生成 scheme 的时机改为在用户打开 H5 时再生成： [图片]

我登录的账号： [图片] 之前有通过这个账号去开通企业账号，然后现在回不去了，不管我怎么切换，所有的回复都是走到企业账户里面！！！ [图片] 请问下这个怎么处理，现在搞得都不敢回复问题了！！！ 我现在这篇帖子是用个人账号在发的，信不信等会儿发布出去就变成企业账号发布的！！！！！

您好： 看到咱们【微信公开课】发布了【重磅|小程序可以实现AR效果了】。作者说【小程序向品牌商户、AR引擎服务商正式开放AR接入】 请问什么条件才能成为你们说的品牌商户或者AR引擎服务商。在哪里进行申请？

在小程序开发过程中，你是否对分包问题感到困扰？ 多业务的分包难以划分 分包体积膨胀 下载并注入无用代码 插件无法实现分包处理 …… 为解决上述问题，微信团队提供【分包异步化】新能力，实现跨分包组件、跨分包方法，成功解决分包难、分包不合理等问题。 • • 分包异步化原理 • • 原有的分包隔离机制导致各分包之间无法引用自定义组件或逻辑代码，因此导致分包难等一系列问题。分包异步化能力打通不同分包的引用关系，解决小程序代码包合理化的问题，支持跨分包组件、跨分包方法。 [图片] • • 跨分包组件 • • 当使用其他分包组件时，代码包需要增加占位组件 (component placeholder)，实现页面高效配置。例如页面展示时，分包 (subpackageB) 仍未下载，进行以下操作实现跨分包组件： 1. 使用组件 <simple-list> 代替 <list>，使用 <view> 代替 <card>，完成页面渲染 2. 完成渲染后，开始下载和注入分包 3. 完成分包下载和注入后，将占位组件替换成真正的组件 // subPackageA/pages/index.json { "usingComponents": { "button": "../../commonPackage/components/button", "list": "../../subPackageB/components/full-list", "simple-list": "../components/simple-list" }, "componentPlaceholder": { "button": "view", "list": "simple-list" } } • • 跨分包方法 • • 在小程序开发过程中，通过require回调函数或requireAsync异步调用2种方法，分包异步化能够引用其他分包的逻辑代码。具体操作如下： // subPackageA/index.js // 使用回调函数风格的调用 require('../subPackageB/utils.js', utils => { console.log(utils.whoami) // Wechat MiniProgram }) // 或者使用 Promise 风格的调用 require.async('../commonPackage/index.js').then(pkg => { pkg.getPackageName() // 'common' }) • • 兼容性要求 • • 分包异步化能力要求基础库版本 2.17.3 及以上（正式发布需在 mp 设置最低版本基础库 2.17.3）。平台能力兼容安卓微信、iOS 微信、1.05.2104272 及以上版本的微信开发者工具。更低版本的基础库兼容工作预计在一个月后完成。 • • 总结 • • 实现分包异步化能力后，主包的「公有」性质被削弱，「前置」性质显得更重要（优先于所有分包注入运行且默认注入运行）。开发者可以根据自身业务诉求，结合分包异步化，进行小程序调优，实现更快的启动速度、按需下载和注入代码包、合理处理公有组件等效果。

前言：什么微搭？微搭（WeDa），全称是腾讯云微搭低代码开发平台。 微搭将繁琐的底层架构和基础设施抽象化为图形界面，通过行业化模板、拖放式组件和可视化配置快速构建多端应用（小程序、H5应用、PC Web 应用等），免去了代码编写工作，让您能够完全专注于业务场景。 微搭以云开发作为底层支撑，云原生能力将应用搭建的全链路打通，提供高度开放的开发环境，且时刻为您的应用保驾护航。 可以实现简易项目全程不写代码，拖拽完成。 参见：产品概述 https://cloud.tencent.com/document/product/1301/48874 2022.02.22 更新说明：鉴于微搭产品已经做了好几版优化，原文和现状出入很大，特做出更新。 开整：目标是做一个简易的用户反馈项目 第一步 创建应用 1，注册腾讯云账号 https://cloud.tencent.com/register 2，完成实名认证 https://console.cloud.tencent.com/developer 3，登录微搭控制台 https://console.cloud.tencent.com/lowcode 4，创建应用位置1：快速开始-》创建应用-》新建自定义应用 位置2：应用开发-》新建应用-》从空白创建 *有四种方式可以创建应用，分别是“从模板创建”、“从数据模型创建”、“从空白创建”、“从Excel创建”。 *本文为了多体验一些内容，特意选择“从空白创建”方式（即新建自定义应用），其他创建方式会更加便捷！ 如图： [图片] *我们选择创建一个WEB端（H5/PC）项目，名字叫简易用户反馈。 如图： [图片] 点击新建后，会直接进入该应用的快速开始页面。 如图： [图片] 但个人习惯是先创建数据源，不着急现在就创建页面，所以让我们先回到应用首页。 可以看到我们刚创建的新应用。 如图： [图片] 以及应用详情： [图片] 接下来，我们先去设置一个用于存储信息的数据源。 第二步 设置数据源位置：应用开发-》数据源-》数据模型-》新建数据模型 早期参与微搭项目的网友需要注意，微搭数据源做了升级，对照关系如图： [图片] 这里我们使用数据模型。 1，新建数据模型如图： [图片] [图片] 然后设置数据模型名称、标识和描述，点击开始新建按钮。 这样就新建了一个数据模型。 如图： [图片] 2，添加数据模型字段默认数据模型中有数据标识、创建时间、更新时间等系统模型字段，我们点击模型字段区域底部的“添加字段”，再增加几个。 1）如图：添加用户账号字段[图片] 设置字段名称、字段标识，选择数据类型，设置最小最大长度，设置必填，然后点击确定添加。 2）我们还可以设置枚举类型的字段比如增加一个“涉及APP”的枚举字段。 如图： [图片] 可以选择是枚举，然后添加枚举项。 最后再加两个字段：问题描述、登录设备。 如图： [图片] 点击确定，数据模型就创建完毕了。 接下来，可以去拖拽控件创建页面了。 第三步 拖拽控件 1，打开应用页面编辑页位置：应用开发-》应用-》编辑应用-》进入应用页面编辑 如图： [图片] 如图：应用页面编辑页 [图片] 工作台主要分为三个功能区：顶部导航栏、组件页面区、编辑预览区 参见官方图示： [图片] 2，拖拽控件 1）表单容器将左侧组件区域的“表单容器”拖到编辑区 如图：这里还可以快速编辑表单场景和数据源绑定 这里建议使用快速编辑，表单场景选择“新增记录”， 然后数据源绑定里面找到刚才新建的数据模型“用户反馈表”，选择“创建单条记录”。 [图片] 选择“创建单条记录”后，页面会自动根据数据模型字段添加页面组件内容。 如图： [图片] 注意：此时是可以直接发布预览的，项目页面可以到此算作完成。 2）调整组件（可忽略）这一步其实可忽略，我是因为个人习惯要调整一下组件。 首先删掉我不要的“所属部门”，点击选中该组件，点删除。 如图： [图片] 点击删除原来“涉及APP”的组件，从左侧拖拽“表单选择”到编辑区域。 这里仍推荐使用“快速编辑”功能，字段绑定直接输入数据模型中的“涉及APP”字段名称app_name。 [图片] 右侧属性区域，改了占位符提示以及选项列表内容（和数据字段枚举对齐）。 [图片] 到底就做好了页面。 第四步 预览和发布1，预览位置：页面右上角-》预览 如图： [图片] 点击预览按钮，会生成提供一个二维码和链接。 [图片] 手机扫码效果： [图片] 2，发布位置：页面右上角-》发布 点击页面右上角的发布按钮，会展示发布弹出层，可以选择发布方式（正式版或体验版），可以设置应用版本号。 系统还会自动进行检查，比如我遇到2个检查问题。 提示我数据源未发布，只有发布的数据源才能公开使用，所以在底部直接点发布即可； 还提示我角色组有更新，点发布或忽略即可。 如图： [图片] 检查项都处理后，在发布弹出层上面点确定，就会进入发布状态。需要稍微等一会。 如图： [图片] [图片] 发布成功后，会提供二维码和访问链接。 [图片] 接下来就可以进行手机或电脑端体验了。 第五步 访问测试 1，扫码或复制H5链接，打开刚做的简易项目页面。如图： [图片] 填写一些信息，然后点击提交。 如图： [图片] 页面显示“提交成功” 2，数据管理后台查看写入数据位置：数据源-》数据模型-》数据管理后台 如图： [图片] 点击“数据管理后台”，或者具体数据模型操作列的“管理数据”，会自动跳转打开数据管理后台页面，并能看到系统为我们自动生成的项目数据列表。 如图： [图片] 点击“用户反馈表”的管理数据，我们打开看一下刚才页面数据是否录入成功。 如果没看到数据，需留意左上角的数据切换，是否选了正式数据。 如图： [图片] [图片] 可以看到录入成功了。 总结：虽然我描述的有点啰嗦，但从头到尾操作下来，确实做到了没写任何代码，全程鼠标点击、拖拽，就完成了一个简易项目。 当然低码并不是完全不写代码，一些项目可能还是要写一点代码的，这个后面找机会我再去试试。 2022.02.22 更新感想：对照一年前的原文，本次更改了很多内容，微搭变的越来越简便易用，越来越好。 感谢阅读！

[图片] 工作中有时候会遇到一些关于“抽奖”的需求，这次以“刮刮乐项目”举例，分享一个实战抽奖功能。 本人对之前网上流传的一些H5刮刮乐JS插件版本进行了一些改造，使其能适用于实际项目，并且支持小程序canvas 2D的新API，这里顺便提下2D API和实际H5 canvas中JS写法非常类似，只有少数不同。 [图片] 1、方法介绍： 1.1 刮刮乐JS组件 [代码]class Scratch { constructor(page, opts) { opts = opts || {}; this.page = page; this.canvasId = opts.canvasId || 'canvas'; this.width = opts.width || 300; this.height = opts.height || 300; this.bgImg = opts.bgImg || ''; //覆盖的图片 this.maskColor = opts.maskColor || '#edce94'; this.size = opts.size || 15, //this.r = this.size * 2; this.r = this.size; this.area = this.r * this.r; this.showPercent = opts.showPercent || 0.2; //刮开多少比例显示全部 this.rpx = wx.getSystemInfoSync().windowWidth / 750; //设备缩放比例 this.scale = opts.scale || 0.5; this.totalArea = this.width * this.height; this.startCallBack = opts.startCallBack || false; //第一次刮时触发刮奖效果 this.overCallBack = opts.overCallBack || false; //刮奖完触发 this.init(); } init() { let self = this; this.show = false; this.clearPoints = []; const query = wx.createSelectorQuery(); //console.log(this.canvasId); query.select(this.canvasId) .fields({ node: true, size: true }) .exec((res) => { //console.log(res); this.canvas = res[0].node; this.ctx = this.canvas.getContext('2d') this.canvas.width = res[0].width; this.canvas.height = res[0].height; //const dpr = wx.getSystemInfoSync().pixelRatio; //this.canvas.width = res[0].width * dpr; //this.canvas.height = res[0].height * dpr; self.drawMask(); self.bindTouch(); }) } async drawMask() { let self = this; if (self.bgImg) { //判断是否是网络图片 let imgObj = self.canvas.createImage(); if (self.bgImg.indexOf("http") > -1) { await wx.getImageInfo({ src: self.bgImg, //服务器返回的图片地址 success: function (res) { imgObj.src = res.path; //res.path是网络图片的本地地址 }, fail: function (res) { //失败回调 console.log(res); } }); } else { imgObj.src = self.bgImg; //res.path是网络图片的本地地址 } imgObj.onload = function (res) { self.ctx.drawImage(imgObj, 0, 0, self.width * self.rpx, self.height * self.rpx); //方法不执行 } imgObj.onerror = function (res) { console.log('onload失败') //实际执行了此方法 } } else { this.ctx.fillStyle = this.maskColor; this.ctx.fillRect(0, 0, self.width * self.rpx, self.height * self.rpx); } //this.ctx.draw(); } bindTouch() { this.page.touchStart = (e) => { this.eraser(e, true); } this.page.touchMove = (e) => { this.eraser(e, false); } this.page.touchEnd = (e) => { if (this.show) { //this.page.clearCanvas(); if (this.overCallBack) this.overCallBack(); this.ctx.clearRect(0, 0, this.width * this.rpx, this.height * this.rpx); //this.ctx.draw(); } } } eraser(e, bool) { let len = this.clearPoints.length; let count = 0; let x = e.touches[0].x, y = e.touches[0].y; let x1 = x - this.size; let y1 = y - this.size; if (bool) { this.clearPoints.push({ x1: x1, y1: y1, x2: x1 + this.r, y2: y1 + this.r }) } for (let item of this.clearPoints) { if (item.x1 > x || item.y1 > y || item.x2 < x || item.y2 < y) { count++; } else { break; } } if (len === count) { this.clearPoints.push({ x1: x1, y1: y1, x2: x1 + this.r, y2: y1 + this.r }); } //添加计算已清除的面积，达到标准值后，设置刮卡区域刮干净 let clearNum = parseFloat(this.r * this.r * len) / parseFloat(this.scale * this.totalArea); if (!this.show) { this.page.setData({ clearNum: parseFloat(this.r * this.r * len) / parseFloat(this.scale * this.totalArea) }) }; if (this.startCallBack) this.startCallBack(); //console.log(clearNum) if (clearNum > this.showPercent) { //if (len && this.r * this.r * len > this.scale * this.totalArea) { this.show = true; } this.clearArcFun(x, y, this.r, this.ctx); } clearArcFun(x, y, r, ctx) { let stepClear = 1; clearArc(x, y, r); function clearArc(x, y, radius) { let calcWidth = radius - stepClear; let calcHeight = Math.sqrt(radius * radius - calcWidth * calcWidth); let posX = x - calcWidth; let posY = y - calcHeight; let widthX = 2 * calcWidth; let heightY = 2 * calcHeight; if (stepClear <= radius) { ctx.clearRect(posX, posY, widthX, heightY); stepClear += 1; clearArc(x, y, radius); } } } } export default Scratch [代码] 1.2 JS 调用方法 [代码]new Scratch(self, { canvasId: '#coverCanvas', //对应的canvasId width: 600, height: 300, //maskColor:"", //封面颜色 showPercent: 0.3, //刮开多少比例显示全部，比如0.3为 30%面积 bgImg: "./cover.jpg", //封面图片 overCallBack: () => { //刮奖刮完回调函数 }, startCallBack: () => { //当用户触摸canvas板的时候触发回调 } }) [代码] 实际中还支持其他很多的配置项，比如缩放比例，刮开比例，放置区域等等，大家可以根据实际需求设置。 1.3 实际页面中的JS调用方法： [代码]//引入刮刮乐部分 import Scratch from './scratch.js'; const app = getApp() Page({ data: { firstTouch: 0, isOver: 0, }, onLoad() { let self = this; new Scratch(self, { canvasId: '#coverCanvas', width: 600, height: 300, //maskColor:"", //封面颜色 bgImg: "./cover.jpg", //封面图片 overCallBack: () => { this.setData({ isOver: "结束啦" }) //this.clearCanvas(); }, startCallBack: () => { this.setData({ firstTouch: "开始刮啦" }) //this.postScratchSubmit(); } }) }, //刮卡已刮干净 clearCanvas() { let self = this; console.log("over"); }, }) [代码] 1.4 HTML/CSS [代码]<-- html --> <view class="wrap"> <canvas class="cover_canvas" type="2d" disable-scroll="false" id='coverCanvas' bindtouchstart="touchStart" bindtouchmove="touchMove" bindtouchend="touchEnd"></canvas> <image class="img" src="reward.jpg" mode="widthFix" /> </view> /* css */ .wrap { width: 600rpx; height: 300rpx; margin: 100rpx auto; border: 1px solid #000; position: relative; } .cover_canvas { width: 600rpx; height: 300rpx; z-index: 9; } .wrap .img { position: absolute; left: 0; top: 0; z-index: 1; width: 600rpx; height: 300rpx; } [代码] 这里注意 type=“2d” 写法，这里使用的是新的2D canvas。 2、注意事项 canvas一些效果不支持真机调试，直接预览就行了 如果刮奖结果是通过第一次触碰canvas触发的，这里的请求需要写一个同步方法 刮刮乐JS的配置会优先判断bgImg这个属性，再判断maskColor 需要反复刮奖，可以反复new 它。 3、代码片段 地址： https://developers.weixin.qq.com/s/RxiaHam574or 建议将IDE工具升级到 1.03.24以上，避免一些BUG [图片] 觉得有用，请点个赞，这是我继续分享的动力~

一、小程序服务商助手监管专区上线通知平台在“小程序服务商助手”小程序新增了 【监管专区】 ，包括服务商旗下小程序违规数据与违规队列展示，支持服务商快速查询小程序违规与申诉情况。详情请参考： https://developers.weixin.qq.com/community/minihome/doc/0002026140063083364baae0250001 二、公众号、小程序回调出口IP变更通知为了提高公众号、小程序回调出口网络质量，微信callback IP地址计划灰度切换到以下腾讯云网络出口网段，详情请参考： https://developers.weixin.qq.com/community/develop/doc/0006c02b1403a0dc693b4132c51001?blockType=1 三、微信卡券将不再支持新申请开通使用“优惠券”功能因“微信卡券>优惠券”产品能力未来将统一升级为“微信支付优惠券”，12月10日0点起，“微信卡券>优惠券”功能将不再支持新商户开通，该功能后续将陆续下线。其他微信卡券功能暂无变化。详情请参考： https://developers.weixin.qq.com/community/develop/doc/000a8aeccf45284fc83bc22d251c01?blockType=1 四、服务平台开放入驻及原有服务升级通知为了更好地为用户提供服务，服务平台在近期进行了改版升级。第三方服务商可在服务平台上传对应行业的小程序开发服务，通过审核后即可进行服务展示。详情请参考： https://developers.weixin.qq.com/community/develop/doc/0004a24516cfd01ec02baefae51401 五、小程序类目资质更新[图片] 备注：绿色字体为小程序类目的更新调整，详情请参考小程序开放的服务类目 第三方快速创建的小程序可选择的类目参考第三方平台-快速创建小程序接口-类目参考表 https://developers.weixin.qq.com/doc/oplatform/Third-party_Platforms/Mini_Programs/Fast_Registration_Interface_document.html

小程序快速审核通道不支持部分类目的加急审核，请耐心等待审核结果。 公告详见：小程序加急审核流程上线 [图片]

之前遇到一个需求，就是要从H5跳转到小程序里，但是微信之前一直没有提供接口做跳转，我们只能做降级方案，在要跳转小程序的地方做了一个弹窗，弹窗里面放小程序码，引导用户长按识别小程序码，然后跳转到小程序内，整个流程非常之长，转化率可想而知也是很低的。 今天刚好看到有人技术群里面问了这个问题，于是我就去看了下微信的文档，发现微信偷偷的更新的这个接口，可以让微信浏览器下的H5跳转到小程序内。 相关文档在这边： https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/Wechat_Open_Tag.html 用的是JS-SDK的接口，需要使用到js-sdk-1.6.0的版本才有支持，https://res.wx.qq.com/open/js/jweixin-1.6.0.js wx.config({ debug: true, // 开启调试模式,调用的所有api的返回值会在客户端alert出来，若要查看传入的参数，可以在pc端打开，参数信息会通过log打出，仅在pc端时才会打印 appId: '', // 必填，公众号的唯一标识 timestamp: , // 必填，生成签名的时间戳 nonceStr: '', // 必填，生成签名的随机串 signature: '',// 必填，签名 jsApiList: [], // 必填，需要使用的JS接口列表 openTagList: [] // 可选，需要使用的开放标签列表，例如['wx-open-launch-app'] }); 在wx.config下面多了一项openTagList，开放标签列表，目前支持配置wx-open-launch-weapp，wx-open-launch-app wx-open-launch-weapp 指H5跳转小程序 wx-open-launch-app 指H5跳转app 我们主要介绍的是wx-open-launch-weapp H5跳转小程序 先上才艺： [图片][图片][图片] html代码如下： var btn = document.getElementById('launch-btn'); btn.addEventListener('launch', function (e) { console.log('success'); }); btn.addEventListener('error', function (e) { console.log('fail', e.detail); }); username为小程序的原始id，path对应的是小程序的链接地址。之前有写过微信H5的应该会知道怎么把这段代码嵌入到之前的代码里面。 目前此功能仅开放给已认证的服务号，网页的域名要在服务号的“JS接口安全域名”下。 亲测<wx-open-launch-weapp>可以跳转到任意合法合规的小程序，是任意的小程序都能跳转！！！！这个接口真开放（不怕人干坏事？） PS： 有个坑，官方文件说的path是/a/b/c?d=1&e=2#fg，类似的这样的链接格式，但是我自己亲测如果直接使用/a/b/c?d=1&e=2#fg这样格式的链接会报页面不存在，然后我想到了小程序那边复制链接的时候会在链接后面加上.html，于是挖槽的事情发生了，把path链接格式换成/a/b/c.html?d=1&e=2#fg这样就能正常访问，不知道是微信故意这样设计的还是bug，有待考证。 然后这个接口真的可以干好多坏事，希望大家能用正确的价值观来正确使用此接口。 微信开放标签有最低的微信版本要求，以及最低的系统版本要求。 如果开发过程中出现以下情况的，要确认一下，微信版本要求为：7.0.12及以上。 系统版本要求为：iOS 10.3及以上、Android 5.0及以上。 [图片]

餐饮行业的线上运营非常重要，传统的线下营销方式已经落伍了。怎么往线上转移，只需要简单的两步： 1、把线下门店的客户加到微信个人号上，同时拉到客户微信群； 2、开通一个小程序，用来做活动，深度服务和连接客户。 小程序通过搭建线上点餐、会员注册、外卖等服务，将线下门店用户不断转化为线上数字化用户，同时联动公众号，深化用户管理及运营，不断扩大核心用户池并提升业绩，再结合零售等场景，综合提升餐饮门店坪效。 小程序提升线下餐饮效益的逻辑示意▼ [图片] 通过小程序更好服务线下餐饮行业，我们建议通过如下3个步骤实现： 1)完善小程序基础服务，搭建持续积累数字化用户池的场景；基础服务是小程序为用户提供价值的基础，在餐饮行业，我们建议搭建的3大基础服务为：点餐、外卖、会员。另外，基于用户实际的消费需求，还可延展出排队、预约、开票、拼团电商等服务。 我们建议，餐饮类小程序须搭建至少一项基础服务，以方便为用户提供实际价值，并积累数字化用户池。 2）完善各类入口，持续推广小程序并扩大用户池；微信为小程序提供了多个入口，在餐饮行业，我们鼓励商家将小程序与线下场景相结合，通过线下场景引流小程序，扩大数字化用户池。 基于实际运用场景，我们建议开通6项小程序基础入口，分别是：线下扫码、搜索、公众号文章及菜单栏、我的小程序、附近的小程序，以及订阅消息。 3）通过场景延伸，完成用户池增值及变现；在完善小程序基础服务，并通过多入口持续扩大用户池之后，餐饮小程序还可通过场景延伸，提升用户池的增值及变现，可延伸的场景包括：基于会员场景的深度运营、裂变-拼团、零售及推荐等。

餐饮门店建立一个自己的门店小程序已经是标配，但是很多门店小程序的运营并没有达到预期效果，老板们经常面临这样的困惑： 第一、小程序的功能有很多，餐饮门店要搭建小程序，应该从何入手呢，是做排队、点餐、外卖，还是会员、营销、直播？ 第二、在小程序里做一次特惠抢券的营销活动，效果可能不错，但是经常没有后续的留存，活动结束之后，用户也没有什么回流，感觉小程序也没什么用。 根据我们的经验，餐饮门店要搭建和运营小程序，可以从以下三个方面着手，一步一步建立起自己的小程序完整功能。九层之台起于垒土，切不可追求功能的全面，而导致运营没有方向。 01 功能搭建阶段 [图片] 小程序功能搭建不难，关键是第一步先做什么。要注意开始一定不用求大求全，一定要结合自己的优势，为用户提供有价值的服务。同时能积累自己的数字化用户，这样才有价值。所以衡量的标准就是能不能更好的帮助门店把用户数字化，作为第一个重要的功能点。 我们首先要想明白餐饮门店小程序的底层目的是什么，最本质上，小程序是帮助餐饮门店实现数字化运营的工具。这其中包括2点：用户数字化和服务数字化。我们期望通过小程序做一些场景的搭建和服务，实现用户数字化的三个核心目标：用户独立标识（手机号、微信OpenID），用户消费数据(菜品、频次、支付方式等)，规模延伸扩大（通过营销、裂变活动扩大用户流量池）。而服务数字化，可以概括为二个核心目标：体验优化（通过用户使用小程序作为自助工具，降低经营成本，提升效率），增值服务（提升门店的综合收益）。 让我们来分析一下，做营销活动，常见的功能是拼团、砍价、秒杀等，这些活动的用户是纯粹的来自线上，和在店内的线下用户数据是割裂的，这样就不是很好的用户数字化方式，老板也会面临这样的困惑：活动做完对我有没有帮助？另外常见的排队、会员、充值等功能，用户主要来自线下，小程序能获得比较完善的用户数据，但是和用户的消费数据是割裂的，也不能在第一步建立完整的用户数字化。而线上线下结合的比较好的方式是点餐和外卖，通过这2个模块，能建立比较完整的用户标识，也能获取用户比较完整的消费行为（地理位置、用餐偏好、菜品偏好），所以可作为小程序第一步功能搭建的模块，完成初始的用户数字化。 既然是线上线下的结合，就一定要把线下能触达用户的优势利用起来，培训服务员通过固定话术主动引导客户：您可以扫描桌上的二维码开始点餐。要成功建立和运营门店小程序，一定要刻意的在门店端增加小程序的使用场景，让用户熟悉和感知小程序功能，培养起使用习惯，这也是任何大品牌的门店小程序能够高速发展起来的必经之路，没有捷径。 门店如何利用小程序开展自营外卖呢？首先把线下的顾客引导加入个人小号或微信群，另外已经在其他大平台上开展外卖业务的，也可以通过卡片等方式引导用户进入门店的私域流量池，后面在群里和小号朋友圈通过自营小程序做一些特惠套餐等营销活动，把用户的点外卖习惯拉到自己的门店小程序上。 有了第一步对用户有价值的核心功能，有了第一批线下转化到线上的数字化用户，才能进入第二步运营增长阶段。 02 运营增长阶段 [图片] 有了第一步的基础，接下来就是深挖场景，精细运营，扩大规模。通过更多的有价值服务，以最有效的方式连接用户。这一步的核心是要关注核心流程的效率，搭建持续增长的用户池。通过数据反馈不断改进核心流程。 [图片] 如何做到精细化运营，最重要的是关注数据。餐饮门店小程序，要特别关注用户的来源，在有用的地方去发力。餐饮小程序要特别关注这些用户来源渠道： 任务栏-最近使用 18%公众号菜单 17%扫一扫二维码 15%其他小程序 10%搜索 8% 而在用户的支付转化率方面，下面这个餐饮行业小程序的入口到支付转化率很好的揭示了要从何处引导用户使用小程序并最终完成支付行为： [图片] 有了运营思路，有了完备的小程序功能，就可以不断扩大数字化用户的规模，如何扩大，最有效的就是社交裂变活动。比较有效的方式比如抽奖、集福袋、拼团、砍价、分销等方式，其底层逻辑就是通过利益驱动，让微信粉丝帮助你进行下一轮传播，吸引更多的人加入到小程序。 这样，我们不断为用户提供有价值的服务，有选择的开展各类营销活动，并不断总结，改进流程，形成正向循环。这时，小程序已经有了大批的用户，在小程序上的操作和支付习惯已经养成，这时就可以延伸到更多场景，实现效益最大化。 03 场景延伸阶段 [图片] 如何延伸到更多场景，实现利益最大化，一定离不开电商。餐饮门店的小程序电商，可以简单概括为外卖和零售两类。基于私域流量的电商/营销是任何品牌门店都不能错过的市场。通过自己门店小程序上的外卖，可以直接连接和服务客户，避免第三方平台的高额佣金支出；零售可以从品牌周边商品做起，或者跨界联合其他品牌做线上营销活动，提升自身品牌影响力，实现更多的收益。 -END- 扫码加小编微信，回复【门店】，进入门店运营案例交流群： [图片]

给各大企业提供一个体温上报，统计收集的一个小程序，方便企业应对疫情

最近在维护微信文档这块内容，遇到一个问题，文档数量多起来编译时间会变慢，而且有时候会越来越慢。后面，发现文档的编译一直走的是单线程的，只用到了一个核，顿时感觉有套路可以走了。node 在 v10 过后提出了 worker_threads 模块，它是在一个单独的 node v8 实例进程里面，可以创建多个线程来进行搞 CPU 任务。 tl;dr 下文主要阐述了一下几点： worker_threads 的基本使用和了解 使用线程池模式，来提高 node 进程的计算速度 用 worker_threads 模块，来优化 vuepress 编译速度 worker_threads 模块和 cluster、child_process 之间的用法和区别 worker_threads 简介 Nodejs 核心执行是基于单线程 + event_loop ，底层是基于 libuv 库，在每次循环中，执行一次完整的 event_loop。所以为了实现 thread_worker 的方式，只有脱离于 node 单线程，单独提供 [代码]worker_threads[代码] 模块来实现。当然，nodejs 还有其他方式实现高性能并发，比如 cluster 和 child_process，不过，这两者在使用和场景上，与 worker_threads 区别还是挺大的。这里我们后面会了解一下。 worker_threads 的应用主要聚焦在 高 CPU 计算，低 I/O 的场景上，比如像现在比较火热的 AI，挖矿计算，或者朴实点的文件编译上。 Note: worker_threads 是在 10.x 版本提出的，但是在使用时，还需要加上 [代码]--experimental-worker[代码] flag，不过不想加 flag 的话，把 node 版本切到 11.7 以上就行。 worker_threads 抽象上提供 mainThread 和 worker。其中： mainThread 相当于就是 nodejs 的主线程 worker 是单独吊起的 worker 子线程 mainThread 通过 [代码]new Worker[代码] 去实例化子线程，然后通过 MessageChannel 来和 worker 通信。 这里参考一下官网例子，顺道先解释一下。下面的 demoCode，描述的是一个文件即作为 mainThread，也作为 worker 的执行。 [代码]const { Worker, isMainThread, parentPort, workerData } = require('worker_threads'); if (isMainThread) { // 通过 isMainThread 判断，是否是 worker 还是 mainthread module.exports = async function parseJSAsync(script) { return new Promise((resolve, reject) => { // 通过 __dirname 引用自身文件创建 worker const worker = new Worker(__filename, { workerData: script }); worker.on('message', resolve); worker.on('error', reject); worker.on('exit', (code) => { if (code !== 0) reject(new Error(`Worker stopped with exit code ${code}`)); }); }); }; } else { // 执行高 CPU 计算 const { parse } = require('some-js-parsing-library'); const script = workerData; parentPort.postMessage(parse(script)); } [代码] 初始化 worker 官方库提供了 Worker 类，用来进行 Worker 的初始化工作。基本格式为： [代码]new Worker(filename[, options]) [代码] 这里，可以通过两种方式来写一个 worker 内容，一种是文件、另外一种 eval 代码。 使用文件初始化 worker 现在你已经写好了 worker.js，文件路径为 [代码]/abs/to/worker.js[代码]。那么，在 mainthread 就可以初始化一个 worker.js。 [代码]let worker = new Worker("/abs/to/worker.js") [代码] 使用 eval 初始化 worker 使用 eval 执行的话，需要设置一下 new Worker 的 eval 参数，将其手动设置为 true. [代码]new Worker(code,{ eval:true }) [代码] 可以看一下实例代码： [代码]// 设置好处 let code = ` let fib(8); function fib(n) { if (n < 2) { return n; } return fib(n - 1) + fib (n - 2); }` // 使用 eval 代码执行 let worekr = new Worker(code,{ eval:true }) [代码] 有时候在进行初始化时，worker 其实还依赖于 mainthread 传入的一些常用变量。nodejs 提供了 workerData 来帮助 coder 完成这件事。 传递给 worker 的初始数据 workerData 的传递，只需要将对应的数据，塞给 new Worker 的初始化 [代码]workerData[代码] 参数。 [代码]new Worker(path,{ workerData:data }) [代码] 需要注意的是，workerData 遵循的是 HTML structured clone algorithm，传递给 worker 时，会 deep-clone 一份，防止 数据的循环引用和保证两个线程之间的数据独立性。也就是说，该 workerData 中的数据只能包含一些基础类型： 不能传函数，保证两个线程的独立性 可以传 Object, Array, Buffer 之类的 更多的，可以参考 https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm 那么，在 worker 中，如何调用 workData 的具体数据呢? 在 worker.js 里面，通过 worker_threads 模块提供的 workerData 来获取。这么说有点抽象，用伪代码模拟下。 [代码]// mainthread.js new Worker("worker.js",{ workerData:{ website:"villainhr.com" } }) // worker.js const { workerData } = require('worker_threads'); // 直接通过 workerData 来获取 let {website} = workerData; [代码] worker 的通信 Worker 的通信主要是 IPC 模式，和 webWorker 一样，也是通过 MessagePort 来互传消息。 Mainthread 向 threadWorker 发消息 主要利用 worker 实例上挂载的 postMessage 方法来实现。 [代码]let worker = new Worker("worker.js"); worker.postMessage("欢迎关注 零度的田 公众号") [代码] Worker 上接受 mainthread 传递的消息，利用 [代码]worker_threads[代码] 模块提供的 [代码]parentPort[代码] 成员对象来。 [代码]const { parentPort } = require('worker_threads'); parentPort.on("message",msg=>{ console.log(msg); // 欢迎关注 零度的田 公众号 }) [代码] 这里有个很重要的点需要注意下，如果你通过 [代码]parentPort[代码] 监听了 [代码]message[代码] 事件，那么该 worker 是不会自动中断的，除非你手动 [代码]terminate[代码] 掉它。 threadWorker 向 mainthread 发消息 那么返回来，在 worker 中，怎么给 mainThread 传递消息？还是需要利用 [代码]parentPort[代码] 对象上，挂载的 postMessage 方法。 [代码]// worker.js const { parentPort } = require('worker_threads'); // 向 mainthread 传递信息 parentPort.postMessage("欢迎关注 零度的田 公众号") [代码] worker_threads 最佳实践 在使用 worker 的过程中，通常是将高 cpu 的计算放在 worker 中运行。根据通信的模式，可以分为两种： 每次接收任务时，单独创建一个原始的 worker 任务，使用完毕后销毁 预先根据 cpu 核数，创建线程池，去执行所有任务 上面两种模式的选取主要是根据业务的模式，不过，一般情况下使用 线程池 会更高效些，因为，重复创建相同的 worker 的话，每次都需要经过一遍 js code 的解码、编译、执行的过程，还是有一定的性能损耗的。 所以，官方推荐是 能用线程池，就不要每次创建 worker。线程池的实现，主要在于 worker_pool 的算法，里面重要功能是需要实现 worker 的调度。 这里推荐一个 worker_pool repo node-worker-threads-pool，这个库在判断 worker 是否 空闲有个取巧的办法，就是当 worker 调用 [代码]parentPort.postMessage("xxx")[代码] API ，返回结果时，就认为该 worker 已经处于空闲状态了。 为了防止这篇内容过于空洞、浮夸，为了证明 我真的不是在吹水。最近在做微信文档构建的时候，使用到 worker_pool 来进行优化。 vuepress 编译实践 前段时间在维护 微信开放文档， 发现每次统一编译需要时间在 110s ~ 200s 之间，差不多 2~3 min 中，有时候如果编译文件过多的话，可能达 5min 左右。后续，随着文件数量的增加，该编译时间可能会拖慢编译的整个流程。 现在的文档的编译是基于 webpack + vue.renderToString 来做的整体编译。webpack 是前端的一个打包工具库，里面的生态已经很成熟。vue.rednerToString 是用来进行 html 的 prerender 方法，作为静态文档的输出部分。 主要的编译过程主要就在上面两个部分当中，为了分析该过程，选择使用小程序开发部分的文件编译，来作为基准。该部分具有的特性为： 所有 md 文件有 1454， 量级比较大 [图片] 在 node 版本 8.6，48 核的机器条件下进行编译，总体耗时为：157s [图片] 拆分看： webpack 的编译耗时为：57s，占比 36% vue.renderToString 的耗时为：100s，占比 64% 所以，这里的主要问题聚焦于，主要减少 vue.renderToString 的时间，尽量减少 webpack 的编译时间。 vue.renderToString 没有提供任何接口来进行性能优化和提升，只是单纯的作为一个模板拼接函数。所以，只能 node 线程入手，即，通过 node 多线程编程充分利用机器性能加快编译速率。 接下来就是 threads_worker 的重点内容了。 其中，vue.renderToString 有一个任务队列，主要是将所有的 pages，按照路径输出模板。通过 worker 的调度器来实现多线程的 renderToString 方案。 [代码]initWorker(){ // 初始化 workerPool 调度器 this.pool = new StaticPool({ size: workerCount, task: this.workerPath, workerData: this.workerData }) } // 执行 vue.renderToString 的任务队列 async renderPages(pages){ let jobs = pages.map(async page=>{ let {html,filePath} = await this.pool.exec(page) await fs.outputFile(filePath,html) }) await Promise.all(jobs) this.pool.destroy() } [代码] 经过多线程的优化，整体的编译时间有挺大的优化。 总体编译耗费时间 优化前：157s 优化后： 84s 优化比例为：46.156% worker_threads vs cluster vs child_process 说道压榨 CPU 性能的点，nodejs 中，除了使用 worker_threads 之外，还有两个模块也能做到， 一个是 [代码]cluster[代码] 、一个是 [代码]child_process[代码]。 cluster cluster 是在一个 master process 中，通过 cluster.fork() 来实例化多个 node v8 实例。可以说 cluster 是多进程的模块，常常用来处理多进程的 node 服务，比如像 pm2。 它的使用方式比较重，每次都需要创建一个进程，并初始化自身的 node 实例，像 event-loop，每个进程都是独立的，所以单个进程发生失败，并不会影响到主进程的稳定性。 具体使用，可以参考 node 文档：https://nodejs.org/dist/latest-v10.x/docs/api/cluster.html#cluster_how_it_works child_process child_process 模块你可以只理解为，它就是一个进程吊起的模块。比如，常常用到的： fork exec spawn 它的执行并不仅仅只限于 nodejs，你用其他语言实现也可以，比如说 python, cpp 二进制文件等。而在 child_process 里面就不存在所谓的通信，父进程通过获得子进程的 stderr、stdout、stdio、stdin 来输出。它进程之间传输数据比较难用，没有所谓的 structure clone 的防止去传递一些对象数据之类的。 worker_threads worker_threads 和上面两者其实都不同，它并没有脱离当前 v8 的进程实例，而是在其中，创建线程，而这些线程和进程类似，都有自己独立的 OS-level API，并且可以使用绝大多数 node 模块。较上面来说，worker_trheads 有以下优势： 单进程，多线程 线程间通信方便，通过 MessageChannel 模式，实现基于事件的跨 线程通信。 可以使用 SharedArrayBuffer，实现多个 worker 共用高效内存 使用简单，在一个 node v8 实例中，共用同一个 event-loop 队列。

1.背景 如今信息流业务是各大互联网公司争先抢占的一个大面包，为了提高用户的后续消费，产品想出了各种各样的方法，例如在微视中，用户可以无限上拉出下一条视频；在知乎中，也可以无限上拉出下一条回答。这样的操作方式用户体验更好，后续消费也更多。最近几年的时间，微信小程序已经从一颗小小的萌芽成长为参天大树，形成了较大规模的生态，小程序也拥有了一个很大的流量入口。 2.demo体验 那如何才能在小程序中实现类原生APP效果的下一条无限刷体验？ 这篇文章详细记录了下一条无限刷效果的实现原理，以及细节和体验优化，并将相关代码抽象成一个微信小程序代码片段，有需要的同学可查看demo源码。 线上效果请用微信扫码体验： [图片] 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a 3.实现原理 出于性能和兼容性考虑，我们尽量采用小程序官方提供的原生组件来实现下一条无限刷效果。我们发现，可以将无限上拉下一篇的文章看作一个竖向滚动的轮播图，又由于每一篇文章的内容长度高于一屏幕高度，所以需要实现文章内部可滚动，以及文章之间可以上拉和下拉切换的功能。 在多次尝试后，我们最终采用了在[代码]<swiper>[代码]组件内部嵌套一个[代码]<scroll-view>[代码]组件的方式实现，利用[代码]<swiper>[代码]组件来实现文章之间上拉和下拉切换的功能，利用[代码]<scroll-view>[代码]来实现一篇文章内部可上下滚动的功能。 所以页面的dom结构如下所示： [代码]<swiper class='scroll-swiper' circular="{{false}}" vertical="{{true}}" bindchange="bindChange" skip-hidden-item-layout="{{true}}" duration="{{500}}" easing-function="easeInCubic" > <block wx:for="{{articleData}}"> <swiper-item> <scroll-view scroll-top="0" scroll-with-animation="{{false}}" scroll-y > content </scroll-view> </swiper-item> </block> </swiper> [代码] 4.性能优化 我们知道view部分是运行在webview上的，所以前端领域的大多数优化方式都有用。例如减少代码包体积，使用分包，渲染性能优化等。下面主要讲一下渲染性能优化。 4.1 dom优化 由于页面需要无限上拉刷新，所以要在[代码]<swiper>[代码]组件中不断的增加[代码]<swiper-item>[代码]，这样必然会导致页面的dom节点成倍数的增加，最后非常卡顿。 为了优化页面的dom节点，我们利用[代码]<swiper>[代码]的[代码]current[代码]和[代码]<swiper-item>[代码]的[代码]index[代码]来做优化，控制是否渲染dom节点。首先，仅当[代码]index <= current + 1[代码]时渲染[代码]<swiper-item>[代码]，也就是页面中最多预先加载出下一条，而不是将接口返回的所有后续数据都渲染出来；其次，对于用户已经消费过的之前的[代码]<swiper-item>[代码]，不能直接销毁dom节点，否则会导致[代码]<swiper>[代码]的[代码]current[代码]值出现错乱，但是我们可以控制是否渲染[代码]<swiper-item>[代码]内部的子节点，我们设置了仅当[代码]current <= index + 1 && index -1 <= current[代码]时才会渲染[代码]<swiper-item>[代码]中的内容，也就是仅渲染当先文章，及上一篇和下一篇的文章内容，其他文章的dom节点都被销毁了。 这样，无论用户上拉刷新了多少次，页面中最多只会渲染3篇文章的内容，避免了因为上拉次数太多导致的页面卡顿。 4.2 分页时setData的优化 setData工作原理 [图片] 小程序的视图层目前使用[代码]WebView[代码]作为渲染载体，而逻辑层是由独立的 [代码]JavascriptCore[代码] 作为运行环境。在架构上，[代码]WebView[代码] 和 [代码]JavascriptCore[代码] 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 [代码]evaluateJavascript[代码] 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 [代码]JS[代码] 脚本，再通过执行 [代码]JS[代码] 脚本的形式传递到两边独立环境。 而 [代码]evaluateJavascript[代码] 的执行会受很多方面的影响，数据到达视图层并不是实时的。 每次 [代码]setData[代码] 的调用都是一次进程间通信过程，通信开销与 setData 的数据量正相关。 [代码]setData[代码] 会引发视图层页面内容的更新，这一耗时操作一定时间中会阻塞用户交互。 [代码]setData[代码] 是小程序开发中使用最频繁的接口，也是最容易引发性能问题的接口。 避免不当使用setData [代码]data[代码] 应仅包括与页面渲染相关的数据，其他数据可绑定在this上。使用 [代码]data[代码] 在方法间共享数据，会增加 setData 传输的数据量，。 使用 [代码]setData[代码] 传输大量数据，通讯耗时与数据正相关，页面更新延迟可能造成页面更新开销增加。仅传输页面中发生变化的数据，使用 [代码]setData[代码] 的特殊 [代码]key[代码] 实现局部更新。 避免不必要的 [代码]setData[代码]，避免短时间内频繁调用 [代码]setData[代码]，对连续的setData调用进行合并。不然会导致操作卡顿，交互延迟，阻塞通信，页面渲染延迟。 避免在后台页面进行 [代码]setData[代码]，这样会抢占前台页面的渲染资源。可将页面切入后台后的[代码]setData[代码]调用延迟到页面重新展示时执行。 优化示例 无限上拉刷新的数据会采用分页接口的形式，分多次请求回来。在使用分页接口拉取到下一刷的数据后，我们需要调用[代码]setData[代码]将数据写进[代码]data[代码]的[代码]articleData[代码]中，这个[代码]articleData[代码]是一个数组，里面存放着所有的文章数据，数据量十分庞大，如果直接[代码]setData[代码]会增加通讯耗时和页面更新开销，导致操作卡顿，交互延迟。 为了避免这个问题，我们将[代码]articleData[代码]改进为一个二维数组，每一次[代码]setData[代码]通过分页的 [代码]cachedCount[代码]标识来实现局部更新，具体代码如下： [代码]this.setData({ [`articleData[${cachedCount}]`]: [...data], cachedCount: cachedCount + 1, }) [代码] [代码]articleData[代码]的结构如下： [图片] 4.3 体验优化 解决了操作卡顿，交互延迟等问题，我们还需要对动画和交互的体验进行优化，以达到类原生APP效果的体验。 在文章间上拉切换时，我们使用了[代码]<swiper>[代码]组件自带的动画效果，并通过设置[代码]duration[代码]和[代码]easing-function[代码]来优化滚动细节和动画。 当用户阅读文章到底部时，会提示下一篇文章的标题等信息，而在页面上拉时，由于下一篇文章的内容已经加载出来了，这样在滑动过程中会出现两个重复的标题。为了避免这种情况出现，我们通过一个占满屏幕宽高的空白[代码]<view>[代码]来将下一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]hidden="{{index !== current && index !== current + 1}}"[代码]来隐藏这个空白[代码]<view>[代码]，并对这个空白[代码]<view>[代码]的高度变化增加动画，来实现下一篇文章从屏幕底部滚动到屏幕顶部的效果： [代码].fake-scroll { height: 100%; width: 100%; transition: height 0.3s cubic-bezier(0.167,0.167,0.4,1); } [代码] [图片] 而当用户想要上拉查看之前阅读过的文章时，我们需要给用户一个“下滑查看上一条”提示，所以也可以采用同上的方式，通过一个占满屏幕宽高的提示语[代码]<view>[代码]来将上一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]wx:if="{{index + 1 === current}}"[代码]来隐藏这个提示语[代码]<view>[代码]，并对这个提示语[代码]<view>[代码]的透明度变化增加动画，来实现下拉时提示“下滑查看上一条”的效果： [代码].fake-previous { height: 100%; width: 100%; opacity: 0; transition: opacity 1s ease-in; } .fake-previous.show-fake-previous { opacity: 1; } [代码] 至此，这个类原生APP效果的下一条无限刷体验的需求的所有要点和细节都已实现。 记录在此，欢迎交流和讨论。 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a

简介 上周发布的 新富文本显示组件 收获了许多关注，为方便大家了解和体验，[代码]demo[代码] 小程序上线啦 [图片] 大家可以在这里查看介绍和示例或者进行自定义的测试，发现任何问题都欢迎反馈哦 立即体验 [图片] GitHub链接 Github链接

[图片] 我们公司是电商做saas的服务商 你好，请问下我们的微信支付服务商要怎么开通分账功能，我看到后台这边说要联系微信支付官方的人开通白名单，能否帮我们的微信支付服务商账号开通这个分账的功能，现在的业务需要使用到微信支付的分账功能。 文档找了一圈都找不到对应的运营人员。 我们公司的服务商商户号是: 1313952501 麻烦帮我们开通一下，谢谢了！

第三方平台代客户复用公众号创建的小程序需要使用到微信支付功能时，不需要对创建后的小程序开通微信支付功能 微信没有给出这方面的说明，所以导致很多开发人员都走错了方向。 其实对于第三方平台代为创建的小程序，需要做的是对微信开放平台的第三方平台下所绑定的“开发小程序”开通微信支付功能 也就是下图所对应的开发小程序，假设该小程序的AppID为：wx1411111111111111 [图片] 所以，如果需要在第三方创建的小程序（假设该小程序AppID为wx2422222222222222）上进行小程序微信收款，那么： （1）使用商户自己申请的微信支付进行收款（这个暂时无法实现） 请登录该微信支付商户平台，在【产品中心 → APPID授权管理】中新增“授权申请单”，此时授权的AppID为wx1411111111111111，而非wx2422222222222222，也就是说就算你在第三方平台代商户创建了1万个小程序，也只需要对一个小程序（也就是原始的开发小程序）进行微信支付授权，这个时候显然是可以在【微信公众平台】上登录上登录原始的开发小程序的，可以轻松进行M-A授权确认 以前会得出上述结论是因为我用的微信支付账户主体与微信开发平台账号主体是一样的 （2）使用服务商模式下的商户号进行收款 请登录微信服务商平台，在【服务商功能  → 特约商户管理】中找到对应的子商户号，对它进行“开发配置”，在【特约商户APPID配置】中添加AppID为wx1411111111111111的原始开发小程序即可（需要注意的是，这个时候再小程序中进行微信支付时，应该在sub_appid填写wx1411111111111111）在【特约商户APPID配置】中添加AppID为wx2422222222222222的小程序即可（需要注意的是，这个时候在小程序中进行微信支付时，应该在sub_appid填写wx2422222222222222，通过wx.getAccountInfoSync().miniProgram.appId获得） [代码]appid:[代码][代码]'服务商商户号对应公众号的appid'[代码][代码],[代码] [代码]sub_appid:[代码][代码]'第三方创建的小程序的appid'[代码][代码],[代码] [代码]mch_id:[代码][代码]'服务商商户号'[代码][代码],[代码] [代码]sub_mch_id:[代码][代码]'子商户商户号'[代码] 服务商可以通过以下页面提供的API，自动为任意特约商户号配置APPID https://pay.weixin.qq.com/wiki/doc/api/xiaowei.php?chapter=20_3&index=3

通过开放平台快速注册的小程序怎么绑定微信支付？ https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=21538208049W8uwq&token=bde48c25c1358221d217ad28e61f0a1042ea06b7 快速申请的小程序没有操作后台，不能登录后台去操作绑定微信支付，那请问下这种模式注册的小程序要怎么绑定微信支付？

- 需求的场景描述（希望解决的问题）     我需要做一个签到功能，要用到人脸对比 - 希望提供的能力     这个云开发怎么做呢

微信小程序社交电商平台，模块自定义排序组合，多种营销模块，砍价、拼团、秒杀、大礼包、阶梯价、抽奖、免单等多种营销模块，会员卡系统，分销系统，商城红包，私密红包，打通服务号，服务号与小程序互动，流量快速变现。 [图片] [图片] [图片] [图片]     有需要可以联系我。 [图片]