1. node编写代码及实现遍历文件
1.node.js虽然是写js的，但是是运行在操作系统级别的平台，除了前端和js语法上是一样的，其他东西都是不一样的。它是操作系统级别的平台，所以可以操作底层的接口。
2.node对ES6支持很好，所以放心用。
3.node是基于CommonJS规范的语法，import是基于ES6的，最好不要混用，所以node代码就用CommonJS规范
4.遍历文件的node代码，重点考察递归思想
2. 为什么学node、node版本升级及NVM
1.学node主要不是为了后端，是为了有前端的工程化思想。
2.在做项目打包的时候，wepack会依赖一些node的api来提高自己的打包效率。
3.正常情况下电脑只能安装一个node版本，nvm允许电脑安装不同node版本，切换
3. 模块化差异及图片上传服务器的过程
1.CommonJS是JS的一种规范，Node就是根据此规范的，其目标主要是在浏览器之外的环境构建JS生态系统；AMD也具备模块化思想，比CommonJS更适合前端，因为AMD异步加载模块，而CommonJS同步加载模块；CMD和AMD相近，也都是异步加载模块，最大区别是对依赖模块的执行时机处理不同，AMD依赖前置，js可以方便知道依赖模块是谁，立即加载，CMD就近依赖，用的时候才require，需要把模块变成字符串解析一遍才知道依赖的模块。
2.AMD耦合小一点，调用的require不需要了解其实现；ES6的import是静态引入，CommonJS是动态引入，所以import不能嵌套在逻辑语句（而且ES6的模块要求能够编译时就识别，不能有运行时才计算的代码);webpack要求用exoport和import，因为可以静态分析。
3.高版本图片上传思路：input事件监听，图片选择后触发onchange事件，高版本浏览器有FileReader对象，调用FileReader.readAsDataURL获取文件base64的字符串，就可以用img标签的src存储该字符串，实现预览图片功能。点击保存后，后端通过form表单存到服务器即可。
4.全浏览器兼容的图片预览，也是利用input框的type='file'，用onchange执行，但是没有FileReader.readAsDataURL，直接让input以表单形式提交给服务器后端，后端存储完，返回一个图片url，接着同样利用img的src。这时点保存不用再上传图片了，而是保存其他表单项。
4. token及node框架中的MVC
1.localStotage易受XSS攻击（跨站脚本攻击）,替代Cookie尚不成熟，无寿命，需手动删除。
2.sessionStorage也是存储在客户端，但是不作为http一部分（即每次与服务器连接不会自动携带，减少不必要的带宽损失）。sessionStorage引入“浏览器窗口”的概念，即同源同窗口，始终存在，打开其他窗口才是不同sessionStorage，关闭浏览器时自动销毁。
3.Cookie有其他没有的域和路径的概念，通过设置可以使不同路径Cookie不能互相访问，且Cookie允许的大小较小。Web Storage（也是存储在客户端）支持事件通知机制，可以将数据更新的通知发送给监听者
4.MVC模式，Model模型，View视图，Controller控制器负责把Model和View的内容整合并返回给用户。MVC大致就是客户端操作视图数据V给服务器，然后服务器通过C接收并进行相应业务处理M，然后返回给C，C生成视图V返回给用户；
MVP将MVC的C改名为Presenter，使V和C基本不发生联系，都经由P来进行双向通讯，逻辑基本都部署在P。(感觉我们常说的MVC可能其实时MVP，然后据说MVC应该是V->C->M->回到V自成三角循环，用户和V互动)
MVVM是Model，View，ViewModel，访问时被修改的Model直接反应给View，View被修改的时候也反应数据给Model，中间协调的就是ViewModel。即VM把M数据同步到V上显示，把V的修改同步反应给M（前端上M通常指的是JS对象，V就是页面显示的内容）；
5.后端代码讲究MVC,Model负责数据处理，比如数据库处理SQL（有些框架也叫Service），View是视图展示，数据展示，C是调用M取数据，整合V。MVP一般指前端的，但是其实现在说的MVC其实大多指的是MVP（P能和M、V互动，但是M和V不直接互动）。M数据层，V视图层，C控制层。
6.React更倾向于MVC，Vue则MVVM。因为React没有VM层，其改变数据后页面变化，是需要手动控制set state变化；而Vue则能通过VM层自动处理数据改变后的View和Model，能自动感知。C层控制层需要我们手动控制，VM层自动感知并作出改变。
5. 工程化的按需加载及Git冲突解决
1.NoSQL数据库：键值数据库、列存储数据库、文档型数据库、图形数据库
2.MongoDB文档型数据库，数据灵活,可以修改结构，比如人的信息，不用为了多存储人的其他信息而重新设计数据库；结构化、关系型数据库例如MySQL通常用于结构关系一般不变动的场景，比如学校信息储存等。
3.Vue不存在C层，数据M层，数据改变后，VM自动就感知了，视图层V就是模板。平时数据的操作就是M层的。
4.Less底层的编译是通过JS编译的，sass底层的编译是Ruby，两者最大差异也就这点，其他的也就差不多是一些语法差异了；stylus比较小巧，这三个比较常用。以前对CSS编写基本就是需要一个页面对应一套，编写修改不易；现在使用这3个，可以在CSS里面定义变量，可以通过修改变量的值，就直接修改了页面风格，极大提高开发效率。一般只用其中一个就行，毕竟功能上都是差不多的。
5.过去常靠命名空间解决CSS冲突问题（即在.css文件中使用不同的名字命名class等），现在有很多代替方法解决此问题。比如Vue的<template scope=xxx>,通过scope指定作用CSS只作用于XXX组件（文件），其底层通过webpack的css-loader配置参数module：true去实现文件引入样式作用域设定（只在当前文件有效）
6.工程上的按需加载，异步组件。原理是webpack现在支持require.ensure
（可以去看看Webpack的Code Splitting实现按需加载https://www.jianshu.com/p/b3b8fb8a2336）和import语法（这个可以异步加载文件）。Vue本身就包含了按需加载的异步组件，只需要做一些相对应配置即可，但是比如React等要按需加载就需要引入一些额外的库，比如reloadable.js（稍微查了一下，React应该也是CommonJS规范，那require是同步加载的）。
7.git上的冲突解决，复习git指令。线上git分支不一定能识别本地分支，可能需要用到git setOrigin设置对应关系。最后发布时利用webpack打包master分支，发布到CDN。可以自己去了解下git-flow工作模式。
GitFlow详解教程：
https://blog.csdn.net/xingbaozhen1210/article/details/81386269
简单介绍 git-flow 流程：
https://www.jianshu.com/p/019c2053485e
6. 设计模式及node中的npm
1.观察者模式和发布订阅一个类型的：解决模块之间耦合、调用问题，通过事件监听，来实现代码间通信；前端对工厂模式用的不多（SSM常用），即返回一个类型的实例，常和单例类挂钩。通过观察者模式，事件触发代码之间的通信，巧妙解耦。
2.组合、继承：将几个模块组合一起。组合优于继承，继承父类子类设计复杂。
3.模块module本身就是单例的。
（复习一下ES6，CommonJS加载模块后，如果有缓存了，是不会再次加载的，后面只会从缓存中直接取第一次加载的结果。ES6 重复import模块只会加载一次.）
4.npm install xxx安装时默认会安装最新版本。npm的package.lock、yarn.lock版本锁，比如当地安装 xx1.0版本，那么将项目放到线上时，线上npm install xx时，就会参考项目的版本锁，避免线上和本地的版本差异问题。注：npm早期版本没有lock。
7. webpack后端环境的搭建及typescript
1.webpack：建议官方阅读文档guides->concepts->API->configuration->(LOADERS、PLUGINS，需要用到时候看)
2.webpack3和4差异极大，4已经完全重构，性能大大提升，很多插件上的使用、配置项改变。
3.后端使用node的话，可以使用pm2管理工具启动服务器。
4.TypeScript,有很多报错项。需要npm install @type/lodash 才能充分利用到其代码校验的特性。
5.Vue里面双向绑定指的是数据和模板的绑定；单向绑定指的是父子组件的绑定单向。
6.node在服务器渲染SSR中通常充当中间件、中间层，通常处理数据转发、Cookie转发，数据转化。
7.diff算法->stack overflow、segment fault等途径查找文章
8.服务器渲染文章(自己找了几篇）
https://www.jianshu.com/p/4acde8b6e5e3
https://www.cnblogs.com/zhuzhenwei918/p/8795945.html
https://www.cnblogs.com/zhuzhenwei918/p/9266407.html