想法是好的

1. uniapp做底座，减少代码审核以及发布次数；
2. 业务需求放在H5上开发，经过开发测试之后的需求无需第三方审核，直接流水线部署更新到生产，节约时间成本。

实际的效果

1. 业务需求能保证正常实现；
2. 底座搭好之后只有在需要调整底座上的逻辑时才会重新审核和发布，否则只需要在H5进行新的业务需求的开发，开发完成之后流水线部署更新即可；
3. webview页面经常出现白屏情况；
4. tabbar页面键盘弹出时，软键盘顶部会多出一块白色区域、或者会向上挤压页面弹窗；
5. webview页面不能实现局部刷新。

现实是残酷的

1. 微信的api在H5上，有很多都是无法使用的；
2. 微信小程序环境webview和H5是无法实时通讯的，postMessage的触发机制不是实时的（只在后退、组件销毁、分享时触发）；
3. webview的刷新会造成当前的webview的页面栈增加，造成返回多次才能回退到上一个页面；
4. webview不能对H5的页面进行局部的刷新，通过设置参数的方式等同于重新设置webview的src会导致H5整个页面刷新；
5. H5内的文件下载问题。

填坑（解决问题）

1. api无法使用：转到uniapp上通过中间页的方式找到对应的api再做处理；
2. webview和H5通讯：webview通过在链接上携带参数传到H5，H5通过postMessage传到webview（只在后退、组件销毁、分享时触发）；
3. webview页面返回多次：每次都重新将webview的src置为空，再给src赋值成新页面的地址即可；
4. webview的刷新：通过改变webview的src的参数或固定加一个时间戳，保证每次打开都会刷新页面，每次改变src的值之前，先对src进行置空操作避免页面栈的增加，造成多次回退的问题；
5. H5文件下载：通过跳转uniapp的中间页方式，携带下载参数到中间页进行下载处理，同上第1点。

总结

理想总是很丰满，但现实却依旧很残酷啊。一直都在不断探索的路上，望各位大佬指点一二……

每篇一点毒鸡汤

何以解忧，唯有暴富。如果暴富太难，那退一步，暴饮暴食也行。