我的阿里云服务器，做了图片连接的防盗链，需要添加域名白名单图片才可显示出来 我小程序没加白名单的时候图片显示不出 在白名单加了这个之后https://servicewechat.com 在微信开发者工具可以显示，但是测试版和体验版还是没效果，请问下正式版 体验版该如何填写正确白名单

这两天打开开发工具，点击真机调试按钮时，经常真机调试的二维码生成不出来，偶尔一次能出来等待时间也比较长。预览是可以正常的。开发工具重新打开或清除全部缓存都没效果。这个问题比较严重比较耽误时间，麻烦问下大家有知道原因的吗？[图片] 开发工具版本： [图片]

原创： 京东凹凸实验室 本文从Taro及小程序·云开发的简介开始，介绍了如何通过小程序·云开发搭建电商后台服务，最后再深入地阐述购物车页，订单页的小程序·云开发端处理逻辑，由浅入深地剖析了使用小程序·云开发开发电商后台服务的整个过程。 Taro简介 Taro是由凹凸实验室开源、遵循 React 语法规范的多端开发解决方案，截止目前 star 数已经突破16.9k，受到了前端开发者的广泛关注，成为了当前最受欢迎的小程序多端开发框架之一。 Taro 目前已支持微信小程序、H5、RN、支付宝小程序、百度小程序以及字节跳动小程序，持续迭代中的 Taro，也正在努力兼容更多的端，并增加支持一些新特性。 小程序·云开发简介 先看官方文档的说法： 小程序·云开发是微信团队联合腾讯云团队推出的一套小程序开发解决方案。小程序·云开发为开发者提供完整的云端流程，弱化后端和运维概念，开发者无需购买和管理底层计算资源，包括服务器、数据库、静态存储，只需使用平台提供的简易 API 进行核心业务等开发，实现快速上线和迭代，把握业务发展的黄金时期。 其实翻译过来就是，一个在小程序中使用的，不用购买服务器，不用运维的简易后端体系，主要是为了突出快和简便。所以小程序·云开发，就非常适合那些对数据本身弱依赖的，中小型的功能性小程序使用。 小程序·云开发主要有几大部分组成，分别是云控制台、数据库、云函数、云存储。以及分别在小程序端，和云端使用的 js-sdk、admin-sdk。关于这几部分的具体内容，可以在官方文档中查看。 而与传统的电商后端开发相比，小程序·云开发有以下区别： ​ 传统电商后端开发 小程序·云开发 后端代码 自主编写、开发接口 开发接口，云函数部署 服务器 自主购买、部署 无 数据监控 自主搭建 官方提供，控制台查看 调用日志 自主搭建 官方提供，控制台查看 费用 服务器购买成本 无 项目结构 因为该项目使用了小程序·云开发进行后端开发，故项目结构会有些不同。具体结构使用的是 Taro 初始化时提供的云开发模板，大致结构如下： ├── demo                          代码目录 |   ├── client                    小程序代码目录 |       ├── …            |   ├── cloud                     小程序·云开发相关代码目录 |       ├── functions             云函数相关目录 |           ├── shop              shop 云函数目录 |               ├── index.js      入口函数 |               ├── getShop.js    getShop.js |               ├── package.json |               ├── … |   ├── project.config.json       小程序配置文件 |   ├── tcb.json                  小程序·云开发配置文件 └── README.md                     readme 文件 可以看到目录里主要分了两大块 client和 cloud： client 里和我们平常小程序的开发目录，存放的都是小程序里业务代码。 cloud 里则是放云函数相关的代码，并且是以模板进行分割，每个模块一个云函数。 基于这样的目录结构，小程序·云开发相关的代码与小程序本身的代码进行了有效分隔，极大地方便了项目的管理与开发，同时也有助于云函数的上线部署。 通过小程序通过小程序·云开发搭建电商后台服务 介绍完 Taro 及小程序·云开发，下面便开始讲解如何通过小程序·云开发搭建一个后端服务。 1.后台服务搭建思路 2.数据库建立 3.数据交互 4.【首页】【商详页】后端逻辑处理 5.【购物车】后端逻辑处理 6.【订单页】后端逻辑处理 后台服务搭建思路 首先，我们知道一个最简单的后端程序就是，开启一个 HTTP服务，连接上数据库，然后根据收到的请求进行相关操作，例如数据库的增删查改，返回 HTML，返回接口数据之类，如果要满足外网访问还要部署上线等等。 而用上了小程序·云开发之后，因为云函数这个概念，我们免去了开启服务器和部署的步骤。同时，小程序是天然前后端分离的，也不需要返回HTML。所以在这种情况下，我们所搭建的后台服务最主要为了实现两个部分的内容，分别是数据库的建立和前后端的数据交互。 1.数据库建立 数据库建立，指的是数据集合及一些初始数据的创建。在我们搭建的这个 Demo 里，主要有以下数据集合： [图片] Information - 首页的资讯数据集。主要是以一个资讯为单位的数据集合，一个资讯可能含有商店图片，商店介绍，商品介绍等，主要作导购作用，点击后引导至相关页面。 Shop - 商店页的数据集。以商店为单位，一个商店页面里主要是各种楼层数据。 Commodity - 商品的数据集。显然，一个商品数据自然就是该商品所需要的各种信息。 Cart - 购物车的数据集。以用户为单位存放购物车数据。 Order - 订单的数据集。以用户为单位存放订单数据。 User - 用户信息的数据集。存放用户信息数据。 上面所讲述的 6个数据集，基本就涵盖了一个最简单的电商所需要的各种数据，可以构成一个完整的购物流程。 同时如下图，还可以设置数据集权限。例如将 Information、 Shop、Commodity设置为所有用户可读、仅管理员可写；将 Cart、 Order、 User改成仅创建者及管理员可读写。通过权限限制，增强了数据集的可靠性。 [图片] 2.数据交互 数据集建立起来后，再往里面填充一些假数据，基本的数据就有了，那么在小程序中如何进行数据交互？ 如果不是用小程序·云开发，自然是通过request拉取接口数据，进行展示。而在使用了小程序·云开发的情况下，通过官方提供的 sdk，主要有两种办法进行数据拉取： 1.直接在小程序端操作数据库，获取所需数据，并进行增删查改等操作。 2.使用云函数，把数据库的操作放到云端；然后在小程序端调用云函数，达到类似调用接口的效果。 第一种方法其实比较适合一些简单的、对数据要求不高、量也不大的小程序。不然在小程序的代码中混合着数据库操作，实践起来不太优雅，也不利于维护。 这里重点说下第二种方法。上篇文章有提到了云函数的概念，这里再回顾一下。所谓云函数，就是将一个函数放在Node.js（即服务端）环境下运行。因此，我们可以将数据库的操作放到云函数中执行，然后在小程序中调用云函数，达到一种类似调用接口的效果。回顾我们上一章节说到的云函数的目录： ├── demo                          代码目录 |   ├── cloud                     小程序·云开发相关代码目录 |       ├── functions             云函数相关目录 |           ├── shop              shop 云函数目录 |               ├── index.js      入口函数 |               ├── getShop.js    getShop.js |               ├── package.json |               ├── … |   … └── README.md                     readme 文件 名字叫 shop 的云函数的具体目录在cloud/functions/shop下，可以见到有一个入口文件 index.js，还有其它的子函数。下面看具体代码： [图片] [图片] 在这个例子中，笔者将一个云函数当成一个模块相关函数的入口，根据函数传入的参数来决定调用哪个函数。而被具体调用的函数，执行的是一些数据的操作，然后返回数据。也就是说，在这个 Demo 里一个云函数是一个数据模块的入口，里面引用了许多待被调用的具体函数，视入参而定。 以数据模块为单位分割云函数，是笔者觉得比较好的做法。一来云函数不必分割得太细，毕竟每个云函数都是独立部署的，省去了一些繁琐的操作；二来以数据模块为单位，就有点类似我们传统后端的 MVC 模式，易于开发者无缝接入。当然，这只是其中的一种云函数代码组织方式，并不代表就一定要遵循这样的方式，具体情况具体分析，还是要结合业务的实际情况。 而具体到小程序的调用，就更简单了，只是将请求接口的操作改为调用云函数的操作。比如： [图片] 可以看到，仅仅是将调用 wx.request改为了调用 wx.cloud.callFunction，其它的地方并不需要改变太多。返回的数据也是可以自己定义的，达到了与调用接口相同的效果。 不过云函数有一个缺点，就是每次都要上传部署后才能被小程序端调用，调试起来略显麻烦。一个比较好的调试方法是添加一个测试函数，在本地环境中使用 Node.js 进行测试。 [图片] 2.1【首页】【商详页】后端逻辑处理 经过上一段落的讲解，相信大家对于整个商城后端服务的搭建与处理逻辑已经有了基本了解。下面我们看一下首页和商详页的页面结构。 首页： [图片] 商详页： [图片] 实际上，上一段落中所举例shop云函数，便是处理首页和商详页的后端逻辑。可以看到，其逻辑只是简单的根据id拉取数据并返回，因为整体也并没有过多与用户发生交互的部分，也没有需要后端逻辑处理的部分，总的来说还是比较简单的，在这里便不作过多介绍。 2.2【购物车】后端逻辑处理 购物车页相较于首页和商详页，其逻辑必定是复杂了很多，下面结合页面结构及代码分析一下。 [图片] 上图是商城demo的购物车截图。可以看到在购物车里，小程序·云开发端需要处理的逻辑有商品的选择与反选、商品删除、商品数量的更改、商品型号的更改等等。因此，我们把购物车操作分类，得到如下一个 map： [图片] 然后，在用户执行相应的操作时，我们便会执行到对应的操作函数： [图片] 在这里，每个操作函数的入参都是 oldCartInfo（旧的购物车里的商品）、 skus（需要更改的 skus 数组）。然后返回处理后、最新的 newCartInfo （新的购物车里的商品）。具体的操作函数的逻辑我们便不再阐述了，主要就是对数组进行遍历然后根据相关操作处理数据。 接下来，根据最新 newCartInfo，来得到完整购物车数据，完整的购物车数据结构如下所示： 更新完数据库后，便会返回给前端最新的购物车数据。 总结下来，整个购物车后端逻辑的流程，可以用如下的流程图描述： 如果后续有新的购物车操作需要迭代，或者处理逻辑需要变更，我们也只需要改变小程序·云开发端执行函数 这一部分里面的内容即可。 2.3【订单页】后端逻辑处理 同样的，我们先看一下订单页的结构。 订单详情页： [图片] 订单页这块主要处理的是生成订单的逻辑。每个用户的购物车中，已勾选的商品数据都是存放在数据库中的，所以当用户点击了去结算按钮，触发了结算请求时，后端会直接从用户数据库中的购物车数据，生成一份订单。详细的流程可以用如下的流程图描述： [图片] 下面我们来看具体代码： [图片] 从代码中可以看到，先是遍历当前购物车中的商品，然后把已经勾选的商品存放到 payInfo中。接着根据 payInfo 生成订单数据，同时除移购物车中已被结算的商品，并更新购物车数据库。 整体来说，并没有太复杂的操作，不过需要注意的是，因为存在很多异步的操作，所以会有使用很多 await 命令来进行同步书写。 除了生成订单之外，还有取消订单、删除订单等操作。相较于生成订单，这些就只是读取订单、更改状态而已，便不赘叙。 总结 笔者作为开发者，使用小程序·云开发后，深感其便利性。私以为有以下几点优势： **便捷。**略去了后端部署、运维等步骤，可以快速地构建所需要的后端应用，非常适合灵活轻便的小程序开发。 免费。目前小程序·云开发提供了免费 2GB 的数据库存储和 免费 5 GB 的文件存储，虽然存储量并不是很大，但对于个人开发者来说，这些存储量绰绰有余。 开发简单。小程序·云开发的使用，云函数的开发都是非常简单的，官方提供的API可以让我们便捷地进行操作。只需掌握 JavaScript 和一些异步处理相关的知识，便可以快速上手。 一致性。小程序·云开发是小程序官方推出的一种解决方案，与正常的小程序开发无缝连接，而且不用担心是否会继续维护、升级迭代等的问题。 最后希望这篇文章对于看完的你有所帮助！

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

生成海报相信大家有的人都做过，但是canvas绘图的坑太多。大家可以试试这个组件。然后附上楼下大哥做的可视化拖拽生成painter代码的工具：链接地址https://developers.weixin.qq.com/community/develop/article/doc/000e222d9bcc305c5739c718d56813