前言

前端开发里比较重要的一块就是页面的适配，在不同的分辨率下是否有一个较好的浏览体验，这个往往来说对绝大多数的开发者来说都是一个比较头痛的问题，因为这一块并没有一个非常完美的方案，或者说有非常完美的方案，这就造成了很多开发者在页面设计的时候采用各种适配单位，如vw vh % flex rem rpx 媒体查询等等，今天我分享一下在这块的思考，也欢迎各位大佬可以在评论区分享出你们的适配方案。

适配

一般设计稿都是1920X1080尺寸的出，为了适配笔记本，应该左侧菜单宽度固定，右侧根据1366-左侧宽度设置一个min-width， 然后宽度自适应 overflow:auto，在小于1366的屏幕上才会出现横向滚动条（个人理解：flex布局应该建立在min-width的基础上，如果宽度过小，那么内容盒子继续自适应缩放，那么内容就会被挤，高度应该按最小的情况来做，然后往高里适配，或者不要求做全屏的页面，内容高度多了就滚动条。如果把过多的图表内容设计在一个屏幕里，会出现设计不合理的情况，这点要注意）所以如果要做整屏方案，个人觉得应该效果图在1366X1080的设计稿下出，这样才合理，宽度既能做到笔记本的适配，高度也能做到在1080全屏的情况下可以全屏显示内容，在笔记本的情况下，显示不全没关系，滚动条就是了，这样合理，也不会造成内容的挤压。弹窗宽高依然要考虑安全宽高 （具体宽高根据内容设计，不过都要在安全距离以内，这个不需要管分辨率，多少都按这个px进行处理即可），如果设计稿内容过多，不在一页，可以就1366Xn的画布上出效果图即可。 关于字体个人不建议使用vw vh单位来写，虽然在不同分辨率下可以做到缩放，往往很多时候都是不可控的，造成维护起来的麻烦，个人还是推荐用px单位来控制字体大小。 因为最近这段时间忙于taro开发小程序的开发，设置好默认设计稿的大小，源码开发的时候直接输入px单位即可，taro帮你做了适配。

echarts

最后再聊一下关于图表的适配，echarts很多开发者在写toB项目的时候都会遇到，比较理想的方案就是对不同类型的图表抽离成单独的组件进行维护，这样在适配的时候就简单一些，我们只需要给单独的图表组件加上dom容器的监听，只要容器的大小发生变化的时候就去调用echarts的重绘方法，你想再优化一下的话可以加上防抖，这样在我们调用我们组件的页面就不需要再添加针对window的resize的监听，而且外层只需要控制需要显示容器的大小就可以，其实个人认为图表的字体依然采用px来，不要去通过媒体查询或者其他js手段来去动态修改字体的大小，我们应该设置容器的最小的合理大小，以满足我们的字体得以正常浏览，而不是刻意的去满足各个分辨率下的完全一致而去写很多兼容代码。

尾声

如果关于页面的适配，包括设计稿、分辨率以及字体的设置等有一套较好的方案，也希望你可以评论区分享给我，以上只是我的一些个人思考，当然了toC和toB的方案应该也有很大的区别，这里就不展开讨论，往往很多时候以实现功能为主，这些偏次要的点可能大家慢慢的就不再关注了，随着项目不断地重构而慢慢淡去。