竟然是滑动，移动端多么简单的动作，手指上下移动就像在PC上滚动鼠标，你觉得你的手指能做什么？大不了...emmmm，花样坏了，我做之前也是这么想的，但是亲身遇到的时候好酸?(?????)6。这次要求做一个局部Area滚动，页面结构大致分为上中下三种结构。上半部分是固定的黑色播放窗口，中间是滚动区，下半部分是操作导航；当时在chrome手机模拟器上看到的效果并没有出现。问题，不过后来用真手机测试了一下。。。瞬间爆款partialscrolling-webkit-overflow-scrolling:touch造成的“悲剧”滑动不流畅，如图；按照基本布局后，使用.main{overflow-y:scroll;-webkit-overflow-scrolling:touch;}中间部分(mian)得到滚动效果，注意这两个属性，先overflow-y:scroll;不用说，我们都知道这一点。用于内容超过容器高度后容器内出现滚动条。这时候Android和ios的区别就来了。在Android上，可以发现滚动没有异常，但是在ios上，滑动会异常卡顿，完全无法滚动的感觉；所以第二句-webkit-overflow-scrolling:touch被加入；这个东西很强大，可以解决大部分ios部分滚动不流畅的问题；那么这个-webkit-overflow-scrolling:touch;到底是什么？仅iOS设备支持的非标准属性。苹果自己的解释：在overflow:scroll元素中指定是否使用“原生”的滚动方式。它包含两个可选值：auto和touchauto：是普通的无惯性滚动效果（就是上面说的异常滞后，如果你根本不能动，这是默认值）touch：原生滚动效果。（也就是说，你可以获得和原生app一样流畅的滚动效果）；使用此效果将构造一个堆叠上下文！什么是堆叠上下文？这可以说是CSS的阴暗面，极其隐晦。没看懂ヾ(=?ω?=)o）总之所有的坑都是这个造成的！！滑动卡住问题的原因其实是-webkit-overflow-scrolling造成的；**1，在Onsafari中，使用-webkit-overflow-scrolling:touch后，页面偶尔会卡住。2、safari点击其他区域，然后在滚动区域滑动，修复滚动条无法滚动的bug。3、通过动态添加内容打开容器，结果出现根本无法滑动的bug。**第一个问题是当滚动区域的内容滚动到顶部或者滚动到底部时会出现这个问题。滚动到顶部和底部后，如果继续滚动，可能会连同整个页面一起滚动。这时候滑动就会卡住（与其说是卡住不如说是被身体卡住了……一言难尽(〃′皮`)q)；第二个问题是在滚动的过程中，如果点击了other第三个问题是我没有遇到过other的滚动。我什至觉得跟手指滚动的力度和活动幅度有关系……总之，很奇怪！更奇怪的是，在百度上什至很难找到相应的关键词词条来补充一些其他的信息。简单的翻译就是：如果我在一个滚动的div中使用-webkit-overflow-scrolling:touch，它可以达到与原生滚动相当的一般效果，但是，div它有时我会冻结（？）并且不会响应我的手指滑动，2-3秒后又可以滚动了（没过2级的渣英文翻译ヾ(?°?°?)??，不过这种情况确实和我上面说的问题很像）;而这个偶尔卡住的问题，网上的解决方法都不一样，我也遇到过很多相同的说法，比如如果卡住了，加个z-index，就可以声明解决问题。试了很多次，这个语句一次都没有解决问题。这个说法可以流传开来，可能是用户在使用的时候遇到了-webkit-overflow-scrolling:touchpointpenetrationorlayer的问题。所以这个方案不适用。所以这个东西真的困扰了我很久，以至于那段时间所有的滚动条要么是通过body本身滚动，要么是用了iScroll这样的库；如果偶尔卡住，那么使用这个属性不要在元素上设置定位或者手动设置定位为static；这将解决一些由于定位（相对，固定，绝对）导致页面偶尔无法滚动的错误。但是，如果滑动到顶部继续向下滑动手指，或者继续向上滑动到底部，仍然会触发卡住的问题（实际上是整个页面上下弹跳）。说是bug，其实是ios8及以上版本的feature。如果滚动区域大一点，用户就不会觉得这是一个bug，如果小一点，用户就会不知道发生了什么而卡住。附上原文地址：深入学习-webkit-overflow-scrolling:touch和ios滚动scrollTop属性不会改变。以前确实有这种情况，在滚动过程中不会发生值变化，只有在滚动结束时才会发生一次变化，但是现在我无法重现这个bug，目前还没有解决这个bug的办法……（TAT）。..后续ps：导致这个问题的原因还是内核问题。新版微信浏览器已修复此bug，其他第三方浏览器不会出现此问题。都转向了更好的WKWebView，但是你在手机QQ自带的浏览器上会遇到这个问题，获取不到scrollTop的值；至少到我写这篇笔记的那一刻，这个问题还没有解决；手势可以通过其他元素来触发元素滚动也称为滚动穿透。h5上也存在点击穿透（pointpenetration）问题。总结这两个问题；滚动穿透基本体现在上层（z-在索引较大的元素上滚动时，底部元素会滚动，最常见的是在遮罩弹窗上滚动，body也会滚动；你显示半透明遮罩时可以设置ul的-webkit-overflow-Scrolling:touchoroverflow:scroll去掉，但是会导致屏幕明显闪烁，如果给body的touchmove事件preventDefault()，可以防止滚动不会被触发，但是所有的滚动区域都会失效。关于内核的一些历史记录。请问到底是什么原因造成了以上问题？有什么好的解决办法吗？？由于苹果对安全等方面的考虑，苹果阻止第三方浏览器在iOS设备上使用自家浏览器内核，即禁止使用自家内核的浏览器上架AppStore。各大厂商都束手无策，所以长期以来，包括Chrome在内的所有第三方浏览器，都只是利用iOS系统自带的浏览器控件包裹了一个外壳（这个在国内叫外壳浏览器，其实就是国内大部分的浏览器都是这样，对于那些号称双核甚至多核浏览器的浏览器，它们的兼容模式其实是使用的ie内核（trident），快速模式是webkit内核。后面会讲到内核大战）这个控件就是UIWebView。这个UIWebView不仅速度差，HTML5支持率低，内存占用高，还有各种奇怪的问题。然而，Apple已经为自己的Safari浏览器打开了后门。首先，Safari使用的JIT编译JS引擎内核Nitro比UIWebView中旧的解释型JavaScriptCore内核快数倍，然后HTML5的支持也比UIWebView高，怪异的bug也少。随着时间的推移，iOS设备上的Safari浏览器已经彻底碾压了其他第三方浏览器。乔的黑帮老大去世后不久，苹果终于松了口气。虽然它没有解除对第三方浏览器内核的限制，但是它提取了Safari浏览器内核并开放给第三方浏览器使用。那就是今天的WKWebView（WK是Webkit的缩写）。不过由于WKWebView只支持iOS8及以上系统，各大浏览器厂商并没有立即跟进。直到最近的iOS9时代，Chrome成为第一个吃螃蟹的app，使用的是WKWebView内核。测试数据显示，使用WKWebView内核的Chrome浏览器在速度和HTML5支持方面与Safari浏览器不相上下。紧接着，Mozilla宣布Firefox将登陆iOS平台，使用的是WKWebView内核（于是就有了第一个基于Webkit内核的Firefox浏览器：）不知道Apple做了什么，可能Apple的开发者认为WKWebView的性能足以支持在滚动事件中执行额外的代码而不会导致UI冻结。总之，在WKWebView内核中滚动是可以正常触发scroll事件的，当然也可以正常获取scrollTop的值。但是滚动穿透的问题依然存在。最后，经历了这么多问题，终于找到了一款优秀的插件better-scroll，终于解决了这个问题；详细可以百度常用参数和方法better-scrollbetter-scroll//一个简单的例子
