【JS】1410- 一行 Object.keys() 引发的思考

作者：4Ark

https://juejin.cn/post/7041049741458669576

故事背景

有一天上线后大佬反馈了一个问题，他刚发的动态在生成分享卡片的时候，卡片底部的小程序码丢失了，然而其他小伙伴都表示在自己手机上运行正常。事实上大佬也说除了这条动态以外，其它都是正常的。

说明这个 BUG 需要特定的动态卡片 + 特定的设备才能复现，所幸坐我对面的小姐姐手机与大佬是同款，也能复现 BUG，避免了作为社恐的我要去找大佬借手机测试的尴尬。

先交代一下项目背景，这是一个微信小程序项目，其中生成分享卡片功能用到的是一个叫 wxml2canvas^[1] 的库，然而该库目前看上去已经「年久失修」，上面所说的 BUG 就是因为这个库，

本文分享一下排查该 BUG 的过程、以及如何从 ECMAScript 规范中找到关于 Object.keys() 返回顺序的规范定义，最后介绍一下在 V8 引擎中是如何处理对象属性的。

希望大家在阅读本文后，不会再因为搞不懂 Object.keys() 输出的顺序而犯错导致产生莫名其妙的 BUG。

TL;DR

本文很长，如果你不想阅读整篇文章，可以阅读这段摘要；如果你打算阅读整篇文章，那么你完全可以跳过本段。

如果阅读摘要时未能帮助你理解，可以跳转到对应章节进行详细阅读。

摘要：

这个 BUG 是如何产生的？

wxml2canvas 在绘制的时候，会根据一个叫做 sorted 的对象对它的 keys 进行遍历，该对象的 key 为节点的 top 值，value 为节点元素；问题就是出在这里，该库作者误以为 Object.keys() 总是会按照实际创建属性的顺序返回，然而当 key 为正整数的时候，返回顺序就不符合原本的预期了，会出现了绘制顺序错乱，从而导致这个 BUG 的产生。
源码：src/index.js#L1146^[2] 和 src/index.js#L829^[3]

如何解决这个 BUG

由于对象的 key 是一个数字，那么 key 有可能会是整数，也有可能是浮点数。但是预期行为是希望 Object.keys() 按照属性实际创建的顺序返回，那只要将所有 key 都强制转换为浮点数就好了。

Object.keys() 是按照什么顺序返回值的？

Object.keys() 返回顺序与遍历对象属性时的顺序一样，调用的 [[OwnPropertyKeys]]() 内部方法。
根据 ECMAScript 规范^[4]，在输出 keys 时会先将所有 key 为数组索引类型（正整数）从小到大的顺序排序，然后将所有字符串类型（包括负数、浮点数）的 key 按照实际创建的顺序来排序。

V8 内部是如何处理对象属性的？

V8 在存储对象属性时，为了提高访问效率，会分为常规属性(properties) 和 排序属性(elements)
- 排序属性(elements) ，就是数组索引类型的属性（也就是正整数类型）。
- 常规属性(properties) ，就是字符串类型的属性（也包括负数、浮点数）。
- 以上两种属性都会存放在线性结构中，称为快属性。
- 然而这样每次查询都有一个间接层，会影响效率，所以 V8 引入对象内属性(in-object-properties) 。
V8 会为每一个对象关联一个隐藏类，用于记录该对象的形状，相同形状的对象会共用同一个隐藏类。
- 当对象添加、删除属性的时候，会创建一个新的对应的隐藏类，并重新关联。
对象内属性会将部分常规属性直接放在对象第一层，所以它访问效率是最高的。
- 当常规属性的数量少于对象初始化时的属性数量时，常规属性会直接作为对象内属性存放。
虽然快属性访问速度快，但是从线性结构中添加或删除时执行效率会非常低，因此如果属性特别多、或出现添加和删除属性时，就会将常规属性从线性存储改为字典存储，这就是慢属性。

可以看一下这两张图帮助理解：

V8 常规属性和排序属性

V8 对象内属性、快属性和慢属性

图片出处：《图解 Google V8》^[5]

如何解决该 BUG

由于是特定的动态 + 特定的设备才能复现问题，可以很轻易地排除掉网络原因，通过在 wxml2canvas 输出绘制的节点列表，也能看到小程序码相关的节点。

既然 wxml2canvas 已经接受到小程序码的节点，却没有绘制出来，那么问题自然就出在 wxml2canvas 内部，不过已经见怪不怪了，在我加入项目以后就已经多次因为这操蛋的 wxml2canvas 出现各种问题而搞得头皮发麻，有机会一定要替换掉这个库，但由于已经有很多页面在依赖这个库，现在也只能硬着头皮上。

首先怀疑是小程序码节点的坐标位置不太对，通过对比，发现位置相差不大，排除该原因。

然后对比所有节点的绘制顺序，发现了一个不太寻常的点，在复现 BUG 的手机上，绘制小程序码节点的时机是比较靠前的，但由于它在卡片底部，所以在正常情况下，应该是比较靠后才对。

于是通过查看相关代码，果然发现了其中的玄机：

在绘制的时候，通过遍历 sorted 对象，从上往下、从左到右依次绘制，但是通过对比两台手机的 Object.keys()，发现了它们的输出是不一样的，这时候我就明白怎么回事了。

先来说说这个 sorted 对象，它是一个 key 为节点 top 值，value 为所有相同 top 值（同一行）的元素数组。

下面是生成它的代码：

问题就发生在前面所说的 Object.keys() 这里，我们先来看个