现状
产品需求是做一个带底部吸底支付的支付页面，如下图所示：
但是在部分（大多数）华为系统原生浏览器上会显示如下：
下拉页面，就会发现，是因为华为浏览器下方的工具栏，遮住了支付组件，造成了这个样式兼容问题。
也就是说，在华为浏览器中下方工具条的高度不算在浏览器自身bom高度上，而是算网页dom的一部分。更通俗地理解可以为，它就是个z-index：无限高;position:fixed;bottom:0的<div/>，坑啊！
那么随之而来的几种解决思路是：
1.有没有那么一种设置，可以让这个浏览器组件像ios或vivo oppo等其它手机的浏览器一样正常算在其自身高度内？ 经百度，并没有。但是有个x5内核强制“开启全屏”的meta设置：
// 开启x5内核浏览器的全屏模式<meta name="x5-fullscreen" content="true">相对应的，还有个亲测也是可以的：
// 据称是uc浏览器开始全屏模式，但是我在x5内核中测试也是可以的<meta name=”full-screen” content=”yes”>本来很开心地看到页面完美地如期展现。但是几番操作，发现这种方法不稳定，主要有两个问题：
- 全屏模式下，x5浏览器会自动开启一个悬浮按钮，来进行“全屏-非全屏”状态的切换。这个是设计图之外的东西，在一定程度上对设计图的实现造成了破坏，且会给用户带来迷茫感。
- 全屏模式的保持并不稳定。在某些路由跳转时刻、某些布局下，会退出全屏模式，没有根治样式兼容性缺陷。比如上图中的支付页面的确样式正常了，但是点击支付跳转到“选择支付方式”页面时，就不知所以地退出了全屏模式，下方“立即支付”按钮，又被遮住了。
2.处理交互障碍。也就是说，这个缺陷带来的问题是，用户在第一屏看不到支付渠道，且无法通过下拉显示（因为它不是不存在，而是被一个更高层的div盖住了），那么我们就把支付组件的padding-bottom增高：
.pay-btn-container{ padding-bottom: 95px; // 因为95px是后面讲到的，在移动浏览器中实际算出的 // 距离差，所以不需要换算为rem，直接使用即可。}撑起下部被遮挡部分；或者将document的height增高，同样达到撑起被遮挡部分的作用。
document,.root{ height: calc(100vh + 95px);}但是这样带来的问题是，用户现在确实可以通过下拉页面，最终看到支付按钮了。但依旧不是在一屏以内。这种改进方式和产品、设计的初始预期出入较大，很容易被否掉，后期还是要改。
且作为一名有良好“产品感”的前端设计师，本身应该也很难接受这种调整方案。
3.将非全屏模式下，底部工具栏占用的空间减掉，作为下方支付组件的bottom值。就是算出在“全屏和非全屏模式”下，由于底部虚拟工具栏的出现，而造成浏览器视窗的高度差。将其作为底部支付组件距离下方的距离值即可。这种解决方式主要有一点需要考虑：改虚拟工具栏，在多台设备上的高度是否统一。若不统一，那么此方法不可行，更难受的是，那么就面临着此题无解的尴尬局面。于是我找测试人员借来4台华为设备，通过计算发现高度几乎完全一致（长吁一口粗气），其值大概是95px，那么我们修改支付组件：
.pay-btn-container{ position: fixed; bottom: 95px;}综合考虑三种方式，最终选择最后一种方式，他相对第一种比较稳定，相对第二种对交互侵入性最小，是目前最适合的答案。 但是因为x5内核并没有给出一个方法获取虚拟工具栏的实际高度，且发现其在多台设备上高度确有2px的差距，所以这点也算是隐患。
最后想说，x5真的巨坑，比u4还坑，不亏其“移动端IE6”的大名。腾讯在加入一些安全措施的同时，将本来很好用的webkit改得一团乱麻，严重影响它的可用性。最可恨的是，还没有完全文档，对开发者十分不友好。而那些将自己系统浏览器套用x5内核的“拿来者”也是不友好团队的簇拥。
最后附上一个x5内核坑汇总的链接，希望有用：《QQ浏览器X5内核问题汇总》，如有问题欢迎留言。