我真的找到问题了。它不是我想的那样用JS，而是用CSS。我添加了一个类来做一个CSS过渡来淡入一些元素。对于匿名用户，这些元素有display: none;，可能从未运行过不透明过渡。
奇怪的是，转换正好在两个元素上。那么为什么这只会在有100多条评论的长线程上崩溃呢？
所以底线是：-webkit-transition在移动的safari上的页面崩溃。

也有同样的问题，对我来说是-webkit-transform: translateZ(0);导致了Safari的崩溃。

我知道这个问题已经成功地回答了，但我只是想把我的五美分也放进去，因为我已经在这个问题上撞了好几次了：
正如大多数答案已经指出的，这通常归结为内存问题。几乎任何东西都可能是最后一位，最终翻倒在“内存堆”上，就像translateZ或其他任何东西。
然而，根据我的经验，它与实际的CSS（或JS）命令没有任何关系。只是碰巧上一次的转变太过分了。
对我有很大帮助的是将此时不可见的任何东西保留在display: none下。这听起来可能很原始，但实际上很有用。这是一种简单的方法，可以告诉浏览器的渲染器，此时不需要这个元素，因此释放内存。这允许你创建一英里长的垂直滚动与各种3d效果，只要你隐藏的元素，你没有在这个时候使用。

任何iOS应用程序的主要问题都是内存使用。因此，很可能您的页面使用了太多内存。
移动的Safari使用了一些巧妙的技术，因此在任何给定的时间，不是整个页面都必须驻留在内存中，而是其中的一部分。也许您可以检查页面中是否有任何内容破坏了此机制或使其效率降低。
在任何情况下，给予更多的点建议，更多的信息，你的网页将是真的很大。
顺便说一句，你可以从设备存储的崩溃日志中得到一些提示。查看是否可以在“设置”下找到它：
1.一般条款
1.内容
1.诊断和使用
1.诊断和使用数据
如果是内存问题，你应该找到类似“signal（0）”的东西;不确定这是否只能意味着“由于内存使用而被杀死”，但当我发现信号（0）时，我通常认为这是理所当然的。
否则，它可能会告诉你什么是错的…
希望这对你有帮助。

有内存限制和JavaScript执行时间限制，尽管对于如何实际达到这些限制有点模糊。常见的报告是，大小大于10MB的页面将出现问题，并且JavaScript执行时间限制为10秒。
有关详细信息，请参阅Apple文档。

我最近遇到了一个问题，因为移动的safari在包含大量图片（30多张就足够了）和一些菜单转换的网页上崩溃。经过大量的尝试和错误，我最终采用了一个类似于LinkedIn的解决方案，但使用angularjs进行无限滚动。我在列表的顶部和底部使用了requestAnimFrame和两个展开/收缩divs（带有js style属性）来移除所有的图片容器（上面覆盖了其他东西），除了一些靠近视口的图片容器。滚动性能（原生的，没有js）很好，内存消耗也在控制之中。

我也遇到过类似的问题，网页在Android设备上工作得像一个魅力，在IOS上崩溃（iPhone和模拟器）.
经过大量的研究（也使用ios_webkit_debug_proxy），我发现问题与jQuery ready事件有关。
添加一点超时就解决了这个问题。我的应用程序也使用了iframe。

$(document).ready(function () {
    window.setTimeout(function () { ready(); }, 10);
});

字符串

贡献一点：这是我使用CSS filter: grayscale时发生的。有趣的是，我对filter: brightness没有问题。想想吧