这里记录工作中遇到的技术点，以及自己对生活的一些思考，周三或周五发布。
封面图
Taro及Taro-Ui
Taro是京东旗下的跨端开发框架，功能非常强大，支持React/Vue/Nerv进行小程序，H5，甚至是RN应用。
并且以Taro命名，足见其野心不小。从这一方面看，你也许会想跃跃欲试，想着尽快将其用户生产环境的开发中去。
Taro-UI是基于Taro框架开发的多端UI组件，支持小程序及H5端，但是不能适配ReactNative。
近一年的开发都在使用这个两个框架，从我个人的使用体验来讲，我觉得如果以后再有开发小程序或者H5的业务时候，我会果断放弃这个框架，因为它的坑实在是不少，尤其是开发企业微信的时候。
Taro及Taro-Ui入坑到弃坑
个人最早使用Taro是在2019年，当时有个非常简单的小程序，也就三四个界面，刚好那一段时间在看Taro，那时候用的版本是1.0,整体的感觉也还好，React语法、类似小程序原生的UI组件，很快就完成了工作。
之后的工作就跟Taro基本没什么关系了。但是今年伊始，因为项目中需要进行多端开发，所以一直在用Taro及Taro-UI进行开发，涉及两个项目，一个是项目需要同时打包成小程序及H5，另外一个项目是企业微信内应用开发。
同时打包成小程序及H5这个项目我们暂且管它叫客户端开发。客户端的开发体验总体上感觉还可以，没有那么多的坑需要去踩，因为有些问题是我们可以提前想到的。比如：
- 运行环境判断
- 登录流行控制
- 系统权限API的异同
- 项目发布流程
- 调试方式
等等，因为在客户端开发的时候同时对这些问题做了处理，所以倒也没遇到什么比较难以解决的问题。甚至觉得自己已经对这套框架相当有信心了，直到切换到了企业微信的开发上，才发现，还是太天真了，各种问题让人头大。
企业微信应用的开发流程跟微信公众号开发的流程一致。但是企业微信的开发体验简直是糟糕透了。
这种糟糕的情况体现在两个方面:
一是项目发布流程。每改动一个地方，就需要发布一次测试或者预发环境进行验证，如果从打包到项目发布成功所消耗的时间非常短，一分钟或者两分钟，也还能接受。可惜的是，我们的CI流程，每发布一次耗时都在5分钟以上，而且极其不稳定。有可能上一秒还在发布项目，突然你的应用就全部离线了。修复这个离线的过程有可能需要半天甚至一天时间。
二是Taro-UI对企业微信的PC端应用和移动端应用内置的浏览器存在严重的兼容性问题。因为PC端的企业微信内置的浏览器类似我们PC的谷歌内核。而移动端的企业微信内置的浏览内核应该是微信的X5内核。所以同样一个输入框，在企业微信应用中，PC上和手机上表现的完全不一致。一个输入框，本地用PC浏览器调试，H5模式完全正常，但是一旦切换回正常的网页模式，完全就废了。
涉及的组件主要是：
- AtInput
- AtInputNumber
并且，文档中标明的属性，也不一定真的有用。比如：
- AtInput 的
maxLength属性。
从用Taro做客户端开发到用Taro做企业微信开发，个人的心态从信心满满变成了想马上弃坑。
是人性的扭曲？还是道德的沦丧？
对于Taro-UI组件，看了它的样式，相当于基于weui进行的二次封装，然后支持编译成小程序UI和H5，但是对于企业微信的兼容性，还是需要在进一步提升一下。
结论
所以最后的结论是，如果你的项目不涉及企业微信开发，那么你大可以使用Taro及Taro-UI，因为这些坑都是小坑。
但是假如开发的项目是企业微信应用，那最好还是选个别的什么UI框架吧，起码企业微信的PC端和手机端的UI能保持一致。
其实用Taro进行开发的大多还是JD内部的项目，并且大多项目跟企业微信关系不大。对于我来说Taro已经不香了。
基于Taro的多端（小程序 H5）开发实践
之前总结的:
基于Taro的多端（小程序 H5）开发实践:https://www.yuque.com/terrence-skafm/dgsa0u/uazr23
