一般的 CSS 代码只会出现 UI 版式 或者 兼容性方面的小问题。但这里我们要分享一行有趣的 CSS，它可以直接让你的 Ch rom e 页面挂掉 :)
复现
在 C hr ome 里打开一个稍复杂的页面，比如 知乎 或者 掘金 打开 开发者 工具，为页面 <body> 增加样式 style: "width:1px; h ei ght:1px; transform:scale(10000)" 欣赏 任务管理器 里 Chrome 崩溃 前的内存占用
其实这台机器只有 8GB 内存， 不过 这不 重要 了。和让 JS 崩溃的红线容量 4GB 比起来，果然还是 CSS 更强大呢 :)
故事
这行代码的发现， 源 自于我们的编辑器项目在实现 画布 尺寸 调节 时的一个诡异现象：用户调节画布尺寸时， 只要新旧尺寸之比超过一定幅度，Chrome 就会卡死 。
虽然这个问题很难由普通用户的操作路径触发，不过它所导致的后果确实比较严重。排查时我们首先考虑了 JS 阻塞和 DOM 重绘过频等方面的可能性，但它们都不是问题所在。一个 突破 点在于调试器 Rendering 工具中 FPS Meter 的输出：
&nbs p;
这里 GPU Memory 被占满了。虽然这个提示信息现在看来很明显是与 硬件 加速有关的，但在没有相关 经历 的情况下我们还是没有确定它与具体代码之间的关联。直到我们偶然查看 Chrome 设计文档中关于 Compos IT ing 的介绍时，发现了一个行为：Blink 会将 DOM 节点映射到 LayoutObject 的渲染树，这棵树中的节点理论上每个都能 具备 到渲染 后端 的上下文，但为了节约资源 Chrome 会将它们做一些合并后再渲染。而这时存在 CSS 定位（如绝对定位与 transform）的元素是不能合并的，这会造成对显存的额外开销。
基于这个信息的提示，我们使用 Layout 工具来调试 当时 的页面，果然 找到了 一个特殊的地方：
图中最大的矩形 Layer 通过一般的 DOM 调试是无法看见的，因此我们推测它的过大尺寸所导致的 R am 开销是罪魁祸首。基于这个信息，我们最后找到了一个 宽 高都很合理但 transform 的 scale 值可能在逻辑中被修改得很大的 DOM 节点，限制它的 scale 上限即可解决问题：我们不难发现 scale 的值和最终对应像素数量之间有着 O(N^2) 的关系，1 个像素只放大 100 倍也有 10000 个像素了。因此 scale 很大时对内存 / 显存的过度使用也就是有可能的了（当然浏览器会做 Tiling 等工作，因此这不符合一般情况下的实际情形，Safari / Firefox 这时候也没有出现问题）。最后给 Chrome 提了个 bug 见 # 894115
总结
需要注意的是，因为缺乏对浏览器内核的深度 了解 ，上面的调试思路很可能是不准确的。 简单 的总结：
硬件加速是有代价的，最好能 知道 代价在哪 浏览器的文档里藏着很多有 意思 的东西 @R_ 304 _2495@的一些冷门功能其实很强大，平时可以多试试以上所述是小编给大家介绍的让 Chrome 崩溃的一行 CSS 代码， 希望对大家有所帮助 ，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对网站的支持！
总结
以上是 为你收集整理的 让 Chrome 崩溃的一行 CSS 代码 全部内容，希望文章能够帮你解决 让 Chrome 崩溃的一行 CSS 代码 所遇到的问题。
如果觉得 网站内容还不错， 推荐好友。
查看更多关于让 Chrome 崩溃的一行 CSS 代码的详细内容...