OPPO 2020.08.29 前端笔试

题目：

十道选择，几道填空，三道大题

1. proxy代理；
2. generator中的yield*；
3. Number.isNaN()判断；
4. 正则表达式获取三四级域名（这个我没做出来）；
5. 服务器通过设置什么响应头来设置Cookie，又通过设置什么使cookie不能被js脚本获取；
6. await，setTimeout的代码选择答案；
7. js数组API乱炖的代码选择答案；
8. 临时重定向的响应码（302）；什么响应码可以使客户端使用本地缓存（304）；
9. 简答题：URL->浏览器的简单描述；
10. 代码题：
    1. 输入两个数组，去重后获取最接近平均值的最小值。举例：[1,2,3,4,6],[2,3,4,5],平均值是3.5，result是3；
    2. 不超过5位的数转中文。举例：12345转为一万两千三百四十五。

解：

1. proxy代理

ES6中的代理模式-----Proxy
Proxy 对象用于定义基本操作的自定义行为（如属性查找，赋值，枚举，函数调用等）。
简单来说:Proxy对象就是可以让你去对JavaScript中的一切合法对象的基本操作进行自定义.然后用你自定义的操作去覆盖其对象的基本操作.也就是当一个对象去执行一个基本操作时,其执行的过程和结果是你自定义的,而不是对象的.
对于代理模式Proxy的作用主要体现在三个方面:
1、 拦截和监视外部对对象的访问
2、 降低函数或类的复杂度
2、 在复杂操作前对操作进行校验或对所需资源进行管理

2. generator

Generator 是 ES6 中新增的语法，和 Promise ⼀样，都可以⽤来异步编程

// 使⽤ * 表示这是⼀个 Generator 函数
// 内部可以通过 yield 暂停代码
// 通过调⽤ next 恢复执⾏
function* test() {
	let a = 1 + 2;
	yield 2;
	yield 3;
}
let b = test();
console.log(b.next()); // > { value: 2, done: false }
console.log(b.next()); // > { value: 3, done: false }
console.log(b.next()); // > { value: undefined, done: true }

从以上代码可以发现，加上 * 的函数执⾏后拥有了 next 函数，也就是说函数执⾏后返回了⼀个对象。每次调⽤ next 函数可以继续执⾏被暂停的代码。

3. Number.isNaN()

Number.isNaN() 方法确定传递的值是否为 NaN，并且检查其类型是否为 Number。 在 JavaScript 中，NaN 最特殊的地方就是，我们不能使用相等运算符（==) 和 ===）来判断一个值是否是 NaN，因为 NaN == NaN 和 NaN === NaN 都会返回 false。因此，必须要有一个判断值是否是 NaN 的方法。

和全局函数 isNaN()相比，Number.isNaN() 不会自行将参数转换成数字，只有在参数是值为 NaN 的数字时，才会返回 true。

Number.isNaN(NaN);        // true
Number.isNaN(Number.NaN); // true
Number.isNaN(0 / 0)       // true

// 下面这几个如果使用全局的 isNaN() 时，会返回 true。
Number.isNaN("NaN");      // false，字符串 "NaN" 不会被隐式转换成数字 NaN。
Number.isNaN(undefined);  // false
Number.isNaN({});         // false
Number.isNaN("blabla");   // false

// 下面的都返回 false
Number.isNaN(true);
Number.isNaN(null);
Number.isNaN(37);
Number.isNaN("37");
Number.isNaN("37.37");
Number.isNaN("");
Number.isNaN(" ");

Number.isNaN = Number.isNaN || function(value) {
    return typeof value === "number" && isNaN(value);
}

4. 正则表达式

正则表达式

5. 响应头设置cookie

ajax请求时是不会自动带上cookie的，要是想让它带上的会，必须要设置withCredentials为true。
有两种方法可以确保 Cookie 被安全发送，并且不会被意外的参与者或脚本访问：Secure 属性和HttpOnly 属性。

• 标记为 Secure 的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端，因此可以预防 {{Glossary（“ MitM”，“ man-in-the -middle“）}} 攻击者的攻击。但即便设置了 Secure 标记，敏感信息也不应该通过 Cookie 传输，因为 Cookie 有其固有的不安全性，Secure 标记也无法提供确实的安全保障, 例如，可以访问客户端硬盘的人可以读取它。 从 Chrome 52 和 Firefox 52 开始，不安全的站点（http:）无法使用Cookie的 Secure 标记。
• JavaScript {{domxref（“ Document.cookie”）}} API 无法访问带有 HttpOnly 属性的cookie；此类 Cookie 仅作用于服务器。例如，例如，持久化服务器端会话的 Cookie 不需要对 JavaScript 可用，而应具有 HttpOnly 属性。此预防措施有助于缓解跨站点脚本（XSS）)攻击。