前端开发

转自： 平凡希 老师 https://www.cnblogs.com/xiaoxi/ SpringMVC的工作原理图： SpringMVC流程 1、 用户发送请求至前端控制器DispatcherServlet。 2、 DispatcherServlet收到请求调用HandlerMapping处理器映射器。 3、 处理器映射器找到具体的处理器(可以根据xml配置、注解进行查找)，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。 4、 DispatcherServlet调用HandlerAdapter处理器适配器。 5、 HandlerAdapter经过适配调用具体的处理器(Controller，也叫后端控制器)。 6、 Controller执行完成返回ModelAndView。 7、 HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet。 8、 DispatcherServlet将ModelAndView传给ViewReslover视图解析器。 9、 ViewReslover解析后返回具体View。 10、DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图中）。 11、 DispatcherServlet响应用户。 组件说明：

什么是跨域？ 跨域是指一个域下的文档或脚本试图去请求另一个域下的资源，这里跨域是广义的。 广义的跨域： 1.) 资源跳转： A链接、重定向、表单提交 2.) 资源嵌入： <link>、<script>、<img>、<frame>等dom标签，还有样式中background:url()、@font-face()等文件外链 3.) 脚本请求： js发起的ajax请求、dom和js对象的跨域操作等 其实我们通常所说的跨域是狭义的，是由浏览器同源策略限制的一类请求场景。 什么是同源策略？ 同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。 同源策略限制以下几种行为： 1.) Cookie、LocalStorage 和 IndexDB 无法读取 2.) DOM 和 Js对象无法获得 3.) AJAX 请求不能发送 常见跨域场景 URL 说明 是否允许通信 http://www.domain.com/a.js http://www.domain.com/b.js 同一域名，不同文件或路径 允许 http://www.domain.com/lab/c

重复优化的思考 这段时间对项目做了一次整体的优化，全站有了20%左右的提升（本来载入速度已经1.2S左右了，优化度很低），算一算已经做了四轮的全站性能优化了，回顾几次的优化手段，基本上几个字就能说清楚： 传输层面：减少请求数，降低请求量执行层面：减少重绘&回流 传输层面的从来都是优化的核心点，而这个层面的优化要对浏览器有一个基本的认识，比如： ① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染 ③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高 衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化： 减少请求数 ① 合并样式、脚本文件 ② 合并背景图片 ③ CSS3图标、Icon Font 降低请求量 ① 开启GZip ② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码 ③ 图片无损压缩 ④ 图片延迟加载 ⑤ 减少Cookie携带 很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如： ① 缓存为王，对更新较缓慢的资源&接口做缓存

　众所周知，目前市场上 最火的五大浏览器 是：google chrome、firefox（FF）、Internet Explorer（IE）、safari、opera。 　　 　他们相对应的 内核 是什么呢？ 　　 谷歌浏览器 ：Google Chrome，谷歌浏览器之前一直使用苹果的webkit内核，但是现在它与苹果内核分道扬镳，自己开创了新的blink内核，这个内核也在被欧鹏（opera浏览器）共同采用和开发； 　　 火狐浏览器 ：Mozilla Firefox ，内核是Gecko； 　　 opera浏览器 ：内核是blink； 　　 Safari浏览器 ：使用的是苹果公司自己的内核webkit； 　　 IE浏览器： 微软出品的浏览器，IE4以上版本都是Trident内核。由于垄断性，IE在很长一段时间内没有更新，导致两个后果：一是IE与W3C标准脱节，二是Trident内核大量的bug问题没得到及时解决。所以这就给了其他浏览器机会，比如firefox等。也正是这些原因，使Web前端开发人员大费周折，特别是IE6正处在新旧交替的关键地方（已经逐渐被舍弃）。 　　当然除了这五大浏览器之外，市场上还有很多，例如： 　　 搜狗浏览器 ：兼容模式（IE：Trident）和高速模式（webkit）； 　　 遨游浏览器 ：兼容模式（IE：Trident）和高速模式（webkit）； 　　

对于一个前端应用，或者说是一个 Node 应用，在 CICD pipeline 中，无论是构建，测试，部署，其中必不可少的环节就是依赖安装: npm i 。 npm i 不仅是必不可少的环节，而且很可能也是耗时最长的一个环节。 打蛇打七寸，优化应该从瓶颈处开始，如果能从依赖安装下手，将能极大地缩短部署时间，提高产品交付效率，改善 DevOps 流程，从而促进敏捷开发。 CI 环境中的优化不同于本地开发环境，其中最大的不同在于: 在本地环境中安装依赖是有状态的，如 node_modules ， ~/.npmrc ， ~/.npm 一系列硬盘目录及文件，无不构成状态。而在生产环境中，往往结合 CICD 工具，每次分配的 Runner 不一定是一台服务器(容器)，往往被视为无状态，因而无法有效利用缓存而导致 CI 中部署用时过长。 但也正因为 CICD Runner 的无状态化，这意味着你只要参考构建脚本，如 .gitlab-ci.yaml ， .travis.yaml 或者 .github/workflows/deploy.yaml ，就可以从零把项目跑起来，而避免过多在熟悉新项目时求助他人。 不同的部署方式，不同的持续集成工具有不同的实践方法，但优化的原理大同小异。 如果嫌文章太长，直接直接拉到最下方看总结 只安装有必要的库 npm install

前端开发人员具体需要的技能（最全面） 1. 要有 比较好的计算机基础 　　这里的计算机基础指的是数据结构与算法，操作系统，编译原理，计算机网络等等。虽然相对于其他方向而言，前端在工作中用到计算机基础的地方可能少一点，但是无论大小厂，招实习生其实都是为正式招聘做储备，所以会比较希望招将来有更大发展空间的人。 如果你具备比较好的计算机基础素养，那么以后在拓展到其他领域（WebGL —— 计算机图形学，Node.js 底层 —— 操作系统，JS 引擎和各种预编译工具—— 编译原理, etc.）的时候会更快上手。另外有一些公司对前端的概念不局限于 Web 前端，也包括移动端偏前端的部分，这里也需要你有比较好的计算机基础才能做好。前端领域有很多人已经不满足于造轮子，直接跑去造语言了，如果你编程基础够好，接触过各种形形色色的编程语言和范式，再上手这些东西也会方便些（比如Ruby/Python->CoffeeScript，Haskell->LiveScript）。 　　虽然也有很多地方为了招到足够多能来干活的前端会降低对计算机基础的要求，但是打好这方面的基础是没有坏处的，如果面试笔试被问到且答得上来，也是能够加分的。一些大厂经常会出现“不是前端的面试官来面前端”的情况，我个人是觉得如果这类面试官问的都是计算机基础问题的话，其实真的无可厚非，毕竟人家在面“一个前端程序员”之前，是在面“一个程序员

目前web产品交互越来越复杂，用户使用体验和网站前端性能优化这些都得靠web前端工程师去做,web前端工程师是设计加开发的综合体，web前端工程师是在开发人员中最直接面向产品，面向用户的设计人员，一个开发团队的成果是要靠web前端工程师去展现，因为用户不会去关心后台的处理有多么强大;在设计人员中web前端工程师是直接面向开发人员的设计人员，向开发人员以一种计算机语言的方式传递其设计理念，web前端工程师在整个团队中是很关键的。 　　Web前端工程师要掌握的基础知识和技能包括： 　　1、网页的基本结构(HTML + CSS) 　　HTML是一种标记语言，而不是编程语言，最基本是标签是和，CSS是用来定义如何显示HTML元素的。对HTML+CSS很容易入门，但很多人不够深入，举几个例子： 　　签是作什么用的?margin-left与left有什么区别，应该在什么情况下使用?再出个DIV+CSS布局问题：一个宽度不确定的DIV里面放三个水平对齐的DIV，左右两个DIV宽度固定为150px，中间那个DIV充满剩余的宽度。如果这些问题你目前还不知道，对那个布局问题几分钟内不能解决，说明你对HTML+CSS还不够深入。 　　2、浏览器是怎么展现网页的 　　不同内核的浏览器对网页的渲染是不一样的，目前浏览器都有客户端调试工具，下图展现一个google首页在IE9下的加载细节： 　

相关知识点 web标准、 web语义化、 浏览器内核、 兼容性、 html5... 题目&答案 Doctype作用？严格模式与混杂模式如何区分？它们有何意义? （1）<!DOCTYPE>声明位于HTML文档中的第一行，处于<html>标签之前，用于告知浏览器的解析器用什么文档标准解析这个文档。DOCTYPE不存在或格式不正确会导致文档以兼容模式呈现。 （2）标准模式的排版和JS运作模式都是以该浏览器支持的最高标准运行。在兼容模式中，页面以宽松的向后兼容的方式显示，模拟老式浏览器的行为以防止站点无法工作。 （3）如果HTML文档包含形式完整的DOCTYPE，那么他一般以标准模式呈现。对于HTML4.01文档，包含严格DTD的DOCTYPE常常导致页面已标准模式呈现。DOCTYPE不存在或者格式不正确会导致文档已混杂模式呈现。 请描述一个网页从开始请求道最终显示的完整过程？ 一个网页从请求到最终显示的完整过程一般可以分为如下7个步骤： （1）在浏览器中输入网址； （2）发送至DNS服务器并获得域名对应的WEB服务器IP地址； （3）与WEB服务器建立TCP连接； （4）浏览器向WEB服务器的IP地址发送相应的HTTP请求； （5）WEB服务器响应请求并返回指定URL的数据，或错误信息，如果设定重定向，则重定向到新的URL地址； （6）浏览器下载数据后解析HTML源文件

相关知识点 web标准、 web语义化、 浏览器内核、 兼容性、 html5... 题目&答案 Doctype作用？严格模式与混杂模式如何区分？它们有何意义? （1）<!DOCTYPE>声明位于HTML文档中的第一行，处于<html>标签之前，用于告知浏览器的解析器用什么文档标准解析这个文档。DOCTYPE不存在或格式不正确会导致文档以兼容模式呈现。 （2）标准模式的排版和JS运作模式都是以该浏览器支持的最高标准运行。在兼容模式中，页面以宽松的向后兼容的方式显示，模拟老式浏览器的行为以防止站点无法工作。 （3）如果HTML文档包含形式完整的DOCTYPE，那么他一般以标准模式呈现。对于HTML4.01文档，包含严格DTD的DOCTYPE常常导致页面已标准模式呈现。DOCTYPE不存在或者格式不正确会导致文档已混杂模式呈现。 请描述一个网页从开始请求道最终显示的完整过程？ 一个网页从请求到最终显示的完整过程一般可以分为如下7个步骤： （1）在浏览器中输入网址； （2）发送至DNS服务器并获得域名对应的WEB服务器IP地址； （3）与WEB服务器建立TCP连接； （4）浏览器向WEB服务器的IP地址发送相应的HTTP请求； （5）WEB服务器响应请求并返回指定URL的数据，或错误信息，如果设定重定向，则重定向到新的URL地址； （6）浏览器下载数据后解析HTML源文件

毕业很多年，一直是在做后端开发，无论是c还是java，甚至用的python也是后端做一些服务类的产品，也不是没想过做点前端的，印象中前端难度比较大，还记得大学的时候，和一同学给老师做个网页产品，但是我们两个对前端不熟悉到文盲的程度，折腾了半个暑假，没啥成果，最后不了了之了，在心理就留下了对前端的阴影，还有经常接触到的前端信息是“xxx浏览器不兼容了”，“css怎么变态难调”了，最后形成了抵触心理。 后面也多次想尝试做点练手的实用的小东西，由于前端的功底比较差最后也不了了之。唯一做过的是在2013年左右，记得用wxPython做了一个系统监控程序，可以自动维护系统，监控错单，自动回单等，界面完全照着另外一个PIM（个人信息管理）系统来抄的，竟然也不丑，能看。 后来web应用兴起，一些管理的系统很少采用CS模式了，多是BS模式，从这个角度来说，浏览器就相当于一个操作系统，难怪windows一直要把IE和系统捆绑起来。相对于CS模式来说，BS模式的软件更易于使用，不用安装，不用考虑各个主机上特殊的差异，只要可以跑浏览器就可以跑应用了，升级的时候，往往是服务器端软件升级了就行了，不用用户操作，体验比较好。对于各个浏览器不兼容问题，业界出现了类似于Jquery库，也有些ui库，比如Bootstrap ，easyUI库，看起来中规中矩，挺正统 ，却不能让人惊艳。 直到了遇到了Antd