实验介绍
一般来说面试官会考察面试者两大块内容，一大块是我们前几个实验学习的基础知识，它是我们做项目的基础；另一块就是项目问题。项目问题往往是衡量一个面试候选人的重要指标，基础知识大家都可以花些时间背下来然后理解理解基本上面试时也可以答的七七八八，但是项目问题只有你在工作中实际遇到并解决了，你才能在面试中说出东西来，这类问题往往没有固定答案，但却有一定的套路，下面我们就来学习哪些项目问题是面试中爱问的，以及回答此类问题的基本思路。
知识点
项目亮点
在面试完基础知识后，面试官经常会这样问，我看你简历上写了很多项目，你能聊聊 xxx 项目有哪些亮点吗？ 这个时候如果没有提前准备你肯定会一脸懵。
那这类问题我们该如何回答呢？首先需要明确一点，项目亮点并不一定说是项目难点（当然项目难点可以当做项目亮点）。
比如我做的项目就是增删改查，简单的后台管理系统或者说简单的 H5 页面，开发起来没有啥难度，那我该如何给面试官说呢？这个时候我们就需要往细节方面来说，比如我做了一个 H5 页面，但是我百分百还原了设计稿，这就可以当作项目亮点。对于前端开发而言，百分百还原设计稿难吗？并不是十分的难吧，只要我们多注重些细节肯定可以做到，但是在现实开发过程中我们有几个前端开发做到这一点了呢？
所以说项目亮点其实就是在说项目的不同点，比如别人在开发这个功能的时候会怎么做，而我开发这个功能时会怎么做并且会比别人做的更好，这就是你项目的亮点。并不是说项目很难才能算得上亮点，下面我给大家总结几个常用的可以拿来当作项目亮点的点，希望可以抛砖引玉，激发你更多的思考。
- 后台管理系统列表比较多，自己封装了一个根据 JSON 生成列表的组件，大大提高列表开发效率；
- 把公司所有登录页面的登陆逻辑封装了一下，做了个公用的登陆组件，提高了开发人员的效率；
- 自己开发或者配置了 ESlint，规范了开发流程；
- 做某个功能的时候考虑到用户量大的时候会出现 xxx 问题，并通过 xxx 方案优化了这个问题。
项目优化，及取得的效果
这个问题也是面试官常问的问题，而且可能问的非常细致，这取决于面试官是不是优化过这方面的问题，或者说面试官对这方面的问题感不感兴趣。
比如你在简历中写到通过懒加载优化了图片加载效率，那面试官可能会问：你能具体说下你是使用什么技术实现的懒加载？
这个时候你可以这样回答：我实现懒加载的原则就是优先加载可视区域的内容，其他部分等进入了可视区域再加载，具体的实现原理是一张图片就是一个标签，浏览器是否发起请求图片是根据 <img> 的 src 属性，在图片没有进入可视区域时，先不给 <img> 的 src 赋值，这样浏览器就不会发送请求了，等到图片进入可视区域再给 src 赋值。通过这样的优化方案把首屏的加载时间从原来的 3 秒优化到了现在的 0.5 秒。
记住最后一定要说出你优化后的效果，要量化。最好直接把优化前后的数据写在简历上，这样更直观，下面给大家总结下常规项目的优化方案，当然在具体项目中需要具体分析。
- 关于首屏优化：
- 减少项目体积，webpack 打包优化，大文件分割，无用代码去除
- 路由按需加载
- 首页图片懒加载
- 大文件上传优化
- 断点续传
- 网络检测
- 切片上传
- 兼容性优化
- babel 转化，把 ES6 代码转化为 ES5
前端安全
安全问题对每个系统都特别重要，但是安全问题归根结底更多的是后端上的问题，前端主要是配合，但是前端也需要把我们可以做的部分做好。下面总结下前端常见的安全问题及防御策略。
- XSS 攻击
XSS 攻击全称跨站脚本攻击（Cross-Site Scripting），为区别 CSS，在安全领域叫做 XSS。攻击者通过在目标网站上注入恶意脚本并运行，获取用户的敏感信息如 Cookie、SessionID 等，影响网站与用户数据安全。 XSS 攻击的本质就是攻击者提交恶意代码，浏览器执行恶意代码。那防御起来也就是根据这两个方面进去防御。
XSS 攻击防御：
- 输入输出检查
- 避免内联事件
- 富文本类使用标签白名单
- 增加验证码，防止脚本冒充用户提交危险操作
- 通过 CSP、输入长度配置、接口安全措施等方法
- CSRF 攻击
CSRF（Cross-site request forgery）跨站请求伪造，攻击者盗用受害人身份，以受害人的名义发送恶意请求。 其本质是重要操作的所有参数都是可以被攻击者猜测到的，攻击者只有预测出 URL 的所有参数与参数值，才能成功地构造一个伪造的请求；反之，攻击者将无法攻击成功。
CSRF 攻击要素：
- 攻击一般发起在第三方网站，被攻击的网站无法防止攻击发生；
- 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作，而不是直接窃取数据；
- 整个过程攻击者并不能获取受害者登录凭证，只是冒用；
- 跨站请求可以是图片 URL、超链接、CORS、Form 提交等。
CSRF 攻击防御：
- 阻止不明外域的访问
- 提交时要求附加本域才能获取的信息（接口添加 token 验证）
- SQL 注入
通过 Web 应用接口注入 SQL 语法，破坏原有 SQL 结构，达到攻击行为。 如果网站存在注入漏洞，相当于将数据库直接暴露在攻击者面前 根据注入位置及方式不同分为 POST 注入、GET 注入、cookie 注入、盲注、延时注入、搜索注入、base64 注入等。
SQL 注入要素：
- 跳过账户权限验证达到越权
- 获取数据库关键信息从而进行脱库
- 特别情况下还可以修改数据库内容，如果数据库权限分配存在问题，攻击者可以通过 SQL 注入直接获取 webshell 或者服务器系统权限
SQL 注入防御：
- 检查数据格式
- 使用数据库特定的敏感字符转义函数把用户提交数据进行转义
- 权限限制
- 日志处理
- 数据库操作失败的时，尽量不将原始错误日志返回，如类型错误、字段不匹配等，把代码里的 SQL 语句暴露出来，以防止攻击者利用错误信息进行 SQL 注入
- 点击劫持
点击劫持注入要素：
- 诱使用户点击看似无害的按钮（实则点击了透明 iframe 中的按钮）；
- 监听鼠标移动事件，让危险按钮始终在鼠标下方；
- 使用 HTML5 拖拽技术执行敏感操作（例如 deploy key）。
点击劫持预防策略：
- 服务端添加 X-Frame-Options 响应头,这个 HTTP 响应头是为了防御用 iframe 嵌套的点击劫持攻击。这样浏览器就会阻止嵌入网页的渲染；
- JS 判断顶层视口的域名是不是和本页面的域名一致，不一致则不允许操作，
top.location.hostname === self.location.hostname； - 敏感操作使用更复杂的步骤（验证码、输入项目名称以删除）。
打包工具
如果宏观的说对前端发展影响最大的技术是什么的话 ，我感觉应该是在 node 发展下孕育出的打包工具，如项目打包常用的 webpack，框架打包常用的 rollup，以及 vue3 新出的打包工具 vite，都极大程度的推动了前端的发展。下面我们就来总结下这些打包工具在面试中常考的点都有哪些。
- 你知道 webpack 的作用是什么吗？
从官网上的描述我们其实不难理解，webpack 的作用其实有以下几点：
- 模块打包。可以将不同模块的文件打包整合在一起，并且保证它们之间的引用正确，执行有序。利用打包我们就可以在开发的时候根据我们自己的业务自由划分文件模块，保证项目结构的清晰和可读性；
- 编译兼容。在前端的“上古时期”，手写一堆浏览器兼容代码一直是令前端工程师头皮发麻的事情，而在今天这个问题被大大的弱化了，通过 webpack 的 Loader 机制，不仅仅可以帮助我们对代码做 polyfill，还可以编译转换诸如
.less,.vue,.jsx这类在浏览器无法识别的格式文件，让我们在开发的时候可以使用新特性和新语法做开发，提高开发效率； - 能力扩展。通过 webpack 的 Plugin 机制，我们在实现模块化打包和编译兼容的基础上，可以进一步实现诸如按需加载，代码压缩等一系列功能，帮助我们进一步提高自动化程度，工程效率以及打包输出的质量。
- webpack 常见配置都有哪些？
- 模式(mode) 通过选择 development, production 或 none 之中的一个，来设置 mode 参数，你可以启用 webpack 内置在相应环境下的优化。其默认值为 production；
- 入口(entry) 指示 webpack 应该使用哪个模块，来作为构建其内部 依赖图(dependency graph) 的开始；
- 输出(output) 告诉 webpack 在哪里输出它所创建的 bundle，以及如何命名这些文件；
- loader webpack 只能理解 JavaScript 和 JSON 文件，这是 webpack 开箱可用的自带能力。loader 让 webpack 能够去处理其他类型的文件，并将它们转换为有效 模块，以供应用程序使用，以及被添加到依赖图中；
- 插件(plugin) loader 用于转换某些类型的模块，而插件则可以用于执行范围更广的任务。包括：打包优化，资源管理，注入环境变量。
- 简单描述一下编写 loader 的思路。
Webpack 内部默认也只能够处理 JS 模块代码，在打包过程中，会默认把所有遇到的文件都当作 JavaScript 代码进行解析，因此当项目存在非 JS 类型文件时，我们需要先对其进行必要的转换，才能继续执行打包任务，这也是 Loader 机制存在的意义。
Loader 使用如下所示：
// webpack.config.js
module.exports = {
// ...other config
module: {
rules: [
{
test: /^your-regExp$/,
use: [
{
loader: "loader-name-A",
},
{
loader: "loader-name-B",
},
],
},
],
},
};
通过配置可以看出，针对每个文件类型，loader 是支持以数组的形式配置多个的，因此当 Webpack 在转换该文件类型的时候，会按顺序链式调用每一个 loader，前一个 loader 返回的内容会作为下一个 loader 的入参。因此 loader 的开发需要遵循一些规范，比如返回值必须是标准的 JS 代码字符串，以保证下一个 loader 能够正常工作，同时在开发上需要严格遵循“单一职责”，只关心 loader 的输入以及对应的输出。
- 简单描述一下编写 plugin 的思路。
如果说 Loader 负责文件转换，那么 Plugin 便是负责功能扩展。Loader 和 Plugin 作为 Webpack 的两个重要组成部分，承担着两部分不同的职责。
Plugin 的开发和开发 Loader 一样，需要遵循一些开发上的规范和原则：
- 插件必须是一个函数或者是一个包含 apply 方法的对象，这样才能访问 compiler 实例；
- 传给每个插件的 compiler 和 compilation 对象都是同一个引用，若在一个插件中修改了它们身上的属性，会影响后面的插件；
- 异步的事件需要在插件处理完任务时调用回调函数通知 Webpack 进入下一个流程，不然会卡住。
了解了以上这些内容，想要开发一个 Webpack Plugin，其实也并不困难。
class MyPlugin {
apply(compiler) {
// 找到合适的事件钩子，实现自己的插件功能
compiler.hooks.emit.tap("MyPlugin", (compilation) => {
// compilation: 当前打包构建流程的上下文
console.log(compilation);
// do something...
});
}
}
- 谈谈 Webpack 和 Rollup 的区别。
Rollup 是一个 JavaScript 模块打包器，可以将小块代码编译成大块复杂的代码，Webpack 偏向于应用打包，rollup.js 更专注于 Javascript 类库打包。 总结来说：Webpack 适合打包应用，比如我们做的各种项目的打包，Rollup 更加适合打包类库，比如我们熟悉的 Vue、React 都是使用 Rollup 打包的。
- Vite 为什么这么快，工作原理是什么。
作者的原话是这样说的：
Vite，一个基于浏览器原生 ES imports 的开发服务器。利用浏览器去解析 imports，在服务器端按需编译返回，完全跳过了打包这个概念，服务器随起随用。同时不仅有 Vue 文件支持，还搞定了热更新，而且热更新的速度不会随着模块增多而变慢。针对生产环境则可以把同一份代码用 rollup 打包。虽然现在还比较粗糙，但这个方向我觉得是有潜力的，做得好可以彻底解决改一行代码等半天热更新的问题。
总结下就是说 Vite 之所以这么快就是因为利用了浏览器去解析 ES 模块，也就没有了 webpack 繁琐的编译过程。Vite 的基本实现原理，就是启动一个 koa 服务器拦截浏览器请求 ES 模块的请求。通过路径查找目录下对应文件的文件做一定的处理最终以 ES 模块格式返回给客户端。
微前端及服务端渲染
在面试的时候面试官可能给你聊些前端比较前沿的技术，看看你是否关注新技术的发展，通常这类问题并没有标准答案，更多得是面试官想看看你自己对技术的个人理解。比如面试官会这样问：
1. 最近微前端比较火，谈谈你对微前端的理解。
首先可以谈谈为什么会出现微前端这个概念，其实这个概念还是从后端微服务概念演变而来，主要解决的问题就是如何多个团队公共开发一个巨型项目，比如一个项目有几百个页面，好几个子模块，每个子模块都要找对应的团队来完成，每个团队使用的技术框架可能不一样，这个时候使用微前端就再合适不过了。
使用微前端在技术上最先要解决的问题就是如果把各个模块进行隔离，在早期我们都是使用 ifarme 标签去做这件事情，ifarme 虽然天然的支持模块的隔离，但是各个模块通信变得十分麻烦，再者体验上也不是很好。所以最后演变出来了微前端的一些解决方案及框架。
我个人认为，微前端的核心还是在于项目的拆分，比如如何把一个巨型项目合理的拆分成几个小模块，同时每个模块之间如何通信。这才是我们需要关心的地方，至于微前端框架其实并不是很难，比如目前业界比较通用的微前端解决方案 qiankun，我们可以直接拿别人做好的现有框架去搭建自己的项目，框架可以帮你从 0 到 1 创建一个微前端项目，但是却不能帮你合理的拆分业务。
2. 谈谈你对服务端渲染的看法。
这也是前端比较火的一个概念，也是在某个特定场景下才会使用到的技术，首先我们来看说下服务端渲染需要解决的问题：
- 首屏渲染快
前端页面直接在服务端渲染好返回给前端，前端只需要 append 到页面上即可，大大提高前端渲染的速度。
- 利于 SEO
后端返回的直接是 HTML，有利于爬虫对数据的搜集，所以有利于 SEO
但是我认为很多项目并不需要服务端渲染这项技术，或者说我们有更好的策略去解决现有的问题，比如 解决首屏渲染问题，我们可以用预加载的方式，SEO 我们可以使用预渲染的方式去解决。虽然在理论层面上没有服务端渲染好，但是在大多数项目中这已经够用。
再者服务端渲染大大增加了项目的复杂度和维护成本，渲染都放在服务端了也大大增加了服务器的压力，这在大部分项目中并不适用。
那什么项目需要使用服务端渲染呢，比如有一个 toC（面向用户）的项目，首屏的加载速度直接影响这个项目的成败，或者直接影响这个项目所带来的经济效益，那我们想都不用想，直接使用服务端渲染，但是这样的项目还是很少。
3. Vue 和 React 你更喜欢哪一个呢？
这个问题就更加开放了 你可以直接说自己喜欢 Vue 或者喜欢 React，但是你要说出你喜欢的理由，并且理由要充分。比如你可以这样回答，我比较喜欢 Vue 原因有以下几点：
- Vue 的组件设计更加符合对前端的认知，更加容易上手；
- Vue API 比较好用，使用起来比较简单，开发相同功能 Vue 写的代码比 React 写的代码要少的多；
- Vue 项目更加容易维护，而 React 灵活性太大，每个人都要自己的代码风格，不利于团队项目的维护。
实验总结
本实验中我们学习了面试中常问的项目相关问题，这种问题大部分都比较开放需要我们在工作中持续的积累，每次遇见问题都积极终结，对问题不能浅尝辄止，要做到刨根问底，这样我们解决问题的能力才能不断提升。
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
