企业官网建设流程全解析

2020奇安信秋招前端方向试卷2 复盘：安全厂商的前端笔试题到底在考什么？

又到了秋招季，后台有不少同学在问奇安信的前端笔试题。刚好去年（2020）秋天我完整走了一遍奇安信的校招流程，笔试、技术面、HR面一个没落，最后也顺利拿了Offer。最近整理笔记，翻出当时做的这套前端方向试卷2，对着答案和后续面试追问重新过了一遍，发现很多题目放到今天依然有参考价值。趁热打铁，把这套试卷的完整解题思路、考察意图和踩坑记录整理出来，给准备投递安全类互联网公司前端岗的同学做个参照。

先说说这套试卷的整体感受：奇安信作为安全行业的头部厂商，前端笔试题并没有刻意去考渗透测试、漏洞挖掘这类安全工程师才需要掌握的硬核内容，而是把安全思维渗透到了前端基础、网络协议、工程化这些常规考点里。整张卷子大概覆盖了JavaScript语言特性、浏览器工作原理、HTTP与网络安全、前端工程化与框架、算法与逻辑思维五个大方向，题型以选择、简答和编程题为主，题量适中，但广度不低，想要拿高分并不容易。

下面我按题型模块拆解，把每道题背后的考点逻辑和正确答题姿势都说清楚。即便你今年才准备投递，把这份题解吃透，再去刷其他安全厂商的笔试题，会轻松很多。

1. 整体设计与思路拆解：安全厂商前端笔试的出题逻辑

开始逐题分析前，先聊点务虚但对备考很有用的事：为什么奇安信会出这样的卷子？它的出题人和普通互联网大厂的前端笔试思路有什么不同？

1.1 五个考察方向的权重分配

从我拿到的这版试卷来看，题目分布大致如下：

这个分布其实很有代表性。普通电商、内容平台的笔试题里安全方向占比可能只有5%左右，顶多考一道XSS基础概念题。但奇安信把安全相关的考察提到了15%的权重，而且不是孤立地考，而是把安全问题放在真实业务场景里让你分析——比如给你一段有漏洞的代码，问你如何修复。

1.2 为什么要这么设计

我后来入职后和当时出题的前端Leader聊过，他的原话大意是：前端岗位在安全公司不仅是做页面，还要做安全产品的控制台、可视化大屏、数据展示，这些场景对前端工程师的安全意识要求比普通业务线高得多。

想想也确实如此。奇安信的产品线很多是安全运营平台，前端要处理大量敏感数据，展示漏洞详情、攻击溯源、威胁情报这类信息。如果前端工程师自己都不了解XSS、CSRF、点击劫持的原理，写出来的控制台本身就可能是安全隐患。所以笔试题里反复出现这类题目，本质上是在筛选“有安全思维的前端工程师”，而不是单纯考你会不会写页面。

这给了我们一个明确的备考方向:投递安全类公司的前端岗位，除了常规的八股文和算法刷题，一定要额外补充Web安全的基础知识，重点是XSS、CSRF、CSP、同源策略、跨域方案这些和前端强相关的领域。

2. 核心考点逐题解析：JavaScript与浏览器原理

这个模块是整张卷子的得分基础，也是区分度比较高的部分。选择题看起来简单，但很多选项都在考容易混淆的概念。

2.1 变量提升与闭包：经典题目里的细节陷阱

试卷第一道选择题大概是这样的：给出以下代码，问输出结果是什么。

for (var i = 0; i < 5; i++) { setTimeout(function () { console.log(i); }, 0); }

这个题几乎是前端笔试的“开场白”了，答案是连续输出5个5。考点很清晰：var声明的变量没有块级作用域，循环结束后全局作用域里i的值已经是5，所有setTimeout回调执行时访问的都是同一个i。

但关键在于，这道题往往是连环问。后面会追问：如何改成输出0、1、2、3、4？这里就有几种答法：

• 最简单直接的方式是把var改成let，利用块级作用域为每次循环绑定独立的值。
• 也可以用IIFE（立即执行函数）包裹setTimeout，把i作为参数传入形成闭包。
• 还可以用bind方法传参：setTimeout(console.log.bind(null, i), 0)。

答题时建议把三种方式都写出来，并各用一句话说明原理。这比只写一种答案更能体现对闭包作用域的理解深度，面试官后续追问的空间也更大。

2.2 事件循环机制：输出顺序题要画图作答

另一道比较有代表性的题目是考察事件循环的：

console.log(1); setTimeout(function () { console.log(2); }, 0); Promise.resolve().then(function () { console.log(3); }); console.log(4);

正确输出顺序是1、4、3、2。这道题考的是宏任务与微任务的执行顺序：同步代码先执行，微任务在本次事件循环末尾执行，宏任务在下一轮事件循环执行。

我的答题建议是：遇到这类题不要只在脑子里过，一定要在草稿纸上画出任务队列的变化过程。先写同步代码的执行顺序，再分别标注宏任务队列和微任务队列中新增了什么，最后模拟事件循环的调度过程。画完之后，答案基本不会错。

当时这个模块还考了原型链的查找规则、this指向的四种绑定方式、==与===的隐式转换规则等。这些都属于前端八股文的高频考点，没有太多技巧，就是要把基础概念吃透。我在准备阶段把MDN上关于JavaScript继承、类型转换、作用域的文档重新过了一遍，再配合刷题，效果比直接背面试题集要好得多。

2.3 浏览器缓存与渲染机制：安全厂商同样重视页面性能

浏览器相关的题目里，有一道关于缓存策略的分析题，要求简述强缓存和协商缓存的区别，以及对应的HTTP头字段。

这道题本身不难，但考察范围很广。完整的回答应该包括：

• 强缓存由Cache-Control和Expires控制，命中时不会向服务器发送请求。
• 协商缓存由Last-Modified/If-Modified-Since和ETag/If-None-Match控制，需要向服务器发送请求确认资源是否变更。
• 两者的关系是：强缓存优先于协商缓存，强缓存未命中时才可能走协商缓存。
• 实际项目中，静态资源（JS、CSS、图片）通常设置长缓存时间配合文件名hash实现更新，HTML页面通常设置为协商缓存或禁用缓存。

这题我后面在面试中被问到过变体：如果强缓存和协商缓存同时存在，服务器返回304时，浏览器从哪里读取资源？答案是浏览器会从本地缓存中读取资源，304只是一个状态通知，并不携带资源实体。

浏览器渲染机制则考了回流与重绘的区别，以及两者的性能差异。答题时可以举具体的触发场景：改变元素的宽度、高度、位置会引发回流；改变颜色、背景、可见性只会触发重绘。优化思路包括：批量修改DOM、使用display: none离线操作、用transform代替位置动画等。这个考点虽然常见，但在安全产品的可视化大屏场景中非常实用，因为大屏页面往往有大量实时刷新的数据图表，对渲染性能要求很高。

3. 前端安全专项：XSS、CSRF与CSP的完整答题模板

这是我当时答卷里比较有特色、也是奇安信这类安全厂商相对更看重的板块。这里我结合卷面题目，把完整答题套路整理出来。

3.1 XSS跨站脚本攻击：从危害到防御的完整链路

试卷里有一道简答题：什么是XSS攻击？简述主要类型及防御措施。

这道题由于是安全厂商出的，我建议不要只答概念，要按“原理、分类、危害、防御”四个层次展开：

首先是原理。XSS的核心是攻击者把恶意脚本注入到网页中，在用户浏览器端执行。由于浏览器无法区分脚本来自开发者还是攻击者，恶意脚本就获得了和合法脚本同等的执行权限。

然后是分类。存储型XSS（恶意脚本持久化存储在服务端，所有访问页面的用户都可能中招）、反射型XSS（恶意脚本通过URL参数反射回页面，需要诱导用户点击恶意链接）、DOM型XSS（通过修改页面DOM节点形成的XSS，纯前端安全问题，服务端无法感知）。

接着是危害。盗取用户Cookie窃取会话、伪造用户操作、钓鱼攻击、传播恶意代码等。

最后是防御。这是关键拿分点，需要答全面:

• 输入过滤：对用户输入进行白名单校验，转义HTML标签、属性、URL中的特殊字符。
• 输出编码：在将数据插入HTML页面时，根据上下文（HTML标签内、属性内、JavaScript内）选择合适的编码方式。
• 使用CSP（内容安全策略）：限制页面资源的加载来源，即使脚本被注入也无法执行，这是纵深防御的关键手段。
• HttpOnly Cookie：将Cookie标记为HttpOnly，JavaScript无法读取，有效缓解会话劫持风险。

我当时在答这题时额外补充了Vue和React框架层面的注意事项：Vue模板默认会转义插值内容，v-html指令则会跳过转义，直接渲染原始HTML，使用时需要确保内容可信；React中dangerouslySetInnerHTML同理。这些细节能让面试官感受到你不仅懂安全理论，还有实际项目中的安全意识。

3.2 CSRF跨站请求伪造：校验Referer还不够

另一道安全题是：CSRF的攻击原理是什么？如何防御？

CSRF的答题要点是：攻击者诱导用户在已登录的浏览器中发出伪造的跨站请求，由于请求携带用户的Cookie（尤其是未启用SameSite属性时），服务端无法判断请求是否由用户主动发起。

防御措施可以从这几个层面答：

• 使用CSRF Token：在页面表单中嵌入服务端生成的随机Token，提交请求时校验Token是否匹配。
• 校验Referer/Origin字段：拒绝来源不明的跨站请求。
• 设置SameSite Cookie属性：Lax模式可以阻止跨站请求携带Cookie，Strict模式则完全禁止跨站携带。
• 双重Cookie验证：在请求中附带Cookie中的随机值和自定义请求头中的值，服务端比对是否一致。

特别提示一下：奇安信这类安全公司的笔试和面试中，你答出“只校验Referer不可靠”会是加分项。原因很简单：Referer在某些场景下会被浏览器省略或篡改，比如从HTTPS页面跳转到HTTP页面时，浏览器不会发送Referer头。这种防御属于降低安全等级的做法，仅作为辅助手段。

3.3 同源策略与跨域方案：越基础越要说得准

同源策略几乎是所有安全题的基础。试卷里考了一道判断题：浏览器同源策略中，判断两个URL是否同源需要满足哪些条件？答案是协议、域名、端口三个全部相同。

现代浏览器对同源策略的管理其实有细化的地方，我把答题时用到的对照表整理出来：

跨域解决方案则考了CORS、JSONP、代理转发、postMessage，以及nginx反向代理等。对于安全厂商的笔试，建议重点展开CORS的预检机制：非简单请求会先发送一个OPTIONS请求，服务端确认允许跨域后，浏览器才会发送实际请求。能够说清楚预检请求的触发条件和响应头配置，这题基本就是满分水平。

4. 框架与工程化：Vue源码原理和安全配置实践

奇安信前端工程师日常工作大量使用Vue，笔试试卷中框架和工程化的占比不算低，而且很看重“能不能真正理解框架原理并解决工程问题”。

4.1 响应式原理：从数据变化到视图更新

框架相关的简答题，最核心的一道是：简述Vue 2的响应式原理，以及Vue 3相比Vue 2的改进。

Vue 2部分要从这几个环节讲清楚：

• 数据初始化：遍历data对象的属性，用Object.defineProperty将它们转为getter/setter。
• 依赖收集：组件渲染过程中访问数据时，触发getter，将当前watcher添加到该属性的依赖列表中。
• 派发更新：数据变化时触发setter，通知依赖列表中所有watcher执行更新，最终触发视图渲染。

Vue 3部分则要提到：改用Proxy实现响应式，可以拦截对象属性的添加、删除以及数组索引变化等，解决了Vue 2中无法通过this.$set监听新增属性、数组变更检测不完整等痛点；同时配合ref和reactive的API设计，让响应式系统的使用更灵活。

进阶答题时可以补充：Vue 3的Proxy代理是懒代理，即访问到某个层级的对象时才对该层级做代理，因此初始化性能比Vue 2的递归遍历要好。这个点说明你读过源码相关内容而不是只背概念，在面试中很容易引起面试官的好感。

4.2 构建工具与代码规范：安全公司也在意依赖安全

工程化部分考了一道Webpack配置题：如何将静态资源开启长缓存、如何做代码分割。这里就不重复基础配置了，重点说一个我在实际答题时主动补充、后来被面试官当场追问的点：依赖安全与供应链攻击。

奇安信作为安全公司，对第三方依赖的安全非常敏感。前端项目会使用npm或yarn安装大量第三方包，如果某个依赖被投毒（恶意代码通过正常发布流程混入开源包），影响面可能是整个产品线。我在回答时提到：生产环境构建前应执行npm audit检查已知漏洞，并在CI/CD流水线中接入依赖扫描工具；同时建议使用锁文件(package-lock.json或yarn.lock)固定依赖版本，配合私有npm镜像仓库对依赖进行统一管控。

这个额外补充其实超出了普通前端工程师的认知范围，但在安全厂商的场景下特别加分，建议准备面试的同学一定要有这方面的知识储备。

4.3 生命周期与组件通信：一个高频简答的完整答法

试卷里还有一道Vue生命周期相关的简答题，要求说明created和mounted的区别。

参考答案可以分为三个层次：

• 执行时机不同：created在实例创建完成后立即调用，此时数据和事件已初始化，但DOM还未挂载；mounted在模板渲染并将真实DOM挂载到页面后调用。
• 可用能力不同：created中不能访问this.$el，mounted中可以操作真实的DOM节点。
• 使用场景不同：created适合做接口数据拉取、初始化非DOM依赖的数据；mounted适合做需要依赖DOM 的操作，比如初始化图表、绑定第三方库事件等。

组件通信方面，我建议把以下方式整理成答题清单：props和$emit（父子组件）、$refs（父访问子实例）、provide/inject（跨层级依赖注入）、eventBus（非父子组件通信）、Vuex/Pinia（状态管理）。每个都写一句使用场景，面试时按需展开即可。

5. 编程题实录：从思路推导到完整AC代码

这套试卷的编程题有两道：一道是算法题，一道是场景题。下面是我当时写的解题过程和最终AC代码，附上完整的思路推导。

5.1 算法题：数组中的第K个最大元素

题目描述：给定一个未排序的整数数组，找出其中第K个最大的元素。例如，数组[3,2,1,5,6,4]，K=2时，返回5。

看到这道题，最先想到的当然是先排序再取下标，时间复杂度是O(n log n)。不过笔试环境里仅仅这样写并不能体现编码能力，我选择了用快速选择算法，平均时间复杂度可以降到O(n)。

快速选择的思想和快速排序很像：每次选一个基准值（pivot），把数组分为小于基准值和大于基准值的两部分，然后根据基准值在排序后数组中的位置，决定继续在左半边还是右半边查找。

/** * @param {number[]} nums * @param {number} k * @return {number} */ const findKthLargest = function (nums, k) { const targetIndex = nums.length - k; const quickSelect = (left, right) => { // 基准值取最右侧元素 const pivot = nums[right]; let storeIndex = left; // 将小于等于pivot的元素移到左侧 for (let i = left; i < right; i++) { if (nums[i] < pivot) { [nums[storeIndex], nums[i]] = [nums[i], nums[storeIndex]]; storeIndex++; } } // 将pivot放到正确位置 [nums[storeIndex], nums[right]] = [nums[right], nums[storeIndex]]; if (storeIndex === targetIndex) { return nums[storeIndex]; } else if (storeIndex < targetIndex) { return quickSelect(storeIndex + 1, right); } else { return quickSelect(left, storeIndex - 1); } }; return quickSelect(0, nums.length - 1); };

写代码时要注意几个易错点：边界条件是left <= right还是left < right，基准值交换的时机，以及在查找右半边时storeIndex + 1而不是storeIndex，否则可能死循环。我当时提交后特意用[3,3,3,3,3]这种全重复数组做了自测，确保算法不会因为值相等而异常。

5.2 场景题：并发请求控制器的实现

编程题第二题比较有意思，考察的是实际工程中很常见的场景：实现一个并发请求控制器，限制同时只能有limit个请求在执行，其余请求排队等待。

这道题的考点是：手写Promise并发控制、异步队列管理、错误处理。我当时给的解法如下：

/** * 并发请求控制器 * @param {Array<Function>} tasks - 每个任务是一个返回Promise的函数 * @param {number} limit - 最大并发数 */ async function runWithConcurrency(tasks, limit) { const results = new Array(tasks.length); let currentIndex = 0; const worker = async () => { while (currentIndex < tasks.length) { const index = currentIndex; currentIndex++; try { results[index] = await tasks[index](); } catch (e) { results[index] = e; } } }; const workerCount = Math.min(limit, tasks.length); const workers = []; for (let i = 0; i < workerCount; i++) { workers.push(worker()); } await Promise.all(workers); return results; }

这个实现的关键在于：通过一个共享的currentIndex指针，让每个worker空闲时都去取下一个待执行的任务，而不是固定分配任务。这样即使某个任务执行得特别快，也不会出现部分worker空转的情况，整体吞吐量是最高的。

错误处理上，我用try/catch捕获每个任务的异常，防止某个任务失败导致整个控制器中断。这是实际项目中非常重要但很多候选人在笔试时容易忽略的点。

6. 高频问题与现场复盘：题目之外的拿分关键

最后整理几个当时笔试和后续面试中反复出现、但题目本身并没有直接考的延展问题。这些问题往往是面试官根据你的笔试卷面追问出来的，提前准备好会很加分。

6.1 简历项目和笔试题的联动追问

我笔试时在安全相关的简答题里写到了CSP，面试官就顺着追问：你们的项目里如何配置CSP？如果使用了style-src限制内联样式，但页面里又用了动态计算的样式属性，如何处理？

这个问题其实在考CSP的'unsafe-inline'和'nonce'机制。我答的是：给合法的内联脚本和样式添加nonce属性，并在CSP中配置'nonce-xxx'，这样浏览器只允许带有正确nonce的内联内容执行。如果你对nonce机制不熟悉，建议提前补一下，这是CSP相关提问中最高频的深入问题之一。

另一个追问方向来自工程化：为什么代码分割能提升首屏加载速度？我在笔试题中提到了动态import做路由懒加载，面试官就让我解释动态import的底层实现原理。这已经从工程应用问到编译原理层面了，如果答不上来不用慌，如实说“这个我了解不深，我目前的理解是……”然后给出你已知的部分，至少能展示诚实和学习意愿。

6.2 从错误答案中学到的排查思路

我在这套试卷上有一个记忆深刻的失误：一道关于==隐式转换的选择题，我判断错了[] == ![]的结果。

具体来看这个表达式的求值过程：

![]的结果是false（空数组是truthy，取反为false），因此原式变成[] == false；

按规范，[]会先转成字符串""，然后"" == false；

之后布尔值转数字false变为0，字符串""变为数字0；

最终是0 == 0，结果为true。

整个过程涉及ToPrimitive、ToNumber、ToBoolean三层隐式转换规则。当初我在考场上心里想的是“数组不等于布尔值”，结果就跳坑了。这种题目的价值不在于让你记住“结果为true”，而是理解隐式转换的执行顺序。面试中考官会顺着问：实际开发中如何避免这类隐式转换问题？答案很简单：统一使用===，减少类型转换带来的不确定性。

6.3 考试时间分配与心态调整

最后聊一个不那么技术、但同样影响成绩的话题：时间分配。

这套试卷题量不是特别大，但简答题写起来很耗时。我当时的策略是：

• 选择题控制在20分钟以内，遇到需要计算的题快速在草稿纸上推算，不确定的先标记，不纠结。
• 简答题先列回答大纲，用关键词提纲挈领，再展开成完整句子。这样即使时间紧张，每道题都有清晰的拿分要点。
• 编程题留足40分钟以上。先写功能正确的基础版本，再考虑优化。比如第K大元素，可以先写排序版本保证AC，再补充快速选择版本展示优化能力。
• 预留10分钟检查。重点看选择题有没有看错选项、编程题边界条件是否都有处理。

这个时间分配方案不一定适合所有人，但核心原则可以复用：越靠前的客观题越要控制时间，编程题宁可写得朴素也要保证通过率，简答题宁可结构清晰也不要在某一道题上过度堆砌字数。

写在最后的个人体会

整套卷子做下来，我最深的感受是：奇安信前端方向笔试题并没有在“难”上做文章，而是更看重你是不是一个“基础扎实、思维严密、有安全意识”的工程师。如果你是准备校招的同学，我的建议是不要只刷面试题，而是把JavaScript语言规范、浏览器原理、Web安全这些基本功真正吃透。安全厂商给你的反馈往往不是“你刷题多”，而是“你理解得深、表达得清楚、意识在线”。

最后分享一个小技巧：笔试结束后，建议立刻把题目和你的答案记录下来。一方面是为了复盘，另一方面是为了后续面试准备——奇安信的技术面会拿着你的笔试卷追问，要是连自己当时写了什么、为什么这么写都说不清楚，那才是真的亏大了。祝各位都能顺利拿到心仪的Offer。