一、核心思路

从零开始用taro写一个小程序的机会是比较少的，如果想马上体验taro带来的工程化开发小程序的便捷，解决现有微信小程序工程和taro的混写，是比较现实的问题。
首先需要放弃的思路是微信小程序转taro，因为转换后代码几乎没有可读性，二次开发是个大坑，而且转换编译过程中会出现很多编译错误问题。
通过查阅文档，得知Taro 项目 支持 Taro 的代码与小程序（微信/百度/支付宝/字节跳动）原生的页面、组件代码混合存在，所以混写最靠谱的思路还是把现有小程序工程嵌入到taro工程中，此时编译taro工程到小程序，原本就有的小程序页面和组件代码不会被修改，而是直接拷贝到对应产物目录，保证了双方代码都是完全可读的。当然过程不是一帆风顺的，需要解决很多现实问题

二、小程序工程结构改造

2.1 入口文件改造

文档里说的很清楚，允许taro工程中存在小程序原生的页面、组件代码的混合存在，所以工程的主体必须是taro工程，所以原本小程序的入口文件app.js需要和taro的入口文件app.jsx融合。

2.1.1 手动融合入口文件

手动融合的方法就是使用taro框架提供的@withWeapp()装饰器，（他是转换代码的运行时，会增加一些原来 Taro 没有方法和属性），将原小程序入口文件app.js中的代码都放入装饰器中即可

  1. @withWeapp({ ...原小程序入口文件app.js中的代码 })

手动融合还需要将原小程序的一些全局配置转换成taro的全局配置，比较繁琐，不推荐手动融合。

2.1.2 转译融合

在小程序工程根目录执行 taro convert 指令，这个指令是微信原生小程序转 Taro ，但我们只需要转译后的入口文件即可，其他不需要，把转译出来的app.jsx入口文件中，@withWeapp()装饰器装饰的那部分代码拷贝到自己的taro工程的入口文件中，把转译出来的入口文件中App类中的一些全局配置也拷贝到taro工程的入口文件中，就完成了入口文件的改造

2.2 源码文件目录改造

将小程序工程根目录下的所有源码文件夹拷贝到taro工程的src目录下
原小程序工程的app.wxss中的全局样式拷贝到taro的app全局样式中
此时小程序工程的app.js app.json app.wxss文件都可以丢弃了，把根目录下剩余文件拷贝到taro工程根目录下

2.3 网络请求模块改造

一般小程序网络请求都会抽出一个工具类统一处理，混写时需要转换成taro的网络请求API，从2.1.2步中转译后的工程中，拷贝出工具类，放入现有taro工程即可。

三 混写工程的编译

完成改造后，只剩下混写工程编译成小程序代码这一步了，执行：taro build —type weapp —watch
执行完后，编译产物导入微信开发者工具后，会发现，缺失了部分源文件，一般都是一些静态文件，比如图片资源，util文件等，需要把缺失的这些文件全部拷贝到编译产物中
由于每次编译完成，产物都会被自动替换，导致每次编译后都要拷贝这些缺失的文件，所以这里迫切需要自动化脚本来处理，此时就需要用node来写cli处理了，这也是node给前端带来的最强大武器。