前言
react开发者应该都知道umi，本来我是一名Vueer，跳槽面试也是Vue，不知道为啥分配到了一个React的开发的部门，我花了三天时间看React文档，然后花了三天时间看了umi3、antd、antdesignpro。然后我就开始开发了。
遇到的问题
约定式
规范我根本懒得看，导致我没有使用通过匹配和规定命名来使用约定式路由，包括现在都没去看
环境配置
文档的这一段我一直理解不来，取不到想要的值
最后只能，没去细研究，也可能是antdesignpro封装的一层有什么东西吧
布局问题
因为开发有个需求，没有登录的用户可以看一些类似于官网的页面，而登录的能够进入控制台，然后是在没法覆盖在路由做切换之类的，最后只能这样了
更新缓存问题
因为打包部署后，就算加了哈希也还是无法保证缓存问题，我只要当天有更新就没有什么好的协调方案，因为根据我的网络请求查看，部署的代码会先引入一个umijs的文件下来，里面有一些根据路由加载的文件名，然后切换菜单去获取，你一次页面刷新有时候会导致内部别的还是有缓存之类的问题，页面和代码逻辑还是旧的，虽然这不是umi的问题，但是umi一开始的那个文件体积太大，我公司网络差的时候白屏时间是真的长，但是也只能克服，因为我不想缓存，我在nginx配置no-store，导致我每次进入都要加载这个文件，用户体验差，但是内部使用我也就不想多想了
兼容性问题
有一个系统去年还是umi3的，然后umijs有一个叫mfsu的优化，可以开可关，我也不知道优化了些啥，今年在做新需求（大屏）的时候 有一个轮播卡片的需求，里面可操作，反正定制化挺多的，我就下载了swiper，但是项目一直报错，有人说mfsu关了就好，结果真的可以，但是关闭之后，hrm实在是慢，每次改代码都慢，时不时我还要刷新页面才会看到代码改动，然后忍无可忍我把umi3改成umi4
路由的问题
在升级umi4的时候有一个不好修改的地方就是路由，是因为umi4集成了新的React Router，导致query传参没了，哎，然后我这边的项目之前老一辈的都喜欢用query，他们喜欢看在地址栏上，可能是jsp年代过来的人的喜爱吧，他们对地址栏长什么样没有什么美观之类的看法，而且有些功能像详情之类的，就是希望在地址栏上，他们能复制一下分享给别人，别人点地址就能看到，这是用路由state传参所没有的办法，所以也不知道大佬是出于什么目的，取消，然后用的那个api，升级带来的改造成本颇高。
多页签
这个可能和框架没啥关系，我本来一个项目都开发完运行了，突然需要一个多页签功能，有人觉得套一层在最外层就好了，我也是这么实现的，但是我发现了一个问题，我有很多的代码
const location = useLocation();
useEffect(()=>{},[location])
太痛苦了,救命啊，目前是还没有找到什么好的解决方案，毕竟代码能跑就行
对于我这种半路Reacter其实不友好
现实看法
umi太强大了，所以有个问题就是我只看了react文档，像什么路由啊，全局状态管理啊之类的第三方库都不是很了解，都用内置的，这其实降低了学习成本，但是导致了我到现在只会用umi开发了，我感觉很不好，因为前端不像后端有个“秦始皇”，你在一家公司用springboot，到哪里都是springboot
题外话，我之前遇到一家恶心的公司，在springboot的注解上加了一层，解析一些分页罢了，然后注解名改掉，自称为框架，这其实很恶心，不是每个人都是培训机构的，也不是每个大学生出来都知道springboot的，出来就是让人干活，人家天天用，出去面试springboot原生注解都不太了解，让人家后续怎么发展
所以umi降低了学习成本，也降低了发展空间，除非工作不忙，有时间去学习，但是我想大多数的心态是
- 学了也用不到
- 活都干不
就像我现在根本没有时间去学，去看，去了解，也可能是我懒，但是我觉得主要还是用不到所以不会去了解，之前我开发vue的时候，vue文档、cli文档、路由、全局状态，我都会去看，也都会去学接受。
而且我不喜欢约定式，虽然说代码统一风格比较好，但是真正开发的风格在于内在代码的思路和编码风格，而不是在于外部。
技术层面
封装的东西过多，导致拓展其实不是很灵活，还有很多人说的umi太重
总结
- umijs很好，可能我看的还不是很透彻，用的一直是基于umi出的
- antdesignpro让我失去了自由，封装太多，还都藏起来了，没办法
- 弃之可惜，食之无味的
- 还是要学习，也不是每个地方都用umi的，多去了解自己react的生态圈
