（小埋大小变镇楼）
关于移动端的网页适配方案，可以用媒体查询，em，rem，vw/vh，viewport等技术处理，这些大家只要接触过移动端网页开发，多多少少都会了解的。不过今天要聊的主题并不是移动端，而是pc端适配。
作为大屏幕网页场景，pc端的屏幕尺寸差距远比移动端要复杂，先是屏幕宽度差距，跨度可以在一千多像素（竖屏）到两千多像素，可以是大屏台式，也可以是笔记本/平板；不像移动端相对固定，窗口能最大化，或者任意宽度调整...
当你遇到需要对pc端网页进行缩放操作的时候，多半会比较头疼。要么告诉产品运营，这个做不了，不支持 ┑(￣Д ￣)┍；要么只能死些脑细胞，看看怎么实现。
那么来啦，惯例思维，先来捋一下思路
先说明，IE8不要出来，我不想见到它，也不打算兼容它~
网页适配，其实就是按屏幕大小调整页面元素/文字的大小，尽可能完整的展示内容。
那么，无论是pc还是移动端，思路都是一样的，可以用媒体查询渐进式调整，可以用font-size等css单位控制大下，还能用整体缩放实现，以下依次梳理。
先来看看一号选手【媒体查询】的表现。
关于它是啥我就不解析了，通过媒体查询实现pc适配的经典代表就是Bootstrap的栅格系统，当年这真是一把锋利无比的杀猪刀，从后台到网站，到处都是它的身影，时至今日，我们很多人仍受惠于它。
虽然思想很好，但奈何现实不太美丽。
首先它的存在就会影响美术放飞自我。强行要求一个美术理解为什么要把页面分成等宽格子，板块需要按格子调整，本身就是不大现实的事情。部分美术甚至连同一组按钮的尺寸间距都没能做到统一，更别提要求他们按不同屏幕尺寸标准做出数套设计图。
此方案很难顺利达成，现在基本都是后台在用，其他地方也有少量用到【媒体查询】做调整。
接着是二号选手【font-size】。
这里就不说vw/vh这些了，我知道按照屏幕宽度变化尺寸很美，现实是移动端都未必能兼容，pc端真可以直接打死了。着重说rem吧，这个比较好用~
rem本身解析就是“font size of the root element”，也就是相对于根元素字体大小而变化的单位。好处我就不提了，具体实现可以百度一下~
一般来说都是用在移动端上的，不过近年来的浏览器发展也蛮快的，pc端直接用问题不大，我们康康它的兼容性。
上图一片绿油油，搭配自动转换工具，标准可行方案，简直美滋滋~
再次吐槽一下，美术作图不规范，开发泪两行...
这个方案需要建立在美术【能做到】的基础上。我们接到的设计稿出现10多像素大小的文字屡见不鲜，且死不悔改的人一抓一大把，要知道移动端文字最小只能去到10像素，pc端大多只能去到12像素。移动端按图稿能用transform缩放个别文字勉强实现，但pc端就~~ ╮(╯▽╰)╭
最后迎来三号选手【缩放】。
和移动端一样，只要整体缩放到视图合适大小，基本就是我们想要的效果了，妥妥的。
不过到了具体实现方案的时候，这个让我觉得有点一言难尽。
因为它没有完美的实现方案.... _(´ཀ`」 ∠)_
网上能翻得到的方案，我基本去印证过，大概说明一下战斗过程。
-
viewport。这个是个假方案，我其实以前就知道可能性不大，在移动端用着OK，但pc端我印象中是不可行的。这次再次实践，得出结论是放弃。不要问为啥，问就是不支持，真相可以去查一下文档，增加知识储备~
-
css zoom属性。这个真的是炒鸡爽，一个zoom设置好，网页整个按比例缩放展示，无需额外调整，真正实现一步到位~
可惜有个叫Firefox的憨憨抵死不从，一直不跟随大众步伐，全线飘红... -
css transform scale。这可以说是最兼容的方案了，作为几乎全绿的靓仔，transform 属性被广泛使用，旋转，缩放，移动，倾斜，位移，几乎囊括所有交互变化，移动端pc端都能为所欲为。
在我们的需求场景中，它也似乎是胜任的，一个缩放轻松搞定整个页面适问题~
别高兴得太早，回忆一下transform的特点：transform并没有让元素脱离标准流。可能是出于性能考虑，避免造成回流，无论元素如何transform变换，仍占有原来的空间大小。
这意味着如果要做常规布局的缩放，你需要裁剪掉缩放后多出来的空白，或者补上放大后缺少了的空间。
此外，transform后，内部元素如果有fixed定位的子元素，那么这个子元素将不再相对于根元素定位，变成了父元素，类似absolute的存在。テ_デ
完美是不可能的，这世界就没有尽善尽美的事，我只能安慰我自己，我不能既要有要还要...
综上所述，进行小结。
-
如果美术给力，或者网站属于功能性站点，可以比较刻板，媒体查询即可完成需求。
-
如果美术给力，设计有规范，字体问题能把控得住，拥抱rem，一切都会很和谐。
-
没有上面的如果，可选择范围就变得很小了，你只能在不完美中找到出路。
最后说下我实践可行的transform方案吧。
经过上面的说明可以知道，transform缩放方案不适用于单个元素（如按钮）的缩放，也不适用语根元素缩放。它应该是作用在一个块，一个章节上的，且避免在含有fixed定位的子元素上套用。
这条件听着有点苛刻，但这实际已经包含了绝大多数的使用场景的了，并不是小众场景。基本网页都是按版面分块的，而悬浮于页面上的导航，侧边栏也是独立的块，它们内部也可以进行独立的缩放处理。
思路说明：
设置一个外壳元素，用于裁剪/扩张。获取被缩放的块元素的真实尺寸（即使transform缩放了，元素大小仍不会变化的），按缩放比例计算，得到缩放尺寸，直接套用样式，即可去除多余空白/弥补不足空间。
再者就是自动缩放的问题：
监听resize事件（可节流优化），计算缩放比例之后触发新的样式计算。设置样式的的操作可整合成多个小函数方便调用，避免代码重复臃肿。
代码我就不发了，这说透了其实是个稍微花几分钟就能码出来的小功能，没show的价值。
本文到此结束，如果还有其他好的方案，欢迎浏览讨论哦~~
