配置入口： 小程序后台->-开发->开发设置->服务器域名 [图片] 常见错误及原因分析： [图片]

微信云开发和云托管的区别是什么？两者数据存储的特点有哪些？云开发的云环境等同于云托管的数据库吗？微信云托管的数据库是需要申请服务器吗？

一、项目介绍 此项目基于微信云托管能力范围编写，构建了一个简单的WEB后端服务，统计WEB网页的访问日志，并保存至serverless形态的mysql数据库中，然后在小程序中调用服务接口，获得访问次数。 项目包含微信云托管在单体运行中的基础能力使用，包含基础容器、mysql、微信小程序调用等。 项目技术栈：后端服务（nodejs + express）、WEB网页（原生js）、微信小程序（原生） 如果你已经体验过微信云托管基础能力，可以继续深入体验微信云托管在腾讯云其他产品的关联使用，日志监控等能力。 二、部署流程 (1) 访问github仓库，将项目下载到本地，打开IDE准备对项目进行改造 (2) 访问微信云托管官网,使用微信扫码，选择自己拟用到的小程序，进入开始创建环节。 [图片] (3) 这里环境名称根据自己用途填写即可，一般小程序项目创建一个环境即可，一个环境里可以包含多个服务，可满足绝大部分企业级需求。 (4) 如果你之前小程序中有使用过云开发，并登录过腾讯云官网配置过腾讯云其他云产品，为了方便使用，可在创建框中「网络类型」选择私人网络，将云托管环境配置到与之前相同的网络环境内（如果你不想这么做或者说你什么也没有过，直接系统默认创建即可） (5) 明确知悉云托管环境的费用，并同意服务条款，开始创建。 (6) 创建成功后，会显示如下效果： [图片] (7) 开始创建mysql数据库，如下图所示： [图片] [图片] (8) 填写密码后，mysql正在进行初始化，请注意这里的费用信息，初始化完成后如下图所示： [图片] (9) 点击右上角「数据库管理」按钮，进入数据库管理后台，开始创建一个库，如下图所示，这里库名叫 online (名称随意，若更改的话注意之后操作相应改变) [图片] [图片] (10) 将项目目录中 database.sql 文件导入到 online 库中，效果如下： [图片] (11) 返回微信云托管控制台，mysql栏中添加一个账户，专门用于编程调用，如下图所示： [图片] (12) 在目录werunserver/db.json中，填写mysql数据库信息，其中host和port信息在控制台中 [图片] { "host": "10.0.224.13",//上图中的冒号之前ip地址 "user": "code", //上一步设置的账户名称 "password": "*****", //上一步设置的密码 "port": "3306", //上图中的冒号之后数字 "database": "online" //之前创建的数据库 online } (13) 将项目保存，将项目目录werunserver作为根目录，上传私人git仓库，在这里已github为例。【注意一定是以werunserver为根目录 (14) 在微信云托管控制台，服务栏中，选择新建服务，如下图所示，记得勾选开启公网访问，名字随意设置（这里示例为aaa） [图片] (15) 创建完成后，进入服务管理，如下图所示，选择新建流水线 [图片] (16) 流水线新建配置如下，代码源第一次使用时需要授权： [图片] (17) 新建完成后，如下图所示，点击开始第一次构建： [图片] (18) 构建完成后，如下状态，此时我们就可以开始发布环节了 [图片] (19) 前往「部署发布」开始全量发布流程 [图片] [图片] (20) 发布后效果如下： [图片] (21) 返回服务列表，在服务详情中找到公网地址，复制到浏览器打开： [图片] (22) 由于配置的是低成本模式，所以首次访问存在容器加载过程，耐心等待即可（不断刷新过程中会出现大概几十秒的请求失败框，正常配置网络中，无伤大雅）访问成功后效果如下，每次刷新都会有记录： [图片] (23) 开始微信小程序的测试，将项目中 miniprogram 做为小程序根目录用微信开发者工具导入打开，填写第一步自己创建服务相同的小程序APPID (24) 在小程序开发者工具中打开 pages/index/index.js 文件，填写如下几处信息： [图片] (25) 重新运行，大功告成！ [图片] 三、项目总结 本次部署实践后，你可以继续在此项目基础上进行修改，重新推送更新代码到仓库中，流水线会自动触发构建。 在新版本发布前，可以进行充分测试，云托管提供各种测试白名单配置；测试验证后可以进行灰度发布，最终到100%新版本接单，完成新版本的全量更替；要是嫌麻烦，相信自己的本事，可以全量发布，给个痛快！ 后续在控制台中会支持自定义域名等更多功能，还在路途中，记得常看看更新。

[图片] 各位微信开发者： 以下是微信云托管本周更新公告（2022.3.18-3.25），公告将围绕微信云托管新增能力、功能优化等产品动态每周更新，帮助微信开发者更好地了解和使用云托管。 功能优化&问题修复 1、官方模板 Dockerfile 更新 增加容器内时区设置示例；支持 php-curl 依赖安装；云调用容器证书安装。2、微信支付 DEMO 更新，支持接收支付回调 查看文档 3、公众号 H5 登录模块优化：一个方法完成登录初始化步骤 查看文档 4、VSCode 调试插件、IDE 插件支持小程序调用本地服务 5、文档更新：「微信消息推送能力被动回复和主动回复」、「容器内时区设置指南」 6、文档优化：「本地调试」、「开发常识」 7、云托管快速上手教程更新：种类更多，更易理解 查看教程 8、控制台部分体验交互和文案优化。 功能预告 1、权限管理：支持为项目成员设置不同角色、不同访问及操作权限等，便于团队管理； 2、新模板：消息推送示例； 3、新版本开发环境：更加流畅的本地开发体验。 微信云托管征文活动，分享你的实战心得 教程：快速上手微信云托管 技术支持：微信云托管1V1专家服务 更多功能敬请期待 _________________ 你还期待微信云托管的哪些功能？欢迎在下方留言告诉我们

本文主要介绍了Kbone的适用场景、方案实现、框架优势、开源交流 。 适用场景 Kbone 是一个致力于微信小程序和 Web 端同构的解决方案。 微信小程序的底层模型和 Web 端不同，我们想直接把 Web 端的代码挪到小程序环境内执行是不可能的。Kbone 的诞生就是为了解决这个问题，它实现了一个适配器，在适配层里模拟出了浏览器环境，让 Web 端的代码可以不做什么改动便可运行在小程序里。这样，我们就可以借助 Kbone 快速实现 Web 项目转化为微信小程序项目。 方案实现 方案设计有如下几个前提： 为了更好的复用组件，尽可能完整的支持 Web 端的特性在小程序端的渲染结果要尽可能接近 Web 端 h5 页面所以，与其他同构框架不同，Kbone 是以适配器的方式来支持的。 [图片] 适配器包含两部分：负责提供 dom/bom api 的 js 库和负责渲染的自定义组件，也就是 Kbone 中的 miniprogram-render 和 miniprogram-element，可以看到 Kbone 最终生成的小程序代码里会依赖这两个 npm 包。除此之外还需要一个 Webpack 插件来根据原始的 Web 端源码生成小程序代码，因为小程序代码包和 Web 端的代码不同，它有固定的结构，而这个插件就是 mp-webpack-plugin。 miniprogram-render、miniprogram-element 和 mp-webpack-plugin 这三个包即是 Kbone 的核心。 [图片] 框架优势 因为 Kbone 是通过提供适配器的方式来实现同构，所以它的优势很明显： 大部分流行的前端框架都能够在 Kbone 上运行，比如 Vue、React、Preact 等。支持更为完整的前端框架特性，因为 Kbone 不会对框架底层进行删改（比如 Vue 中的 v-html 指令、Vue-router 插件）。提供了常用的 dom/bom 接口，让用户代码无需做太大改动便可从 Web 端迁移到小程序端。在小程序端运行时，仍然可以使用小程序本身的特性（比如像 live-player 内置组件、分包功能）。提供了一些 Dom 扩展接口，让一些无法完美兼容到小程序端的接口也有替代使用方案（比如 getComputedStyle 接口）。不是所有的方案都是无懈可击的，就像每个人都有优缺点，Kbone 也不例外。 Kbone 是使用一定的性能损耗来换取更为全面的 Web 端特性支持。 开源交流 我们期望通过 Kbone 开源，能够帮助更多有多端需求的项目解决实际问题，也希望更好的完善 Kbone 本身，如果你对 Kbone 感兴趣，欢迎提出 Issue 和 PR ！关于 Kbone 你有什么使用问题或建议，欢迎访问Kbone社区主页发帖交流（PC网页端可发帖）。查看更多 Kbone 相关干货内容，欢迎来到Kbone文章专区。 Github 开源地址： https://github.com/Tencent/kbone 请给 Kbone 一个 Star ! 欢迎提出你的 issue 和 PR！ 国内镜像地址： https://git.code.tencent.com/Tencent_Open_Source/kbone [图片] 腾讯工蜂源码系统为开源开发者提供完整、最新的腾讯开源项目国内镜像 Kbone官方社区地址： https://developers.weixin.qq.com/community/minihome/mixflow/1213301129006825473

本文主要介绍了如何快速上手Kbone-UI，以及Kbone-UI的原理。 开始做 Kbone-UI 的初衷是为了减少 Kbone 的上手难度，需要提供多端的样式统一的 UI 组件库。现在，微信这边已经有了 WeUI 公共样式库来支持 Web 端的对外展示，其中，小程序本身基础组件也是由 WeUI 重构团队来做的。所以，为了达到这个目标，Kbone-UI 的方式是以小程序内置组件和拓展组件为对齐目标， 使用 WeUI 样式提供 H5 和 小程序体验一致的跨端 UI 组件库。 [图片] 主要思路是通过 Page 和 Component 特有环境变量来区分 小程序 和 H5 的环境： // 判断小程序端 const ismp = typeof Page === “function” && typeof Component === “function” 对外按照小程序组件，以 K 为前缀暴露一个统一的组件名称，内部H5端通过 WeUI 样式来适配，而小程序端直接使用内置组件。比如： // 对外暴露： // 小程序端： // H5 端： + weui 快速上手 Kbone-UI 的第一期工作，已经基本完成。为了让用户快速上手，已经提供如下可以参考的基本信息： 《Kbone-UI 文档》 《Kbone-UI 示例》《Kbone-UI 仓库》现在的 UI 库是基于 Vue，考虑点主要是优先满足团队内部的基础开发和使用。后续会随着生态完善，计划提供对应 React 版本。 Kbone-UI 和市面上大部分的其它 UI 库类似，提供了 codeSplit 和全局引用两种方式。 加载全部组件内容，并引入 WeUI 样式库： import KboneUI from 'kbone-ui' import 'kbone-ui/lib/weui/weui.css' Vue.use(KboneUI) 使用按需引入： import KButton from 'kbone-ui/lib/KButton.js' import KView from 'kbone-ui/lib/KView.js' import 'kbone-ui/lib/weui/weui.css' Vue.use(KButton) Vue.use(KView) UI 原理 Kbone-UI 目前是基于 Kbone 来实现的小程序和 Web 端的同构方案。基本方案是通过 KView 组件来模拟大部分交互 UI 的功能组件内容，比如像 KActionSheet、KToast、KToptips 等。 另外，考虑到 Web 端和小程序端的差异，Kbone-UI 需要对三类组件来进行跨平台实现。 KView(div) 组件: 直接通过 KView + css 的方式来模拟一些常用组件，比如像 progress、rich-text、icon、ActionSheet 等。这些实现起来比较容易，可以直接通过 KView 实现两端复用表单组件: 对于一些表单组件，Kbone 默认是直接支持 input[type=“xx”] 来模拟，不过，像 switch, editor 等还是需要通过 wx-xxx 组件来针对特有平台调用。视图组件: swiper, picker-view 这类在 View 层具有强 UI 交互的组件，很难做到两端通用。主要小程序是双线程模型，用户自定义组件无法独立运行在 View 层。对于这类组件，只能通过 Web 端向小程序端同属性适配的方式来做。最近 Kbone-UI 的版本更新还加上了，比较重要的三个视图层组件：swiper、movable-view、scroll-view，以及其他交互组件 slider、dialog： [图片] 整体来说，Kbone-UI 切入的角度和 taro、mpvue 等跨端式的方式不太一样，使用 Kbone-UI 可以在不脱离已有框架(Vue, React)下，实现多端开发目的，而不需要像 taro/mpvue 之类需要重新学一遍语法和框架。目前 Kbone-UI 还处于比较早期状态，前期打算是对齐微信小程序实现好用易用组件，后续，也会持续维护提供更多更好用的组件。 如果你对 Kbone-UI 感兴趣，欢迎在 Github 提出 Issue 和 PR ！关于 Kbone-UI 你有什么使用问题或建议，欢迎访问Kbone社区主页发帖交流（PC网页端可发帖）。查看更多 Kbone 相关干货内容，欢迎来到Kbone文章专区。

kbone 是一个致力于微信小程序和 Web 端同构的解决方案。

按照api开始对接 [图片] 上图配置得服务期地址url是微信向我们发出得请求，可以理解为 用户 ->微信 ->自己得后台服务。微信在中间做了一层转发 wxJava 中给出了相关得例子代码**（代码在wxJava得demo版中给出）** 引入pom [图片] [图片] if (StringUtils.isAnyBlank(signature, timestamp, nonce, echostr)) { throw new IllegalArgumentException(“请求参数非法，请核实!”); 微信推荐我们在接收得时候需要判断一下参数得合法性 [图片] 验证这次消息是否正确 使用得是SHA1 传入预先配置好得token 和 timestamp和nonce 获取结构后 和signature 比较 比较成功后 返回 echostr 成功返回后表示这次就接入成功了 网页授权 [图片] 这里可以值得注意下，提示说“回调页面需在此域名下” 所以 带“http://” 或者带 kj2kvs.natappfree.cc/mayiin/ 都是不对得/ 只有就填个光溜得域名就可以了

微信小程序用JSON作为本地数据库， 现有一个表单数据需要保持到json文件中 项目结构和效果图 项目地址： https://gitee.com/luomingui/applet/tree/master/zlswxapp 待开发：定位，获取手机号，支付功能 [图片] 问题相关代码，请勿粘贴截图data\data.js var localData={ "list":[ { "id":1, "pctype":"车找人", "cfd":"江西南昌艾溪湖7栋", "mdd":"江西南昌火炬广场", "cfdate":"2022-1-17", "bcdate":"14:56:57", "telephone":"13320163492", "kwnun":"1", "hometop":"置顶", "remarks":"", "isread":"1", }, { "id":2, "pctype":"车找人", "cfd":"江西南昌艾溪湖8栋", "mdd":"江西南昌滕王阁", "cfdate":"2022-1-16", "bcdate":"14:56:57", "telephone":"13320163492", "kwnun":"1", "hometop":"置顶", "remarks":"", "isread":"1", }] } module.exports={ JsonList:localData.list } 表单文件：\pages\carpool\add.js formSubmit(e) { var frmdata=e.detail.value; frmdata["username"]=app.globalData.userInfo.nickName; localData.JsonList.push(frmdata); console.log('submit事件：',localData) //在这里需要把表单数据保存到data.js文件中 } 这个地方不知道怎么写

微信小商店源码怎么能看到？想要基于小商店进行二次开发。

瀑布流布局是一种比较流行的页面布局方式，最典型的就是Pinterest.com，每个卡片的高度不都一样，形成一种参差不齐的美感。 在HTML5中，我们可以找到很多基于jQuery之类实现的瀑布流布局插件，轻松做出这样的布局形式。在微信小程序中，我们也可以做出这样的效果，不过由于小程序框架的一些特性，在实现思路上还是有一些差别的。 今天我们就来看一下如何在小程序中去实现这种瀑布流布局： [图片] 小程序瀑布流布局 我们要实现的是一个固定2列的布局，然后将图片数据动态加载进这两列中（而加载进来的图片，会根据图片实际的尺寸，来决定到底是放在左列还是右列中）。 [代码]/* 单个图片容器的样式 */.img_item {  width: 48%;  margin: 1%;  display: inline-block;  vertical-align: top; }[代码]我们知道，在HTML中，我们要动态加载图片的话，通常会使用new Image()创建一个图片对象，然后通过它来动态加载一个url指向的图片，并获取图片的实际尺寸等信息。而在小程序框架中，并没有提供相应的JS对象来处理图片加载。其实我们可以借助wxml中的[图片]组件来完成这样的功能，虽然有点绕，但还是能满足我们的功能要求的。 [代码]<view style="display:none">  <image wx:for="{{images}}" wx:key="id" id="{{item.id}}" src="{{item.pic}}" bindload="onImageLoad">image>view>[代码]我们可以在Page中通过数据绑定，来传递要加载的图片信息到wxml中，让[图片]组件去加载图片资源，然后当图片加载完成的时候，通过bindload指定的事件处理函数来做进一步处理。 我们来看一下Page文件中定义的onImageLoad函数。在其中，我们可以从传入的事件对象e上，获取到[图片]组件的丰富信息，包括通过它加载进来的图片的实际大小。然后我们将图片按照页面上实际需要显示的尺寸，计算出同比例缩放后的尺寸。接着，我们可以根据左右两列目前累积的内容高度，来决定把当前加载进来的图片放到哪一边。 [代码]let col1H = 0;let col2H = 0; Page({    data: {        scrollH: 0,        imgWidth: 0,        loadingCount: 0,        images: [],        col1: [],        col2: []    },    onLoad: function () {        wx.getSystemInfo({            success: (res) => {                let ww = res.windowWidth;                let wh = res.windowHeight;                let imgWidth = ww * 0.48;                let scrollH = wh;                this.setData({                    scrollH: scrollH,                    imgWidth: imgWidth                });                //加载首组图片                this.loadImages();            }        })    },    onImageLoad: function (e) {        let imageId = e.currentTarget.id;        let oImgW = e.detail.width;         //图片原始宽度        let oImgH = e.detail.height;        //图片原始高度        let imgWidth = this.data.imgWidth;  //图片设置的宽度        let scale = imgWidth / oImgW;        //比例计算        let imgHeight = oImgH * scale;      //自适应高度        let images = this.data.images;        let imageObj = null;        for (let i = 0; i < images.length; i++) {            let img = images[i];            if (img.id === imageId) {                imageObj = img;                break;            }        }        imageObj.height = imgHeight;        let loadingCount = this.data.loadingCount - 1;        let col1 = this.data.col1;        let col2 = this.data.col2;        //判断当前图片添加到左列还是右列        if (col1H <= col2H) {            col1H += imgHeight;            col1.push(imageObj);        } else {            col2H += imgHeight;            col2.push(imageObj);        }        let data = {            loadingCount: loadingCount,            col1: col1,            col2: col2        };        //当前这组图片已加载完毕，则清空图片临时加载区域的内容        if (!loadingCount) {            data.images = [];        }        this.setData(data);    },    loadImages: function () {        let images = [            { pic: "../../images/1.png", height: 0 },            { pic: "../../images/2.png", height: 0 },            { pic: "../../images/3.png", height: 0 },            { pic: "../../images/4.png", height: 0 },            { pic: "../../images/5.png", height: 0 },            { pic: "../../images/6.png", height: 0 },            { pic: "../../images/7.png", height: 0 },            { pic: "../../images/8.png", height: 0 },            { pic: "../../images/9.png", height: 0 },            { pic: "../../images/10.png", height: 0 },            { pic: "../../images/11.png", height: 0 },            { pic: "../../images/12.png", height: 0 },            { pic: "../../images/13.png", height: 0 },            { pic: "../../images/14.png", height: 0 }        ];        let baseId = "img-" + (+new Date());        for (let i = 0; i < images.length; i++) {            images[i].id = baseId + "-" + i;        }        this.setData({            loadingCount: images.length,            images: images        });    } })[代码]这里是显示在两列图片的wxml代码，我们可以看到在scroll-view>组件上，我们通过使用bindscrolltolower设置了事件监听函数，当滚动到底部的时候，会触发loadImages去再加载下一组的图片数据，这样就形成了无限的加载：/scroll-view> [代码]<scroll-view scroll-y="true" style="height:{{scrollH}}px" bindscrolltolower="loadImages">  <view style="width:100%">    <view class="img_item">      <view wx:for="{{col1}}" wx:key="id">        <image src="{{item.pic}}" style="width:100%;height:{{item.height}}px">image>      view>    view>    <view class="img_item">      <view wx:for="{{col2}}" wx:key="id">        <image src="{{item.pic}}" style="width:100%;height:{{item.height}}px">image>      view>    view>  view>scroll-view>[代码]好了，挺简单的一个例子，如果你有更好的方法，不吝分享一下哦。 完整代码可以在我的Github下载：https://github.com/zarknight/wx-falls-layout                                                                                                                                          原作者：一斤代码（简书作者）  原文链接：http://www.jianshu.com/p/260f2623562d

场景： 在小程序中大家应该都有这样的场景，在onLaunch里用wx.login静默登录拿到code，再用code去发送请求获取token、用户信息等，整个过程都是异步的，然后我们在业务页面里onLoad去用的时候异步请求还没回来，导致没拿到想要的数据，以往要么监听是否拿到，要么自己封装一套回调，总之都挺麻烦，每个页面都要写一堆无关当前页面的逻辑。 直接上终极解决方案，公司内部已接入两年很稳定： 1.可完美解决异步问题 2.不污染原生生命周期，与onLoad等钩子共存 3.使用方便 4.可灵活定制异步钩子 5.采用监听模式实现，接入无需修改以前相关逻辑 6.支持各种小程序和vue架构 。。。 //为了简洁明了的展示使用场景，以下有部分是伪代码，请勿直接粘贴使用，具体使用代码看Github文档 //app.js //globalData提出来声明 let globalData = {   // 是否已拿到token   token: '',   // 用户信息   userInfo: {     userId: '',     head: ''   } } //注册自定义钩子 import CustomHook from 'spa-custom-hooks'; CustomHook.install({  'Login':{     name:'Login',     watchKey: 'token',     onUpdate(token){       //有token则触发此钩子       return !!token;     }   },  'User':{     name:'User',     watchKey: 'userInfo',     onUpdate(user){       //获取到userinfo里的userId则触发此钩子       return !!user.userId;     }   } }, globalData) // 正常走初始化逻辑 App({ globalData, onLaunch() { //发起异步登录拿token login((token)=>{ this.globalData.token = token //使用token拿用户信息 getUser((user)=>{ this.globalData.user = user }) }) } }） //关键点来了 //Page.js，业务页面使用 Page({   onLoadLogin() { //拿到token啦，可以使用token发起请求了 const token = getApp().globalData.token },   onLoadUser() { //拿到用户信息啦 const userInfo = getApp().globalData.userInfo },   onReadyUser() { //页面初次渲染完毕 && 拿到用户信息，可以把头像渲染在canvas上面啦 const userInfo = getApp().globalData.userInfo // 获取canvas上下文 const ctx = getCanvasContext2d() ctx.drawImage(userInfo.head,0,0,100,100) },   onShowUser() { //页面每次显示 && 拿到用户信息，我要在页面每次显示的时候根据userInfo走不同的逻辑 const userInfo = getApp().globalData.userInfo switch(userInfo.sex){ case 0: // 走女生逻辑 break case 1: // 走男生逻辑 break } } }) 具体文档和Demo见↓ Github：https://github.com/1977474741/spa-custom-hooks 祝大家用的愉快，记得star哦

message：Error: 系统错误，错误码：80051,source size 3020KB exceed max limit 2MB

[图片] 每次真机调试，都会跳这个页面？网上也没找到原有，有没有知道怎么解决的。十分干感谢！

一行文字太多，用view标签包裹时，超出屏幕，如何让其换行？ <view style=“overflow-wrap: break-word”> [代码]123213123123213213213213213213213213213213213211232131231232132132132132132132132132132132132112321312312321321321321321321321321321321321321 [代码] </view> 简单粗暴

云开发基础·云开发控制面板介绍 [视频]

云开发基础·云开发是什么 [视频]

2分钟快速了解微信云开发 [视频]

云开发基础·云开发基本功能演示 [视频]

背景如标题所述 具体一点：在小程序里开通的组件版本的小商店，和自主注册的小商店如何互通的问题。 即自主注册的小商店，怎么接入到自己的小程序里呢？用组件版小商店，店铺里的数据需要做迁移吗？

一、小商店是什么 1.小商店是什么？ 微信小商店是小程序团队提供的一项新能力，无需开发、免费开店，帮助商家快速生成卖货小程序。小商店将降低商家在微信经营和卖货的门槛，让更多中小微企业和个体创业者可以低门槛的进入小程序生态尝试经营，开展电商业务。 2.小商店有几种类型？ 小商店有四种类型： （1）企业/个体店 企业营业执照类型为：有限责任公司、股份有限公司、合伙企业、个人独资企业等。 个体营业执照类型为：个体工商户 （2）个人店 按电商法规定无须进行市场主体登记的个人主体。 （3）事业单位 是国家为了社会公益目的，利用国有资产设立的，从事教育、科技、文化、卫生等活动的社会服务组织，如旅游、报社、杂志社、学校等机构。 （4）其他组织 不属于个体户、企业、政府/事业单位的组织机构，如民办非企业、社会团体、基金会、合作社等组织。 3.“企业/个体店/事业单位/其他组织”与“个人店”有什么区别？ （1）功能差异 目前企业店功能更加完善，支持直播、优惠券、数据中心等功能，个人店的功能也在同步完善中，敬请期待。 （2）收款限额 个人店正常日收款上限额度为10万，若交易良好则自动提升至20-30万/日，若交易异常则自动下降至5万以下/日。信用卡单日收款上限不超过1千，信用卡单月收款不超过1万。 二、如何开通一个小商店 1.开通流程包括哪些？需要准备什么材料？ （1）搜索“小商店助手”小程序，点击“免费开店”，选择开店类型 （2）企业/个体/事业单位/其他组织店 pc登录网址： https://shop.weixin.qq.com/ https://mp.weixin.qq.com/ 扫码登录小商店，完成开店任务（共四步），即可卖货经营 -经营信息填写：营业执照（营业执照照片并填写相关信息）/事业单位法人证书（证件照片并填写相关信息）/相关登记证书（证件照片并填写相关信息）、经营者/法人信息（身份证正反面照片）、超级管理员信息（姓名、身份证号、手机、邮箱） -验证账户：法人扫描二维码验证/小额打款验证，两种方式任选其一即可 -基础信息填写：小商店头像、名称、店铺简介；品牌与类目信息（如有品牌，提供商标注册证相关信息） -签约开张：用超级管理员的微信扫描二维码即可完成签约 （2）个人店 -完善经营者信息：身份证正反面照片 -签约开张/协议签署 2.没有营业执照可以开通小商店吗？ 如果没有营业执照，可以开通个人小商店，请搜索“小商店助手”小程序，点击“我要开店”，选择开店类型“个人”。 3.开通小商店有数量限制吗？ （1）企业/个体/事业单位/其他组织店：一个微信号能申请3个“企业”，“个体”，”事业单位“和”其他组织“主体的小商店。 （2）个人店：一个微信号仅能申请1个“个人”主体的微信小商店。 4.开店后还可以变更店铺类型吗？从企业店改为个人店？ 目前暂不支持变更店铺类型，如果需要开设其他类型的店铺，需重新申请。 三、如何登录小商店 1.小商店怎么登录？ （1）企业/个体/事业单位/其他组织店： pc端登录网址： https://shop.weixin.qq.com/ https://mp.weixin.qq.com/ 用微信扫描二维码，在移动端选择对应小商店，即可跳转小商店后台。 （2）个人店：搜索“小商店助手”小程序，点击“进入我的店” 2.可以支持手机登录小商店管理后台吗？ 已实现双端互通，个人店和非个人店均支持网页端、移动端登陆及管理。 3.谁可以扫码登录小商店？ 注册小商店的微信号、超级管理员、添加的其他管理人员。 四、开店任务常见问题 （一）主体信息 1.营业执照/事业单位法人证书/相关登记证书信息审核不通过怎么办？ 请根据营业执照/事业单位法人证书/相关登记证书驳回原因，仔细核对填写的相关信息是否准确。保证：营业执照/事业单位法人证书/相关登记证书证书未过期、清晰可见、如有二维码，尽量保证二维码可扫描。如果核对之后未发现错误，请至小商店后台，点击联系客服，我们将尽快跟进排查。 2.普通营业执照/事业单位法人证书/相关登记证书为什么要提交组织机构代码证？ 个体工商户的工商营业执照和2015年10月1日前企业申请的工商营业执照及事业单位法人证书/其他组织相关登记证书，不包含组织机构代码信息，为非三证合一类营业执照/证书，因此商家提交该类证件时需要补充组织机构代码证。参考图例： https://developers.weixin.qq.com/miniprogram/product/mini-store/yingyezhizhao/putong.html 3.商户简称怎么填？ 商户简称会在支付完成页向买家展示，填写商户名称即可。个体工商户，若营业执照上商户名称为空或为“无”，填写“个体工商户+经营者姓名”即可。 （二）超级管理员信息 1.超级管理员要填谁？ 超级管理员信息需要填写注册微信号时的身份信息。 2.超级管理员可以更换吗？ 小商店后台暂时不支持更换超级管理员。 3.填写超级管理员的时候要注意什么？ 填写超级管理员信息时，务必注意填写真实姓名、身份证号，否则无法完成校验。 4.小商店可以多人管理吗？怎么进行多人管理？ 企业/个体/事业单位/其他组织店支持多人管理（个人店暂不支持）。在“店铺-成员管理”中，添加成员即可，可以添加不同岗位，设置岗位权限。 （三）验证账户 1.怎么验证账户？ 验证账户有两种方法，任选其一即可。 （1）法人验证：使用法人微信号扫描二维码即可验证成功。 （2）汇款验证：根据页面提示小额打款至指定账户，验证成功后，打款金额会原路退回。 2.验证账户有有效期吗？ 若30天内一直未完成验证，将自动驳回申请单。若未超过30天，申请单被审核驳回，可再次提交申请单，完成账户验证流程。 （四）基础信息填写 1.店铺名称可不可以重名？ 小商店不会出现店铺同名的情况，以下几点请各位商家注意： （1）小商店是小程序的一种类型，所以小商店不能和现有小程序同名，即使是同一主体也暂不支持。 （2）如果小商店和现有公众号同名，需保证二者是同一主体。 2.店铺名称、头像、简称、介绍可以修改吗？ 小商店的名称和头像都可以修改。 个人店请至移动端店铺后台，点击“我-店铺信息” 企业店请至pc端后台，点击“店铺管理-基础信息” 修改次数限制如下： （1）店铺名称：企业/个体每年5次，个人每年3次 （2）店铺头像：企业/个体/个人每年5次 （3）店铺简称：企业/个体每年2次，个人每年3次 （4）店铺介绍：企业/个体/个人每月5次 3.店铺名称补充材料是什么？ 当店铺名称命中一些品牌、旗舰店保护词之后,需要提交相关资质材料，请根据页面提示上传相应材料。 （五）品牌申请 1.如何申请品牌？ 开店任务中可以申请品牌，需要依照页面提示上传相应资质。 开店任务完成后，在“店铺-品牌与类目”模块中，可以申请新品牌。 2.品牌有哪几种类型？申请不同类型的品牌需要什么资质？ 品牌分为三种类型：自有品牌、代理品牌、无品牌。不同类型品牌需要不同的资质，详细规则可以点击链接查看。 自有品牌：https://developers.weixin.qq.com/miniprogram/product/mini-store/pinpai/ziyou.html 代理品牌：https://developers.weixin.qq.com/miniprogram/product/mini-store/pinpai/daili.html 3.如果是自有品牌，但商标主体和小商店主体不一致怎么办？ 如果属于以下情况，我们支持提交相关证明材料。详情请点击链接至（开通品牌常见问题）查看。 https://developers.weixin.qq.com/miniprogram/product/mini-store/#三、微信小商店品牌开通规则 五、在小商店可以卖什么 （一）开放类目范围 小商店共开放超过2000个类目，一级类目包括：宠物生活、厨具、家用电器、手机通讯、数码、电脑&办公、服饰内衣、鞋靴、个人护理、母婴、美妆护肤、家纺、家居日用、家具、家庭清洁&纸品、家装建材、工业品、汽车用品、玩具乐器、运动户外、箱包皮具、酒类、食品饮料、钟表、农资园艺、生鲜、二手、生活服务、图书、艺术品、教育培训 详细类目开放范围请点击链接查看： 非个人主体店：https://developers.weixin.qq.com/doc/ministore/minishopspecification/leimuzizhi/qiye.html 个人店：https://developers.weixin.qq.com/doc/ministore/minishopspecification/leimuzizhi/geren.html 为什么我的类目列表里没有xx类目？ 小商店部分类目需要资质，不会直接显示在“新增商品”的类目列表里，需要到“店铺-品牌与类目”模块申请所需类目，并上传相应资质。 （二）类目资质要求 哪些类目需要资质？这些资质有示例吗？ 小商店部分类目需要资质，当你在“新增商品”过程中，发现没有某个类目时，可以到“品牌与类目”模块申请类目，如果选择了需要资质的类目，页面会提示上传相应资质。 整体类目及商品资质如下，请点击链接查看，具体资质证照可以点击跳转查看示例 非个人主体店类目资质： https://developers.weixin.qq.com/doc/ministore/minishopspecification/leimuzizhi/qiyeleimu.html 非个人主体店商品资质： https://developers.weixin.qq.com/doc/ministore/minishopspecification/leimuzizhi/qiyeshangpin.html 个人店商品资质： https://developers.weixin.qq.com/doc/ministore/minishopspecification/leimuzizhi/gerenshangpin.html （三）类目/商品审核 1.我的商品还没通过审核怎么办？ 2.我提交了资质，对审核结果有异议怎么办？ 3.希望开设更多类目，对现有类目的资质要求有异议怎么办？ 如果你出现以上情况，可以通过后台的联系客服途径，反馈问题，客服人员会尽快跟进处理。 六、有什么营销功能 （一）怎样让人看到我的小商店？ 小商店曝光渠道：任务栏、发现入口、客服消息、小程序码、搜索、对话分享、群分享、APP分享、模板消息、公众号Profile页/文章插入、LBS广告、微信广告 商品曝光渠道：对话分享、群分享、APP分享、小程序互跳、公众号自定义菜单/文章插入、二维码、模板消息 [图片] （二）优惠券 1.优惠券有哪几种类型？ 目前小商店支持的优惠券功能，包括店铺优惠券和指定商品优惠券，每一种类型的优惠券都会分为直减券、满减券和折扣券。所有券支持两种发放渠道，小商店内推广发放和自定义渠道推广发放。 2.店铺内推广发放和自定义渠道发放的区别？ （1） 小商店内推广发放： 商家在管理后台制作优惠券并生效后，优惠券会自动出现在小商店的各个位置，如小商店首页、商品详情页出现优惠的特殊样式，下单页也会出现简易的凑单提示。 商家可设置“仅该商品可以使用的优惠券”，在视觉样式上提升该商品的下单转化率，或设置一些合理的梯度满减优惠券，在给用户更多优惠的同时提高单用户单次访问的购买订单消费总额。 （2）渠道优惠券： 当商家开通小商店并将商品分发给其他人进行售卖时，可配置专属优惠券，当其他人员售卖商品时，商家在后台的优惠券详情明窗看到专属优惠券具体产生了多少次购买，了解该人员带来的订单量。 3.优惠券创建创建之后可以取消吗？ 商家发布优惠券时可设置有效期，生效后的优惠券，用户已领取，则暂时不支持作废用户已领的优惠券。 （三）公众号 1.小商店怎么关联公众号？ 登陆公众号后台-小程序管理-关联小程序搜索-输入小商店名称 2.小商店的带货商品链接怎么插入公众号推广？ 带货商品链接支持插入公众号文章和自定义菜单进行推广，具体步骤请查看下方链接： https://developers.weixin.qq.com/community/business/doc/0000e265b90e00615a2b7c6c75b00d （四）带货 1.如何查看佣金的打款时间？ 带货佣金需要等待对应平台打款后，才能打款给商家。 可点击「带货收入」查看佣金，进入「待打款佣金」页面，显示「预估X月20日可打款」栏有金额显示，如果填写的银行卡信息正确，到日期后就会进行打款。一般下单到最终收到佣金需要45-60天； 显示「平台未打款」栏，即对应第三方平台并未打款至小商店，可查看到预计的佣金款项。 更多小商店带货能力结算规则，请查看： https://developers.weixin.qq.com/community/business/doc/00064631af05c0783d8b3e9955b00d 2.商品接入范围？ 鉴于微信小商店对带货平台、带货商品的资质有严格的审核要求，目前链接搜索仅支持京东、拼多多、有赞的符合小商店售卖规定的商品，其它平台暂未支持；其他平台（包括唯品会和当当）上仅支持部分已经进入商品库的商品。 3.带货成功后需要我联系供应商发货吗？ 不需要。只需负责带货，生成订单后，供应商主动发货，售后问题由该带货商品的平台、供应商负责。 4.带货商品也可以在视频号售卖吗？ 是的，带货商品上架小商店之后也可以在视频号直播的时候进行选择添加并售卖。 5.怎么带货？ 小商店带货指引详情请见 https://developers.weixin.qq.com/community/business/doc/0000a210138b70c91c2bc32f35180d 更多关于小商店带货能力推广问题，请查看: https://developers.weixin.qq.com/community/business/doc/00084c90ecc3b0983a8b23c8156c0d 6.企业店支持带货吗？ 现阶段暂时只支持个人小商店带货，企业店带货能力敬请期待。 7.为什么带货订单里看到的佣金，和我分享的时候显示的不一样？ 在带货的时候看到的佣金为预估佣金，由于买家下单时可能会使用京豆、京东余额等虚拟货币，导致记佣金额减少，进而导致订单收益变少。 8.订单取消、订单已完成、平台未打款，分别是什么意思？哪些情况下我可以收到打款？ 订单取消，是指因为用户主动取消订单、或第三方平台审核失败等原因，导致订单失效无法记佣。这种情况下无法收到打款。 订单已完成是指买家已经收到货并确认，但第三方平台还没有和腾讯结算，还不能收到打款。 平台未打款，是指京东、拼多多等第三方平台还没有和腾讯结算，还不能收到打款。 9.买家收货后，我什么时候可以收到打款？ 买家收货并且没有发生退款及其他售后纠纷等行为的情况下，第三方电商平台会将该笔订单标记为审核通过的订单。腾讯公司会在每个月20号左右和第三方平台对当月审核通过的订单进行结算，并在次月20号左右完成打款。通常这一周期为30～60天。 更多关于小商店带货能力收入管理问题，请查看: https://developers.weixin.qq.com/community/business/doc/0002aea8e94a58f83b8be95ea5600d （五）导购分销 导购分销已开放给所有企业/个体店（个人店不支持） 1.导购被添加后，无法登录手机端后台管理？商家如何正确添加导购？ 如果「店铺管理」中没有添加导购管理员，只在「导购分销」中添加导购，则导购是无法成功登陆后台导购管理体系的。 （1）方法一：商家需先在「店铺管理」-「成员管理」中添加导购管理员，商家或已被成功添加的导购管理员进入「营销中心」-「导购分销」添加导购分销员。 注：添加导购管理员和导购分销员，需在小商店后台由管理员主动添加，暂不支持增加自主申请成为导购。 （2）方法二：需要该导购删除「小商店助手」小程序后，重启该小程序。 2.导购如何推广带货商品？ （1）导购分销员可通过生成「海报」和「复制链接」的推广方式，引导客户进入小商店购买，链接可挂在公众号或其他小程序中使用（链接分享至视频号不支持结算分成）。 （2）现已支持通过小程序转发记佣。导购通过在推广商品中点击进入程序，直接分享该小程序商品页面，也算该导购的。 3.导购员分享商品且交易完成，但后台没有给导购员提成？ （1）情况一：该导购进行了无效推广 若客户在导购A的有效客户关系中，通过导购B推广的链接购买商品，该客户直接从B的链接购买，则计算给B。 （2）情况二：该商品被设置的结算规则有误 需确认该商品被设置的结算规则，有以下两种结算方式。 交易完成后结算——客户确认收货后，即订单完成后，该订单的相应提出才能结算给导购。 无法发起退款后结算——用户无法发起退货退款后才能结算。 （3）情况三：被同店其他导购抢客 顾客A通过导购A分享的商品海报或链接进店后，无立即购买到商品，又通过同一家店的导购B海报或链接扫码进店，购买商品，则会形成被同店导购B抢客的情况，如不在有效客户关系内购买，导购员无法获得提成。 4.商家如何管理业绩？ （1）导购等级实时升降，不再与提成结算时间一致，而是在订单交易后即提升相应的业绩，相应的订单发生退款时，也会减少业绩。 （2）「营销中心」-「导购分销」中分销的佣金结算能力已支持自动结算给导购分销员。 （3）如有线下结算需要，后台支持导购业绩批量导出，方便对账。 更多导购分销疑问，请点击链接查看 https://developers.weixin.qq.com/community/business/doc/000cc6f0030558c19f2be29365100d （六）店铺直播 1.怎么开通直播功能？ 成功开通的小商店（企业/个体店）自带直播能力，商家只需同时满足已开张、且商品库中有成功发布的商品，后台的直播页面将会自动开通直播功能，商家点击管理直播跳转到直播管理后台，可创建直播间、指定主播、设定直播开播时间。 Tips：建议商家在直播间选货之前，先在小商店上传好商品，直播间选品时会自动同步小商店已经上传并且发布成功的商品，提高直播的效率。 2.怎么让用户看到商家直播？ 商家可直接以直播间小程序码的形式进行分享，也可以把商家的小商店主动分享给用户，凡是设定了直播的商家，小商店主页都会看到直播入口，用户点击可进入直播间观看或订阅直播。 在直播将开始时，直播间会自动给预约的用户发消息提醒，为商户提供定时召回用户的功能。直播间还会完整展示主播推荐的商品、讲解和抽奖能力，并设有直播浮窗的功能，保证用户边看边买的流畅体验。 3.店铺直播与视频号直播的区别？ （1）店铺直播是小商店自带的微信小程序直播，帮助商家在自有小程序（小商店）中实现直播互动与商品销售闭环，提高转化率。店铺直播优势为低门槛、快运营，一键分享、一键订阅。 更多小程序直播信息可查看以下链接：https://developers.weixin.qq.com/community/business/doc/000e28dbfd8a8082282a60d6f5b80d （2）视频号直播作为视频号的重要能力之一，现已与微信小商店打通，商家或导购可以在直播时添加在架商品，进行引流、带货。视频号优势在于可以快速突破熟人圈，拓展更广阔的私域流量。 （七）视频号 1.视频号怎么关联小商店？ 视频号关联/取消关联小商店的具体步骤请查看下方链接： https://developers.weixin.qq.com/community/business/doc/000ce0f5014a186f871bf21b459c0d?page=2#comment-list 2.视频号直播怎么带货？ 视频号直播可支持带货小商店在架商品，视频号关联小商店后，即可在视频号添加带货商品，具体步骤请查看以下链接： https://developers.weixin.qq.com/community/business/doc/000ce8f5688b4873a72b2d6c15ac0d （八）后续营销能力规划 小商店是一种卖货小程序，未来，用户可以从下方图片中展示的场景，比如任务栏、会话框、扫码、搜索、分享等进入小商店。小商店将持续与微信生态的场景实现更紧密地结合，为商家提供更多连接用户的方式。 七、服务提升 1.运费险（卖家版）保障什么？保障周期是多久？ 运费险是帮助买家适当减少退换货运费损失的一种服务，卖家为买家购买运费险，当买家退换货的时候，保险公司会向用户赔偿部分运费。 运费险从卖家发货开始生效，到买家确认收货/到期系统自动确认收货为止，总时长不超过90天。 2.如果同一笔订单，发生多次退换货行为，商家需要多次投保吗？ 一笔订单对应一笔运费险，因此商家只需购买一次运费险。 3.运费险理赔金额标准怎么定？ 理赔金额是根据用户的收货地址和商家在系统里预留的退货地址的距离进行首公斤价格赔付的，具体以实际赔付金额为准。 更多运费险疑问，请点击查看 https://developers.weixin.qq.com/community/business/doc/0006a651408b80b12dda778cd5180d 八、订单物流 1.订单是否支持改价？ 商家可修改「待付款订单」的价格（目前仅支持调低价格）、减免运费。 用户拍下商品但未付款前，商家可以在订单管理中找到对应订单并修改订单价格（可直接输入修改后的价格或折扣，系统会自动计算）及选择是否减免运费，设置完成后点击确定； 用户微信上会收到订单价格已修改的服务通知，点击后可按修改后的价格进行付款； 2.如何确定收货？ 目前统一的确认收货规则为：用户可手动对订单确认收货，若不手动确认收货，在商家发货15天后系统将自动确认收货。若订单中有商品发生了退款/售后，订单自动确认收货的倒计时将停止。 3.小商店支持的物流方式有哪些？ 目前仅支持快递物流配送，上门自提、同城配送、无需物流模板正在开发中，敬请期待。 4.商家快递单号填写错误后，是否影响正常收货流程？ 只要快递顺利到达买家手中，就不会影响正常收货。修改物流单号的功能正在开发中，敬请期待。 九、怎么结算 1.小商店结算账户是什么？ 开通小商店，将自动开通一个全新的微信支付商户号。该商户号暂时不支持更换。商家可以直接在小商店后台进行经营对账，客户的每一笔货款都会直接到达商家自己的微信支付商户号账号中。 2.什么时候可以提现？ 到账的款项无特殊情况均为待结算状态，商家将在客户确认收货后，可对该笔款项进行提现至银行账户操作。 3.收款提现多长时间到账？ 收款提现后，无特殊情况下，24h内到账。 4.收款可以提现到私人账户吗？ 如果是企业，会自动提现至对公账户，不支持提现到私人账户； 如果是个体工商户，可以选择对公或者对私账户； 个人主体的直接结算到绑定的对私银行账户。 5.小商店的结算费率0.6%指的是？ 微信支付收取每笔订单实际销售金额的千分之六； 小商店不收取手续费，免费开店、免费提现至银行账户。 十、客服 1.商家客服添加多名客服后，是否只有开通小商店的微信收到顾客咨询信息？ 添加多名客服后，只要绑定客服帐号的微信都可以收到顾客的资讯信息。 2.商家客服可以手机接收到消息吗？ 企业/个体店，在小商店后台-客服与售后模块中，点击添加，可以绑定客服帐号，绑定后，扫描下方二维码，即可在移动端小程序客服进行客服沟通。 客服消息指南如下：https://developers.weixin.qq.com/miniprogram/introduction/custom.html#网页版客服工具 [图片] 十一、服务商 1.小商店支持服务商吗？ 毋庸置疑，我们需要服务商一起参与，小商店将开放店铺、商品、订单、物流、客服等一系列API接口供第三方介入，完善小商店能力。未来，小商店会开放接入ERP/CRM、智能客服、店铺装修、营销等经营工具，和第三方合作伙伴共同帮助商家经营成长。 2.小商店开放接口在哪里？ 微信官方文档-小商店板块中，已上线小商店开放组件介绍，请点击查看：https://developers.weixin.qq.com/doc/ministore/minishopopencomponent/Introduction.html

[图片] message：Error: 无插件开发资质,plugin not init [20220114 14:04:05][wx20a0b86282fc9c3c] appid: wx20a0b86282fc9c3c openid: o6zAJs8aYBMB0g1mIMEPQYdgchUY

内含开店指引、店铺运营和平台规则，帮你快速掌握小商店经营秘诀。

之前的插件类目没有了导致搜不到了，重新发个文章。 image-cropper 一款高性能的小程序图片裁剪插件，支持旋转。 [图片] 优势 [代码]1.功能强大。[代码] [代码]2.性能超高超流畅，大图毫无卡顿感。[代码] [代码]3.组件化，使用简单。[代码] [代码]4.点击中间窗口实时查看裁剪结果。[代码] ㅤ 初始准备 1.json文件中添加image-cropper [代码] "usingComponents": { "image-cropper": "../image-cropper/image-cropper" }, "navigationBarTitleText": "裁剪图片", "disableScroll": true [代码] 2.wxml文件 [代码]<image-cropper id="image-cropper" limit_move="{{true}}" disable_rotate="{{true}}" width="{{width}}" height="{{height}}" imgSrc="{{src}}" bindload="cropperload" bindimageload="loadimage" bindtapcut="clickcut"></image-cropper> [代码] 3.简单示例 [代码] Page({ data: { src:'', width:250,//宽度 height: 250,//高度 }, onLoad: function (options) { //获取到image-cropper实例 this.cropper = this.selectComponent("#image-cropper"); //开始裁剪 this.setData({ src:"https://raw.githubusercontent.com/1977474741/image-cropper/dev/image/code.jpg", }); wx.showLoading({ title: '加载中' }) }, cropperload(e){ console.log("cropper初始化完成"); }, loadimage(e){ console.log("图片加载完成",e.detail); wx.hideLoading(); //重置图片角度、缩放、位置 this.cropper.imgReset(); }, clickcut(e) { console.log(e.detail); //点击裁剪框阅览图片 wx.previewImage({ current: e.detail.url, // 当前显示图片的http链接 urls: [e.detail.url] // 需要预览的图片http链接列表 }) }, }) [代码] 参数说明 属性 类型 缺省值 取值 描述 必填 imgSrc String 无 无限制 图片地址(如果是网络图片需配置安全域名) 否 disable_rotate Boolean false true/false 禁止用户旋转(为false时建议同时设置limit_move为false) 否 limit_move Boolean false true/false 限制图片移动范围(裁剪框始终在图片内)(为true时建议同时设置disable_rotate为true) 否 width Number 200 超过屏幕宽度自动转为屏幕宽度 裁剪框宽度 否 height Number 200 超过屏幕高度自动转为屏幕高度 裁剪框高度 否 max_width Number 300 裁剪框最大宽度 裁剪框最大宽度 否 max_height Number 300 裁剪框最大高度 裁剪框最大高度 否 min_width Number 100 裁剪框最小宽度 裁剪框最小宽度 否 min_height Number 100 裁剪框最小高度 裁剪框最小高度 否 disable_width Boolean false true/false 锁定裁剪框宽度 否 disable_height Boolean false true/false 锁定裁剪框高度 否 disable_ratio Boolean false true/false 锁定裁剪框比例 否 export_scale Number 3 无限制 输出图片的比例(相对于裁剪框尺寸) 否 quality Number 1 0-1 生成的图片质量 否 cut_top Number 居中 始终在屏幕内 裁剪框上边距 否 cut_left Number 居中 始终在屏幕内 裁剪框左边距 否 [代码]img_width[代码] Number 宽高都不设置，最小边填满裁剪框 支持%(不加单位为px)(只设置宽度，高度自适应) 图片宽度 否 [代码]img_height[代码] Number 宽高都不设置，最小边填满裁剪框 支持%(不加单位为px)(只设置高度，宽度自适应) 图片高度 否 scale Number 1 无限制 图片的缩放比 否 angle Number 0 (limit_move=true时angle=n*90) 图片的旋转角度 否 min_scale Number 0.5 无限制 图片的最小缩放比 否 max_scale Number 2 无限制 图片的最大缩放比 否 bindload Function null 函数名称 cropper初始化完成 否 bindimageload Function null 函数名称 图片加载完成,返回值Object{width,height,path,type等} 否 bindtapcut Function null 函数名称 点击中间裁剪框,返回值Object{src,width,height} 否 函数说明 函数名 参数 返回值 描述 参数必填 upload 无 无 调起wx上传图片接口并开始剪裁 否 pushImg src 无 放入图片开始裁剪 是 getImg Function(回调函数) [代码]Object{url,width,height}[代码] 裁剪并获取图片(图片尺寸 = 图片宽高 * export_scale) 是 setCutXY X、Y 无 设置裁剪框位置 是 setCutSize width、height 无 设置裁剪框大小 是 setCutCenter 无 无 设置裁剪框居中 否 setScale scale 无 设置图片缩放比例（不受min_scale、max_scale影响） 是 setAngle deg 无 设置图片旋转角度（带过渡效果） 是 setTransform {x,y,angle,scale,cutX,cutY} 无 图片在原有基础上的变化(scale受min_scale、max_scale影响) 根据需要传参 imgReset 无 无 重置图片的角度、缩放、位置(可以在onloadImage回调里使用) 否 GitHub https://github.com/wx-plugin/image-cropper/tree/master 如果有什么好的建议欢迎提issues或者提pr

近期，我们在与多家项目外包开发团队的沟通交流中，发现有几个问题经常被问到，比如：类似知晓云这样的 Serverless 云服务适用于什么场景？已有后端团队还需要用 Serverless 吗？爱范儿的项目也用知晓云吗，能应对百万级流量的冲击吗？为此，我们对部分问题进行统一的解答。如果你还有其他疑问，可以随时提出。 🎉「知晓云开发者联盟」空间正式上线，下拉到文末，扫码进入小程序，即可参与首期福利活动。 Serverless 云服务的十问十答 1. Serverless 是什么？ Serverless（无服务器架构）包含了两个领域 BaaS（Backend as a Service）和 FaaS（Function as a Service）。BaaS 为后端即服务，通过应用程序编程接口（API）和软件开发人员工具包（SDK）连接应用和后端系统的新模型，包括数据库、文件存储、运营分析、消息推送等。FaaS 为函数即服务，开发者可以直接将服务业务逻辑代码部署、运行在第三方提供的无状态计算容器中，只需要编写业务代码即可，无需关注服务器，并且代码的执行由事件触发。 2. Serverless 适用于什么场景？ 通过事件触发场景（例如：抽奖活动）；有业务访问高峰和低谷的场景（例如：点餐、购票、节日活动）；需要快速打通多个平台，迭代次数较多的场景（例如：电商）；注重成本、效率问题的场景（例如：创业项目）。 3. Serverless 能否帮我打造小而美的技术团队吗？ 能。Serverless 可以更好的解决企业在服务器搭建、域名备案、线上运维等繁琐的事情，因此可以节省大量的人力配备，满足小团队的创建需求。还可以帮助团队快速响应业务需求，交付安全可靠的应用，满足优质团队的创建需求。 4. 公司已有后端开发工程师，为什么还要使用云服务？ Serverless 云服务并不会取代后端开发工程师，企业在不确定业务、产品、活动是否能带来回报和收益时，需要以更低的成本、更短的时间来进行试验和探索，此时，云服务正好可以满足企业的需求。 5. 类似知晓云的云服务，团队学习成本是否很高？ 不会。云服务的目的在于降低门槛，学习成本并不会高。在使用知晓云之前，开发者需要对 JavaScript 有一定的基础。我们针对每一个产品提供了完整的开发文档，同时还基于简单的 demo 进行实战演练，你只需要掌握「知晓云控制台、JS SDK、云函数、运营后台 API」几个模块的内容，基本可以上手并完成应用开发。 6. Serverless 是否可以应对具有周期性的大流量？ 在面对具有周期性业务场景和活动时，可能流量会集中在某一时间段，使用 Serverless 云服务，可以轻松应对大流量，并且可自动扩容或缩容以确保服务不会中断，也能在业务/活动闲时不造成资源浪费。 7. 使用第三方云服务，数据安全如何保障？ 使用 4096 位 RSA 密钥交换以及至少 128 位的强加密算法，提供安全可靠的数据存储及传输，保证数据安全。 8. 爱范儿哪些项目使用了知晓云云服务？ 知晓云不仅服务于数十万的开发者，同时也服务于爱范儿品牌下的项目以及政企合作伙伴。如糖纸社区小程序、好物商店小程序，粤工惠活动小程序。基于高效和弹性扩容的特点，满足了粤工惠一月一活动（小程序）的高频开发需求，也轻松应对周期性大流量的冲击。 9. 云服务按量收费，在资源用量以及费用上如何把控？ 知晓云提供了不同量级的版本套餐，你可以根据实际用量情况选择对应的套餐版本，当应用使用资源量超过版本套餐，会进行超额部分的计算和收费，不会对应用的正常使用产生影响。企业也可随着业务的发展选择不同的版本套餐，当业务量较低时，也能降低版本以降低运营成本。 10. 多平台的项目可否一起接入到知晓云，如何操作？ 可以。在同一个知晓云应用下，授权多个平台的应用（如小程序、App、Web），此时多平台共用同一个数据表和功能配置，在此基础上还能实现全平台数据统一、消息推送等。详见知晓云开发文档>> 🎉「知晓云开发者联盟」小程序社区上线啦～ 该社区是基于糖纸小程序的群空间功能所创建，用于发布行业资讯、组织大小活动，满足广大开发者交流互助的需求。即刻订阅「知晓云开发者联盟」空间，你将可第一时间获得社区动态。 当然，福利活动同步上线～ 🎁好书推荐有礼： 12 月 2 日 - 12 月 8 日，在社区中发布一条与工作相关的书籍推荐的动态，我们将结合书籍内容和动态点赞数，选择一本书作为礼品。在所有有效动态中，点赞数最高的发布者，可获得该本书，而推荐者也能获得知晓云的纪念 T 恤一件。 参与方式： 微信扫描下方小程序，进入「知晓云开发者联盟」社区 点击小程序右下方「+」按钮，发布动态 动态内容包含书名和推荐理由；动态标签选择「好书推荐」 邀请好友点赞或参与好书分享 [图片]

摘要： 对比小程序框架。 原文：小程序第三方框架对比 ( wepy / mpvue / taro ) 公众号：前端小苑 Fundebug经授权转载，版权归原作者所有。 [图片] 众所周知如今市面上端的形态多种多样，手机Web、ReactNative、微信小程序, 支付宝小程序, 快应用等,每一端都是巨大的流量入口，当业务要求同时在不同的端都要求有所表现的时候，针对不同的端去编写多套代码的成本显然非常高，这时候只编写一套代码就能够适配到多端的能力就显得极为需要。但面对目前市面上成熟的小程序第三方框架如何针对自己的需求进行选择也是一个麻烦事,本文针对当前市面上的三大转译框架进行一个综合对比,希望能对大家的技术选择有所帮助,如有哪里不妥的地方希望大家指正。 小程序开发有哪些痛点? 频繁调用 setData及 setData过程中页面跳闪 组件化支持能力太弱(几乎没有) 不能使用 less、scss 等预编译器 request 并发次数限制 为什么使用第三方框架? 只要熟悉vue或react即可快速上手,学习成本低 一套代码可在多端编译运行(微信,支付宝,h5,RN) 支付宝小程序暂不完善 组件化开发，完美解决组件隔离，组件嵌套，组件通信等问题 支持使用第三方 npm 资源 使小程序可支持 Promise，解决回调烦恼 可使用 Generator Function / Class / Async Function 等特性，提升开发效率 对小程序本身的优化，如生命周期的补充，性能的优化等等 支持样式编译器: Scss/Less，模板编译器，代码编译器：Babel/Typescript。 小程序框架对比：WePY / mpvue / Taro 在这里我通过对目前已开源的三种常用小程序框架做一个综合对比, 还有一个叫nanchi的基于react的小程序转译框架,由于没来的及研究暂不做比较。 WePY 腾讯团队开源的一款类vue语法规范的小程序框架,借鉴了Vue的语法风格和功能特性,支持了Vue的诸多特征，比如父子组件、组件之间的通信、computed计算属性、wathcer监听器、props传值、slot槽分发，Mixin混入等。WePY发布的第一个版本是2016年12月份，也就是小程序刚刚推出的时候，到目前为止，WePY已经发布了52个版本, 最新版本为1.7.2; mpvue 美团团队开源的一款使用 Vue.js 开发微信小程序的前端框架。使用此框架，开发者将得到完整的 Vue.js 开发体验，同时为 H5 和小程序提供了代码复用的能力。mpvue在发布后的几天间获得2.7k的star,上升速度飞起,截至目前为止已经有13.7k的star; Taro 京东凹凸实验室开源的一款使用 React.js 开发微信小程序的前端框架。它采用与 React 一致的组件化思想，组件生命周期与 React 保持一致，同时支持使用 JSX 语法，让代码具有更丰富的表现力，使用 Taro 进行开发可以获得和 React 一致的开发体验,同时因为使用了react的原因所以除了能编译h5, 小程序外还可以编译为ReactNative; [图片] [图片] 生命周期 同为vue规范的mpvue和wepy的生命周期和各种方法不尽相同。 WePY wepy生命周期基本与原生小程序相同,再此基础上糅合了一些vue的特性; 对于WePY中的methods属性，因为与Vue中的使用习惯不一致，非常容易造成误解，这里需要特别强调一下：WePY中的methods属性只能声明页面wxml标签的bind、catch事件，不能声明自定义方法，这与Vue中的用法是不一致的。 [图片] [图片] 简单示例Taro与React生命周期完全相同 [图片] 列表渲染 在列表渲染上三者也分别有不同的应用方法 wepy当需要循环渲染WePY组件时(类似于通过wx:for循环渲染原生的wxml标签)，必须使用wepy定义的辅助标签。 [图片] mpvue使用v-for与vue一致,只是需要注意一点，嵌套列表渲染，必须指定不同的索引！ [图片] taro的列表循环用法基本与react相同,有一点需要注意,在 React 中，JSX 是会编译成普通的 JS 的执行，每一个 JSX 元素，其实会通过 createElement 函数创建成一个 JavaScript 对象（React Element），因此实际上你可以这样写代码 React 也是完全能渲染的： [图片] 但是 Taro 中，JSX 会编译成微信小程序模板字符串，因此你不能把 map 函数生成的模板当做一个数组来处理。当你需要这么做时，应该先处理需要循环的数组，再用处理好的数组来调用 map 函数。例如上例应该写成： [图片] 事件处理 mpvue目前全支持小程序的事件处理器,引入了 Vue.js 的虚拟 DOM ，在前文模版中绑定的事件会被挂在到 vnode 上，同时 compiler 在 wxml 上绑定了小程序的事件，并做了相应的映射，所以在真实点击的时候通过 runtime 中 handleProxy 事件类型分发到 vnode 的事件上，同 Vue 在 WEB 的机制一样，可以做到无损支持。同时还顺便支持了自定义事件和 $emit 机制。 事件映射表，左侧为 WEB 事件，右侧为 小程序 对应事件 [图片] 踩坑注意(官方文档)： 列表中没有的原生事件也可以使用例如 bindregionchange 事件直接在 dom 上将bind改为@ @regionchange,同时这个事件也非常特殊，它的 event type 有 begin 和 end 两个，导致我们无法在handleProxy 中区分到底是什么事件，所以你在监听此类事件的时候同时监听事件名和事件类型既 <map @regionchange=“functionName” @end=“functionName” @begin=“functionName”> 小程序能力所致，bind 和 catch 事件同时绑定时候，只会触发 bind ,catch 不会被触发，要避免踩坑 事件修饰符 .stop 的使用会阻止冒泡，但是同时绑定了一个非冒泡事件，会导致该元素上的 catchEventName 失效！ .prevent 可以直接干掉，因为小程序里没有什么默认事件，比如submit并不会跳转页面 .capture 支持 1.0.9 .self 没有可以判断的标识 .once也不能做，因为小程序没有 removeEventListener, 虽然可以直接在 handleProxy 中处理，但非常的不优雅，违背了原意，暂不考虑 其他 键值修饰符 等在小程序中压根没键盘，所以… wepy事件绑定区别于vue,根据原生小程序事件提供了语法优化 [图片] Taro 元素的事件处理和 DOM 元素的很相似。但是有一点语法上的不同: Taro 事件绑定属性的命名采用驼峰式写法，而不是小写。 如果采用 JSX 的语法你需要传入一个函数作为事件处理函数，而不是一个字符串 (DOM 元素的写法)。 例如，传统的微信****小程序模板： [图片] Taro 中稍稍有点不同： [图片] 在 Taro 中另一个不同是你不能使用 catchEvent 的方式阻止事件冒泡。你必须明确的使用 stopPropagation。例如，阻止事件冒泡你可以这样写： [图片] request请求 wepy对wx.request做了接受参数的修改,值得一提的是它提供了针对全局的intercapter拦截器。 [图片] 拦截器 [图片] taro对request进行了二次封装,可以使用Taro.request(OBJECT)发起网络请求，支持 Promise 化使用。 [图片] [图片] [图片] mpvue没有对request做特殊优化,与原生相同,可以自己根据需要进行封装 状态管理 wepy 可引用Redux和Mbox,目前wepy的脚手架内已经集成了redux,选择需要即可; mpVue使用vuex; taro使用Redux; 如何选择适合自己的项目 如果只需要做一个微信小程序则根据自己的擅长框架选择mpvue或taro 如果是当前老项目想像向程序迁移同时老项目又是使用vue开发,建议使用mpvue或wepy 如果是老项目使用react开发且需要部分迁移小程序,建议使用taro 如果是新项目且新项目需要同时支持微信小程序和支付宝小程序, 建议使用原生开发,因为目前框架的转译支付宝小程序支持并不是很好,且出了问题不好定位修改, 但如果是小demo不涉及太多逻辑的项目都可以使用框架作为尝鲜; 但如果是涉及太多交互逻辑的则不建议使用框架转译,由于支付宝小程序在视图层基本与小程序一致所以建议手动更改替换部分方法和全局替换一些属性或文件名,如wxml替换为axml这种, 手动转换时间比大概是四比一; 当然如果人手足够一端开发一个是最好的… 时刻前端新鲜技术推送,定期前端精品文章分享，欢迎关注公众号前端小苑。

Kbone原理解析 官方介绍 “Kbone 是一个致力于微信小程序和 Web 端同构的解决方案。” Web端框架基本原理 首先我们来看下普通Web端框架，以Vue框架为例，一份Vue模板对应一个组件，在代码构建阶段编译成调用Dom接口的JS函数，执行此JS函数就会创建出组件对应的Dom树，从而渲染到浏览器页面上。 [图片] 然而，小程序是双线程的，并没有Dom树的概念，逻辑层和视图层完全分离，逻辑层是一个纯粹的JSCore,开发者可以编写JS脚本，但是无法直接调用Dom/Bom的api, 没有任何浏览器相关的实现。 在小程序中，视图层和逻辑层的交互是通过数据和时间驱动的。 因此，要实现跨端同构，问题是：怎么将web端代码转为小程序代码？ 业界常规做法 目前业界流行的第三方跨端框架们，常规做法都是：静态编译兼容。 [图片] 原理是把代码语法分析一遍，然后将其中的模板部分翻译成对应的跨端需求的模板（微信小程序、支付宝小程序、H5、APP等）。 静态编译最大的局限性是无法保证转换的完整性，因为Vue模板和WXML模板的语法并不是直接对等的，Vue的特性设计也和小程序的设计无法划等号，这自然就导致了部分Vue特性的丢失。 比如像Vue中的v-html指令、ref获取Dom节点、过滤器等就通通用不了。 除了Vue自身的特性外，一些原本依赖Dom/Bom接口的Vue插件页无法使用，例如Vue-Router。 Kbone的做法 Kbone是通过提供 适配器 的方式来实现同构，即运行时兼容，而非静态编译。 Kbone的适配器核心包含两个部分： miniprogram-render： 仿造Dom/Bom接口，构造仿造Dom树； miniprogram-element: 监听仿造Dom树变化，渲染到页面，同时监听用户行为，触发事件。 仿造Dom树和浏览器的运行时对比： 仿造Dom树： 利用内置组件和自定义组件的自引用来进行递归，创建组件树。 如图，自定义custom-dom为递归自引用组件： [图片] 递归的终止条件是遇到特定节点、文本节点或者children空节点。 在创建出组件树后，将Dom节点和自定义组件实例进行绑定，以便后续的Dom更新和操作。 [图片] kbone这里还对节点数进行了优化： 如果一个dom节点对应一个自定义组件的话，就会创建很多自定义组件，这样会很浪费开销，这里做了子树的合并，也就是说3层才创建一个自定义组件，节省开销。 优化前：17个dom=17个自定义组件； 优化后：17个dom=4个自定义组件，蓝色那个是单节点，会合并到上面的树； [图片] dom 子树作为自定义组件渲染的层级数是可以通过配置传入，理论上层级越多，使用自定义组件数量越少，性能也就越好。 一棵很大的 Dom 树，一次性 setData 到视图层，可能会超过 setData 的大小限制（1024kB），拆分成多棵子 Dom 树，然后分批的 setData 到视图层，可以节省开销。 事件监听 小程序的事件是视图层到逻辑层的通讯方式，事件绑定在组件上，当被触发时，就会执行逻辑层中对应的事件处理函数。 小程序的捕获冒泡是在视图层view端，因此逻辑层在整个捕获冒泡流程中各个节点接收到的事件不是同一个对象，小程序事件的捕获冒泡和阻止冒泡等操作必须在WXML模板中生命，无法使用接口实现。 [图片] 为了能够让web端和小程序端的事件系统行为一致，kbone除了仿造了一份Dom树外，也把整个事件系统仿造了一份，即在仿造Dom树上进行捕获冒泡。 当自定义组件监听到用户的操作后，就将事件发往仿造Dom树，后续自定义组件监听到的同一个事件的冒泡就直接忽略。 当触发改节点，仿造Dom树接收到事件后，再进行捕获和冒泡，让事件在各个节点触发。 [图片] Kbone的优势 支持多个前端框架：Vue、React、Preact 等 支持更为完整的前端框架特性： Vue 中的 v-html 指令、Vue-router 插件等 提供了常用的 dom/bom 接口 可以使用小程序本身的特性： live-player 内置组件、分包功能等 提供一些 Dom 扩展接口：getComputedStyle 接口等 Kbone实践 脚手架kbone-cli 官方已经提供了kbone-cli可以用来快速开发： 用npm全局安装kbone-cli [图片] 可以根据自己的技术栈选择不同的开发模板：React/Vue/Omi/Preact [图片] 然后就可以愉快的进行开发啦~ [图片] 生成的demo项目结构如下： [图片] demo中包含了多页跳转、vue-router、vuex等的使用示例，以及mp-webpack-plugin的配置示例。 对于多页面的应用，在 Web 端可以直接通过 a 标签或者 location 对象进行跳转，但是在小程序中则行不通。同时 Web 端的页面 url 实现和小程序页面路由也是完全不一样的。 Demo示例对比 [图片] 其中，有一部分两端差异的业务逻辑功能，也给出了3中不同的解决方案： 利用vue-improve-loader，在构建时对dom树节点进行删减，在需要提出的节点加上check-reduce属性 利用reduce-loader，将业务中不需要被打包的代码进行去除，使用行内loader和环境变量来判断 使用样式隐藏，即设置不需要显示的节点样式为 display:none 其他问题 在实际开发中，还会碰到一些细节，例如： 多页面开发：修改webpack和mp-webpack-plugin配置 小程序内置组件： 部分用html标签代替，其他用wx-component + behavior标签 小程序自定义组件：修改mp-webpack-plugin配置，补充wxCustomComponents字段，将自定义组件放入组件根目录，使用自定义组件 自定义app.js和app.wxss：监听app的生命周期，修改webpack配置补充app.js的构建入口，修改插件配置的generate.app字段，补充app.js 扩展dom/bom对象和API：使用 window.$$extend追加方法 代码优化：用reduce-loader做体积精简，dom树精简用vue-improve-loader 区分环境实现不同功能：process.env.isMiniprogram 更新迭代 kbone由于目前在快速发展期，更新迭代非常迅速，以下特性是对比了8月份的版本和11月份版本，可以看出已经解决了近2/3的问题。 [图片] 小程序技术选型 详细了解了kbone之后，我们来分析下小程序技术框架到底应该怎么选？ kbone & 小程序原生 已有web版，需要小程序版：kbone 跨平台需求（web + 小程序）：kbone 对性能特别苛刻 or 追求稳定 or 要用最新功能：小程序原生 页面节点数量特别多（ 1000 节点以上），且对渲染性能要求高：静态模板转义方案（第三方框架：mpvue/taro等） 第三方框架 MpVue ：不推荐再用了，坑越来越多，内部也表示之后不会投入太多维护 WePY 1.7.x ：不推荐再用了：1.7.x 的版本在最初的设计上的缺陷导致遗留了很多比较严重的问题 WePY 2.0：现在还是 alpha 阶段，内外部有一些小程序在跑，体验和反馈还可以。但依然 issue 比较多。害怕踩坑的也不推荐使用 Taro:  也还是有不少问题，但相对来说应该是比 mpVue 和 WePY 更稳定一点 Uni-app：mpvue的衍生版，跨端 (官方示例有6端) 支持的很好，在H5端实现了一套微信模拟器，可以尝试，是目前唯一支持app端的商用方案，有独立的编辑器HBuildX Chameleon: 统一的多态协议，渐进式跨端，提供脚手架命令工具，规划比较宏大 Omi ：基于Taro完成的框架，kbone有支持omi的模板 Nanachi: 基于react的编译期间的转义框架 总结 没有跨端需求，只需要微信小程序 ==> 小程序原生 web端转小程序 or 两端 or 想要尝鲜 ==>  kbone 多端 or Vue 技术栈 ==>  uni-app 多端 or React 技术栈 ==>  taro 不介意学习新技术栈 ==>  wepy 2.0  or chaemeleon 写在最后 小程序在非常快速的更新迭代，就算是原生框架也还是有一些坑的，因此没有哪种框架是百分之百完美，需要根据业务具体需求以及自身技术栈偏好来进行选择。 文章中提及到的部分第三方框架只是参考了官方文档，没有逐个一一尝试，有问题麻烦指出，鞠躬~~ [图片]

作者：coldsnap 原文：小程序多端框架全面测评 Fundebug经授权转载，版权归原作者所有。 最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？ 作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。 那么，当我们在讨论多端框架时，我们在谈论什么： 多端 笔者以为，现在流行的多端框架可以大致分为三类： 1. 全包型 这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。 这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。 2. Web 技术型 这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有： 开发迅速 复用前端生态 易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS 缺点有： 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 [代码]JS[代码] 和 [代码]Native[代码] 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。 3. JavaScript 编译型 这类框架就是我们这篇文章的主角们：[代码]Taro[代码]、[代码]WePY[代码] 、[代码]uni-app[代码] 、 [代码]mpvue[代码] 、 [代码]chameleon[代码]，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架，以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。 这类框架最大优点和创造的最大原因就是小程序，因为第一第二种框架其实除了可以跨系统平台之外，也都能编译运行在浏览器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 [代码]react-native-web[代码], Weex 原生支持) 另外一个优点是在移动端一般会编译到 React Native/Weex，所以它们也都拥有 Web 技术型框架的优点。这看起来很美好，但实际上 React Native/Weex 的缺点编译型框架也无法避免。除此之外，编译型框架的抽象也不是免费的：当 bug 出现时，问题的根源可能出在运行时、编译时、组件库以及三者依赖的库等等各个方面。在 Taro 开源的过程中，我们就遇到过 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，当然也少不了 Taro 本身的 bug。相信其它原理相同的框架也无法避免这一问题。 但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。 那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。 如果不管什么 DSL 都能接受，那就可以进入下一个环节： 生态 以下内容均以各框架现在（2019 年 3 月 11 日）已发布稳定版为标准进行讨论。 1. 开发工具 就开发工具而言 [代码]uni-app[代码] 应该是一骑绝尘，它的文档内容最为翔实丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。 其它的框架都是使用 CLI 命令行工具，但值得注意的是 [代码]chameleon[代码] 有独立的语法检查工具，[代码]Taro[代码] 则单独写了 ESLint 规则和规则集。 在语法支持方面，[代码]mpvue[代码]、[代码]uni-app[代码]、[代码]Taro[代码] 、[代码]WePY[代码] 均支持 TypeScript，四者也都能通过 [代码]typing[代码] 实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对于 JSX 的良好支持，Taro 也能对组件进行自动补全。 CSS 方面，所有框架均支持 [代码]SASS[代码]、[代码]LESS[代码]、[代码]Stylus[代码]，Taro 则多一个 [代码]CSS Modules[代码] 的支持。 所以这一轮比拼的结果应该是： uni-app > Taro > chameleon > WePY、mpvue [图片] 2. 多端支持度 只从支持端的数量来看，[代码]Taro[代码] 和 [代码]uni-app[代码] 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），[代码]chameleon[代码] 少了头条小程序紧随其后。 但值得一提的是 [代码]chameleon[代码] 有一套自研多态协议，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能。[代码]uni-app[代码] 则有一套独立的条件编译语法，这套语法能同时作用于 [代码]js[代码]、样式和模板文件。[代码]Taro[代码] 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似 React Native 的方式）。 在移动端方面，[代码]uni-app[代码] 基于 [代码]weex[代码] 定制了一套 [代码]nvue[代码] 方案 弥补 [代码]weex[代码] API 的不足；[代码]Taro[代码]则是暂时基于 [代码]expo[代码] 达到同样的效果；[代码]chameleon[代码] 在移动端则有一套 SDK 配合多端协议与原生语言通信。 H5 方面，[代码]chameleon[代码] 同样是由多态协议实现支持，[代码]uni-app[代码] 和 [代码]Taro[代码] 则是都在 H5 实现了一套兼容的组件库和 API。 [代码]mpvue[代码] 和 [代码]WePY[代码] 都提供了转换各端小程序的功能，但都没有 h5 和移动端的支持。 所以最后一轮对比的结果是： chameleon > Taro、uni-app > mpvue > WePY [图片] 3. 组件库/工具库/demo 作为开源时间最长的框架，[代码]WePY[代码] 不管从 Demo，组件库数量 ，工具库来看都占有一定优势。 [代码]uni-app[代码] 则有自己的插件市场和 UI 库，如果算上收费的框架和插件比起 [代码]WePy[代码] 也是完全不遑多让的。 [代码]Taro[代码] 也有官方维护的跨端 UI 库 [代码]taro-ui[代码] ，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 demo 的数量不如前两个。但 [代码]Taro[代码] 有一个转换微信小程序代码为 Taro 代码的工具，可以弥补这一问题。 而 [代码]mpvue[代码] 没有官方维护的 UI 库，[代码]chameleon[代码] 第三方的 demo 和工具库也还基本没有。 所以这轮的排序是： WePY > uni-app 、taro > mpvue > chameleon [图片] 4. 接入成本 接入成本有两个方面： 第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 [代码]wxparse[代码]、[代码]echart[代码]、[代码]zan-ui[代码] 等）多是基于原生微信小程序框架语法写成的。目前看来 [代码]uni-app[代码] 、[代码]Taro[代码]、[代码]mpvue[代码] 均有文档或 demo 在框架中直接使用原生小程序组件/库，[代码]WePY[代码] 由于运行机制的问题，很多情况需要小改一下目标库的源码，[代码]chameleon[代码] 则是提供了一个按步骤大改目标库源码的迁移方式。 第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。 而对于两种接入方式 Taro 都提供了 [代码]taro convert[代码] 功能，既可以将原有微信小程序项目转换为 Taro 多端代码，也可以将微信小程序生态的组件转换为 Taro 组件。 所以这轮的排序是： Taro > mpvue 、 uni-app > WePY > chameleon 流行度 从 GitHub 的 star 来看，[代码]mpvue[代码] 、[代码]Taro[代码]、[代码]WePY[代码] 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。 [代码]uni-app[代码] 则号称有上万案例，但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是 [代码]uni-app[代码] 领先，它拥有 20+ 个 QQ 交流群（最大人数 2000）。 所以从流行程度来看应该是： uni-app > Taro、WePY、mpvue > chameleon [图片] 5. 开源建设 一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。 从第三方贡献者数量来看，[代码]Taro[代码] 在这一方面领先，并且 [代码]Taro[代码] 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的 [代码]omi[代码] 框架小程序部分也是基于 Taro 完成的。 [代码]WePY[代码] 在腾讯开源计划的加持下在这一方面也有不错的表现；[代码]mpvue[代码] 由于停滞开发了很久就比较落后了；可能是产品策略的原因，[代码]uni-app[代码] 在开源建设上并不热心，甚至有些部分代码都没有开源；[代码]chameleon[代码] 刚刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现。 那么这一轮的对比结果是： Taro > WePY > mpvue > chameleon > uni-app 最后补一个总的生态对比图表： [图片] 未来 从各框架已经公布的规划来看： [代码]WePY[代码] 已经发布了 [代码]v2.0.alpha[代码] 版本，虽然没有公开的文档可以查阅到 [代码]2.0[代码] 版本有什么新功能/特性，但据其作者介绍，[代码]WePY 2.0[代码] 会放大招，是一个「对得起开发者」的版本。笔者也非常期待 2.0 正式发布后 [代码]WePY[代码] 的表现。 [代码]mpvue[代码] 已经发布了 [代码]2.0[代码] 的版本，主要是更新了其它端小程序的支持。但从代码提交， issue 的回复/解决率来看，[代码]mpvue[代码] 要想在未来有作为首先要打消社区对于 [代码]mpvue[代码]不管不顾不更新的质疑。 [代码]uni-app[代码] 已经在生态上建设得很好了，应该会在此基础之上继续稳步发展。如果 [代码]uni-app[代码] 能加强开源开放，再加强与大厂的合作，相信未来还能更上一层楼。 [代码]chameleon[代码] 的规划比较宏大，虽然是最后发的框架，但已经在规划或正在实现的功能有： 快应用和端拓展协议 通用组件库和垂直类组件库 面向研发的图形化开发工具 面向非研发的图形化页面搭建工具 如果 [代码]chameleon[代码] 把这些功能都做出来的话，再继续完善生态，争取更多第三方开发者，那么在未来 [代码]chameleon[代码] 将大有可为。 [代码]Taro[代码] 的未来也一样值得憧憬。Taro 即将要发布的 [代码]1.3[代码] 版本就会支持以下功能： 快应用支持 Taro Doctor，自动化检查项目配置和代码合法性 更多的 JSX 语法支持，1.3 之后限制生产力的语法只有 [代码]只能用 map 创造循环组件[代码] 一条 H5 打包体积大幅精简 同时 [代码]Taro[代码] 也正在对移动端进行大规模重构；开发图形化开发工具；开发组件/物料平台以及图形化页面搭建工具。 结语 那说了那么多，到底用哪个呢？ 如果不介意尝鲜和学习 DSL 的话，完全可以尝试 [代码]WePY[代码] 2.0 和 [代码]chameleon[代码] ，一个是酝酿了很久的 2.0 全新升级，一个有专门针对多端开发的多态协议。 [代码]uni-app[代码] 和 [代码]Taro[代码] 相比起来就更像是「水桶型」框架，从工具、UI 库，开发体验、多端支持等各方面来看都没有明显的短板。而 [代码]mpvue[代码] 由于开发一度停滞，现在看来各个方面都不如在小程序端基于它的 [代码]uni-app[代码] 。 当然，Talk is cheap。如果对这个话题有更多兴趣的同学可以去 GitHub 另行研究，有空看代码，没空看提交： chameleon: https://github.com/didi/chameleon mpvue: https://github.com/Meituan-Dianping/mpvue Taro: https://github.com/NervJS/taro uni-app: https://github.com/dcloudio/uni-app WePY: https://github.com/Tencent/wepy (按字母顺序排序)