出现惯性的原因
-webkit-overflow-scrolling : touch;
https://developer.mozilla.org/zh-CN/docs/Web/CSS/-webkit-overflow-scrolling
在ios上可以使用这个api
在uniapp的scroll-view组件中自动加入了这个css
为什么要惯性呢
好处呢，就是两个字：流畅。
该属性，会让iOS浏览器的滚动区域，变得特别流畅，媲美原生APP的滚动效果，以至于在H5的滚动区域，都会添加这个属性。
不得不说，惯性滚动大大的提升了用户的体验，也提升了H5页面的逼格，所以就算是开发人员，都无法说服自己，不去使用这个属性。
事物总是会带有双面性的不是么，没有任何一件事，只有好的一面，如果有，那么就说么，你与这个事情的亲密度不够。
惯性滚动也是，而与惯性滚动最为亲密的人，就属于H5的前端开发者，接下来，我们来看看，惯性滚动，会有哪些影响，甚至哪些可以被认为算是BUG呢。
惯性带来的影响
以下链接在iphone手机上可以看到效果
1：click事件
当处于惯性滚动时，click事件将不起作用，或者更确切的说，click事件，将会被认为是，强制滚动停止的事件。
如果在惯性滚动的过程中，手指进行一次点击，那么不会触发对应元素的click事件，而是会停止当前的惯性滚动，这个也是属于正常的吧，我们完全可以接受。
懒得写的话，可以参考：示例1
2：touchend触发之后，滚动并没有停止
作为前端的开发者来说，一些频繁触发重绘，重排，高频计算的JS方法，应该是尽量避免的，毕竟我们并不确定，我们的用户，使用的什么样的手机。
尽量的避免占用内存的量，降低手机性能损耗，也是很重要的，说到这里的时候，相信很多人，都想起了一个效果：滚动加载。
相信也有不少人，尝试过，使用touchend事件，来实现滚动加载，但是当我们使用了惯性滚动这个属性之后，这个方案，就被彻底否决了，因为当元素处于惯性滚动的时候，是已经触发了touchend事件了。
本小节就不进行示例说明了。
3：scrollTop的问题
有文章说：当页面处于惯性滚动时，scrollTop的值是不变的，我进行了尝试，发现根本没有这个问题，我大概猜想当时的作者是为什么有这么一个结论：
原因可能是：在touch事件中，去计算scrollTop的值。
这个问题，就可以看前一条：当处于惯性滚动的时候，其实touch事件，已经都被触发过了，不会在惯性滚动的时候，触发touch事件了，既然都不会触发事件了，那么计算scrollTop的代码都不会被执行了，所以无法获得scrollTop的值，也是正常的啊。
本小节，是经过了测试得到，测试设备有限，可能在不同的手机上，会有些兼容问题，仅作为参考。
4：滚动穿透
本小节，才是本篇文章的重点，并且，本小节也只是拿几种情况的示例，来进行了测试，结果请自行查看，因为结果我个人感觉，还是很难用文字表述的，所以就直接使用示例吧。
现在我们就一个个的来说一下： 假设有两个滚动区域A和B，B区域覆盖在A区域的上方；
接下来，我们将分为四种情况，进行 1：A是文档流，可滚动。 2：B是fixed定位，可滚动。
直接参考示例：示例2
测试方式： 1：B区域，scrollTop=0时，整个屏幕范围内，向上滑动，都是触发的A区域的上滑或者A区域的顶部回弹。（B区域在底部时，效果一样，方向相反）。 2：A , B 区域，两者都不在顶部和底部时，在B区域滚动，则滚动B区域，在A区域内滚动，则滚动A区域。 3：当快速把A区域滑动起来，并且在A区域未停止之前，继续滑动（全屏区域，即使触摸区域在B区域），这个时候，依然是A区域继续滚动，B区域无效。 4：反之，当快速把B区域滑动起来，并且在B区域未停止时，继续滑动，如果滑动区域未B区域，那么B区域会继续滑动，如果滑动区域变成A区域，那么A区域会也会有滚动滚动，此时，手指触发在哪个区域，那么对应区域就会滑动起来。
1：A是文档流，可滚动 2：B是fixed定位，不可滚动
直接参考示例：示例3.
测试结果： 1：不管在屏幕的什么区域滑动，都是触发的A区域的滑动。
1：A是fixed定位，可滚动 2：B是fixed定位，可滚动
直接参考示例：示例4 测试结果： 1：各自滚动各自的区域，不会对双方有影响。
1：A是fixed定位，可滚动 2：B是fixed定位，不可滚动。
直接参考示例：示例5. 测试结果： 1：任何区域滑动，滚动的都是A区域。
若有收获，就点个赞吧
0 人点赞
