共计 811 个字符，预计需要花费 3 分钟才能阅读完成。
最近遇到一个需要，须要在地图上显示某地区的路网线路，后果后端间接返回了 3w 多条数据
每条线路下坐标点靠近 100 个
这四舍五入就是 300w 的数据啊。
而且还不能分层级显示，只能一次性显示全副打点，没方法，硬着头皮放到地图上吧。
开发实现，关上网页，拖动地图，偶然呈现了卡顿的状况，然而，上线吧，能用就行
3 天后
产品经理：诶，这数据怎么不会变啊，你加个轮询定时申请吧，还有地图能不能有点动态效果，隔一段时间随机定位到某个地点吧，而后地图打点点击要有具体数据的弹窗
打工人：…
加上轮询，关上网页，拖动地图，呈现了显著的掉帧和卡顿的状况，然而，上线吧，能用就行
一天后
产品经理：页面没怎么操作，怎么放着放着就崩了
打工人：…
关上控制台，关上工作管理器，发现首次加载页面内存就占用了靠近 1G
第一次轮询，内存占用 1.4G
第二次轮询，内存占用 1.8G
每次轮询，内存占用就增大了 400M，好家伙，这样上来 1T 的内存都不够用啊（况且一个 tab 内存占用到 4G 左右页面就解体了
这 … 不对啊，我明明地图对象都移除了，数据也是重置了啊，内存怎么始终在增大呢？
于是开始了修 bug 之路
通过重复调试和定位，发现是 vue 数据深度监听和地图对象存在援用关系导致内存无奈开释（狐疑）
那这个问题好解决啊，禁用 vue 深度监听不就好了吗
因为本我的项目中申请的数据只用于展现，不会对数据作批改，所以只须要在赋值 data 前把数据解冻即可
this.list = Object.freeze(list)因为数据被解冻，所以 vue 无奈深度遍历数据给数据增加 get 和 set 属性，这样就缩小了数据监听带来的问题，而且在大数据量的状况下 Object.freeze() 十分有用
Object.freeze()办法能够解冻一个对象，一个被解冻的对象再也不能被批改，当然你能够将变量的援用替换掉
- 不能增加新属性
- 不能删除已有属性
- 不能批改已有属性的可枚举性、可配置性、可写性
- 不能批改已有属性的值
- 不能批改原型
