仅仅就是为了做模拟native的下拉刷新吗？
回复内容：
其实是得不偿失的，前端很难想象浏览器为了网页滚动的流畅性做了多少优化，才能达到稳定60fps的效果，而JS控制的滚动就意味着放弃了这些优化，并且还要加上额外的JS/DOM/CSS开销。一些浏览器常见的滚动优化：
1，预判滚动的方向，预先生成不可见区域纹理；
2，异步光栅化，延迟光栅化；
3，延迟甚至停止内核网页重绘/重排版；
4，线程优先级调整，任务优先级调整；
----
补充浏览器处理滚动的一些其它优势：
1，浏览器处理触屏事件比使用JS处理响应更及时；
2，浏览器一般使用OS本身的惯性滚动算法，更符合用户的使用体验；
3，浏览器可以记录页面的滚动位置，在前进后退或者后台被杀重启后可以自动恢复页面的位置；
如果需要了解更多浏览器渲染的知识，可以阅读我的文章：
How Rendering Work (in WebKit and Blink) 淘宝的前端是渣，看下天猫淘宝商品页的源代码就知道，要多难看有多难看。最近一年有改善，不知道是哪个部门主导的。 不仅是 Web 端，也有一些其他的客户端之类的 view（视图） 选择自己实现滚动效果，而屏蔽掉浏览器、view 组件的默认滚动。
自己实现滚动，可以让 view 有更丰富的动作和效果，也为其增加了更多的可控制能力（参数化、函数化）。
但是，自定义组件和动作会有更多的麻烦：
1. 兼容性无法保证。许多自定义的内容只在有限的平台和设备上测试过，在一些未测试的设备和平台上，可能存在 Bug、性能差、不稳定或者表现不一致等诸多问题。
2. 丢失了通用的默认行为。举个例子：浏览器打开页面时，可以滚动到 URL 中 #abc 对应的页面中 ID 为 abc 的元素，如果你的页面是单页应用，但子页面跟 URL 无关，那这种滚动（或单页应用中的切换子页面）行为就丢掉了。类似的例子还有很多，都是坑。
如果没有能力保证兼容性，并实现或保留通用的默认行为，还是不要自定义。 在我手机上巨卡，安卓uc浏览器 忘记安卓4.0还是4.1了，ajax载人的东西滚蛋有bug，烦死人 当你有足够开发能力的时候，自己实现滚动好处多多，
1.微调参数，例如滚动速度，惯性，越界回弹距离，时间，android的webview是没有自带回弹的
2.更多的功能，例如下拉刷新，实现更好看的滚动条
3.防止一些问题，比如单页app拉动出页面边界
自己只有用到过这些 ios在滚动的时候会禁js，可能是因为这个原因吧
