1. 箭头函数里的 this 是在箭头函数被定义那一刻决定的，且后续不会再变了。
2. 箭头函数里的 this 是离它最近的外层普通函数的 this ，如果最外层是全局环境，那么即 window 。

第一个输出：
箭头函数定义的那一刻，外层没有普通函数，那么 this 是 window 。
第二个输出：
箭头函数定义的那一刻，外层普通函数是 pet 函数，且 pet 函数被调用是通过 new 操作符，所以 pet 函数的 this 是 cat 对象，即箭头函数的 this 是 cat 。

竟然有人低情商说 op 的博客内容低至...
人家至少坚持了 10 年博客，你还在评论区巴拉键盘呢

@polaa

现在已经不需要还回去了。

不懂你纠结的点是什么？
听上去你们两个人甚至都不喜欢对方。
如果你真的是想找个人结婚过日子，那也得选一个互相合适的啊，何必在这个人身上纠结呢？

@DrakeXiang

mdn 的中文翻译烂的一批

@rabbbit

我觉得，大多数情况下、默认 XXX ，只是用来掩盖自己的知识掌握不够全面的一个说辞而已。

@otakustay

```css
.parent {
font-size: 10px;

.child {
font-size: 20px;
width: 1em;
}
}
```
如果按照你说的，child 的宽度应该是 10px ，实际上最后的宽度是 20px ，你可以自己验证一下。

@danbai
并不是。
因为我们是先讨论完 rem 的计算是通过根元素的字号来进行计算，之后又问的 em.

底下的部分评论太让人长见识了，是真劝别人大度一点啊...

@lucays
我觉得把前端的心理动态套在后端上，确实是合理的。
按照咱们俩这样解释前后端的心理动态的话，也许问题还是出在了运维那里。
（ 我并不是说前端没犯错，只是始作俑者确实不在前端这。

莫名能理解 op 的心理破防的原因。
页面 500 了，大概率不是前端的问题。然而 op 还是去询问了运维，运维说让找后端，后端又说找运维。
请问各位，如果是你，你的心态还会依旧依旧平稳吗？
只是 op 有点冲动了，其实把大家拉到一个群里，心平气和地讨论就好了。
这个事前端没办法解决，最终肯定赖不到前端这。

（还有人在嘲讽前端不懂 Nginx 的，我也不认同。就算前端需要懂 Nginx ，必须每个人都懂吗？
前端都有自己的定位，有人写业务，有人负责基建，有人负责服务适配，没有全能。

@maizero
方便加一个联系方式吗