在日常的开发中，我们总是重复的做重复的工作，比如我们做管理后台页面的列表页，我们每个项目都是用基于所选的ui组件去开发，每次都是用对应组件的api,虽然挺好，但是对于我来说，总感觉不是自己的东西，有点虚无缥缈的，感觉下一个项目，下一个需求再使用它就要重新熟悉一遍它的功能和使用方法，或者要把以前的冗长的代码copy过来使用，
这不是一个良好的习惯，我的个人习惯里，总是要对拿来的ui组件，比较基础性的、常用性的组件进行符合自己开发习惯的，或者认为是最好解决方案的二次开发封装，这样我能把常用的业务场景，以及和页面布局，其他组件的搭配使用相结合起来，代码进行了抽离，再次有业务需要时候，使用起来会更简单，更高效，我认为这是一个好的习惯
-
由于本人日常使用的前端技术栈以vue为核心，由于naive-ui被尤大仁的极力推荐，本人已经使用该ui框架将近2年，从一开始使用，就像vue2时代一样，开始了组件的基于实际生产的二次开发，经过长久时间的丰富完善，二次封装开发的 rong-table 组件 已经基本能使用于98%的列表业务场景，包括良好的场景布局方案，大大的提高了 开发的效率，降低了列表模块的开发代码繁杂程度，降低了代码量，如果你使用了naive-ui,这个可以帮你大大的解放该部分的开发时间
-
在日常开发环境中，我们常用到富文本编辑器，在实际业务中，富文本上传图片，如果不是长传到云存储，如果只是通过表单接口传递，这时候，如果图片被转为base64字符串，并提交接口的话，一个图片过大，表单接口提交的内容过大，1MB 3MB 5MB ..,接口请求会卡死的，或者接口会拦截，表单提交失败的，网上普遍的富文本 这个问题解决的不是非常经典完整，比如识别粘贴事件上传，这样会把文本内容也当图片上传了。或者把文本内容屏蔽掉了，这是不行的，本人经过妥善构思，现在可以使用函数 html-base64-img-to-upload 在表单提交时候检测对应字段，如果是base64格式的，如果长度大于使用设定的长度参数，则会把这个base64图片自动上传到设定的存储接口上，promise返回上传后的图片地址，避免在表单里面提交，另外，富文本一般会有新手测试提各种奇怪的bug,比较常见的是一个 富文本长度问题，这个我的做法 一般是不做长度限制的，从生产上来说实现不是很理想。。
在个人的看法里。vue,react 只是同一维度的两个竞争的js框架，一般应用场景96%的业务场景，彼此都能很好的解决，只需要把一门学好就行了，人的精力有限的，一个js框架是那么多技术大哥一起努力的产物，对于开发学习者，一个人的智慧力量和专注力是适当有限的，还是专人专事比较好，实际应用中来回切换这两个，可能精力会不够，也就用的不够到精髓，等用到了深处时候会发现框架和js是交互共生的，框架只是一种环境、开发范式、理念。一个vue3是有大概99位技术大哥，将近3000次代码提交，历时2年多时间才开发出来的，而且还借鉴对比于vue2、react、angular。未来的日子里，我也讲适当把vue3的源码读后感记录一下。学习要做笔记，不然学的不深。