响应式适配
采用 viewport 单位做响应式适配
统一标准视口
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no" />
- 设置内容宽度等于设备宽度，避免出现横行滚动条
- 初始缩放为1
- 不支持用户缩放，解决
iphone机型input聚焦自动放大页面
设置预处理器
@device-width: 375; // 默认设计稿宽度
@vmin: (100vmin/@device-width)
利用less预处理器实现计算，使用示例如下：
width: 20 * @vmin // 设计稿要求设置宽度为20px
问题
为什么使用 vmin 而不是 rem ？
rem本质其实就是绕着圈子在模仿viewport单位，还需要 js 配合计算- 类似阿里
flexible.js这种 rem 方案也早已弃用，建议使用viewport单位
- 有成熟的项目落地作为参考，
b站移动端采用viewport单位
为什么是 vmin 而不是 vw ？
vmin 取的是当前 vw 和 vh 中较小的一个值，可以避免使用 vw 时横屏字体偏大，布局怪异等问题；
看个实际的例子，下图我们将b站等顶部导航栏高度单位从 vmin 改为 vw:
好像没什么问题？来看下横屏效果：
啊这导航栏也太高了点吧......改回 vmin 单位看一下：
如果说你们不用兼容横屏，那我还是推荐用 vmin，竖屏下 vmin 就是 vw，等你需要的时候也不用再改成 vmin
关于 vmin 兼容性
- 已兼容
98.39%的浏览器 - 如果真的有用户是使用了那
1.61%的浏览器也完全可以用css预处理器做兼容性处理，不过基本不会有这种情况出现，因为接近1%是因为opera mini，如果不是国际化应用完全不用担心这个问题，因为在中国opera的移动端市场份额几乎为0
下图是10月份中国移动端浏览器市场份额分布情况：
思考
同比例的缩放就是所谓的适配吗，我大屏幕的意义在哪里，是为了看更大的字体吗？
我的答案是不，在屏幕间有较大的差距的时候，比如从 iphone 切到了 ipad，我想更大的屏幕是用来容纳更多的内容的。比如像以下模块：
我在大屏可能希望看到的应该是三个模块甚至四个模块为一行吧？而不是同比的缩放，当然我不排除有些场景它更适合同比的缩放。
那为什么我仍然采用了 viewport 方案？
若要做上述的兼容，需要设计、开发投入更多的工作量，我不可能要求让设计一个场景出多份设计稿，也不能要求每个前端开发人员，全面思考什么需要做换行，什么时候需要在一行容纳多个模块。所以这是最高效的方案，但不是最佳的方案。
那最佳的方案是什么？
最标准的做法是 文字大小用em、rem px，其他容器尺寸元素尺寸全部用px（配合媒体查询），这会带来最佳的用户体验，也是现在许多大型站点使用的方案，如我第一个问题提到的场景就可以有效解决。
样式兼容
前缀问题采用 autoprefixer 统一添加
在 webpack 中使用
配置 postcss-loader，创建 postcss.config.js 文件即可
tips：postcss 它负责把 CSS 代码解析成抽象语法树结构（Abstract Syntax Tree，AST），再交由插件(如 autoprefixer)来进行处理，AST 所能进行的操作是多种多样的，比如可以支持变量和混入（mixin），增加浏览器相关的声明前缀，或是把使用将来的 CSS 规范的样式规则转译（transpile）成当前的 CSS 规范支持的格式。
指定需要兼容的浏览器版本
最好的方式是提供一个 .browserslistrc 文件在根目录，或者增加一个 browserslist 属性在你的 package.json 文件
"browserslist": [
"> 0.1% in CN", // 兼容在中国市场占有率超过 0.1% 的浏览器
"last 2 versions", // 所有浏览器最新的两个版本
"not dead", // 不兼容弃用版本
"not op_mini all", // 不兼容 opera mini
"iOS 7", // 兼容 ios7 版本浏览器
"Firefox ESR" // 兼容火狐企业版
]
browserslist 参数说明，目前兼容的浏览器如下：
其他问题参考--移动端的兼容问题汇总及解决方案
总结
前端适配我想不是单纯的还原设计稿而是带来更好的用户体验，在条件允许的情况，尽量多和设计沟通，以达到视觉体验上的最优。
