『壹』 React + webpack 热更新后修改了样式文件，但是不能及时生效的解决办法
使用了webpack的热更新后，修改样式文件，不能热更新到样式文件上，只能打枝弊包到服务器上，样式文件才会生效。
具体的原因是因为我将样式文件和js文件分开了，所以样式文件不会汪拆生效。
解决办法就是在开发环境中猛陵族将样式文件和js文件合并，正式环境中再 将其分开。
这里我将css分离、文件规则等配置分离到其他js中，这里就写了样式文件。
『贰』 webpack3.5分离css没有内容
创建和应用 CSS 样式表
除了为单个元素设置内联样式之外，还可以创建和应用级联样式表 (CSS) 文件。级联样式表使您可以定义可应用于多个控件和页面的样式，而不必分别编辑元素。
在演练的本节中，将创建样式表，该样式表使您可以使用用于设置内联样式的相同工具。然后将样式表应用于正在编辑的页面。
创建样式表
在解决方案资源管理器中，右击网站的名称（如 C:\WebSites），再单击“添加新项”。
在“Visual Studio 已安装的模板”之下单击“样式表”。
在“名称”框中，键入“dark.css”，再单击“添加”。
编辑器打开一个包含 body 样式元素的新样式表。
将插入点定位在左右大括号 ({ }) 之间，然后在“样式”菜单上单击“生成样式”。
出现“样式生成器 - body”对话框。
单击“字体”，在“字体属性”下单击位于“颜色”框右边的省略号“(…)”，在“颜色选取器”对话框中单击一种亮色，再单击“确定”。
注意
请确保选择一种与网站网页的默认颜色不同的颜色。
单击“背景”，单击一种与前面步骤中选定的字体颜色对比的暗色（如“褐紫红色”），再单击“确定”关闭“样式生成器 - body”对话框。
将插入点定位到 body 元素的右大括号之后，右击，再单击“添加样式规则”。
出现“添加样式规则”对话框。
“添加样式规则”对话框使您可以创建绑定到特定 HTML 元素类型、样式类名或特定元素的新样式。
单击“类名”，然后在框中键入“reverse”。
这样将创建一个名为 .reverse 的新样式类。将能够把为 .reverse 定义的样式设置应用于页上的任何元素。还可以蚂碰选择创建类，以便它只能应用于特定类型的元素（定位滚轿点、按钮等），但是在本演练中将创建一个简单的样式类。
单击“确定”以关闭“添加样式规则”对话框。
使用样式生成器或 IntelliSense 功能将 .reverse 样式的颜色设置为与主体样式的颜色相反的颜色。元素类似于如下所示：
.reverse
{
background-color:white;
color:maroon;
}
既然有样式表，那么可以在正在编辑的页中对其进闷备谈行引用。
在网页上引用样式表
打开 Default.aspx 页并切换到“设计”视图。
从解决方案资源管理器中，将 dark.css 文件拖动到页面上。
页面已更新，并显示样式表的效果。
单击“正方形”，然后在“属性”中设置“CssClass”“reverse”。
这样将反转样式应用于“正方形”。
切换到“源”视图。
在 <head> 元素中，可以看到编辑器已经添加了引用样式表的 <link> 元素。还可以看到 <asp:button> 元素的 cssclass 属性已设置为 reverse。
右击该页，再单击“在浏览器中查看”。
该页出现在浏览器中，且已应用样式表。
『叁』 为什么webpack分离打包的css文件没有被引入
打包的文件确实需要手动引入，兆早凯或族唤者用html-webpack-plugin，配置一下睁此就可以自动生成模板
『肆』 webpack中打包后的js和css分离不出来
rules: [
{
test: /\.css$/,
use: ExtractTextPlugin.extract({
fallback: "style-loader",
use: "css-loader"
})
}
]
以后再遇到这样的问题 可以直接搜索这个插件 看它的用法
『伍』 html-webpack-plugin按需加载的js/css也会被提取出来吗
//引入想要的css文件
var style = require('style/useable!css!./file.css');
//激活，也就是在dom中添加style标签
style.use();
//销毁，也就是不想用时，可以从dom中把style标签再删掉
style.unuse(); // = style.unref();
至于你说“没有提取出来”，那是因为你用的是style-loader，如果真想提取文件，应该用extract-text-webpack-plugin。
最后关于javascript部分，script标签从dom中删除这件事，其实意义不大，这么说吧，对你来说，最想把她从dom中移除的原因是什么？因为你的用户会检查你的dom？还是因为你觉得script标签杵在那里影响了你的心情？
实际上，当script标签添加之后，脚本内容开始下载/解析，甚至执行，该被运行时记录的变量都已经记录了。如果真有变量需要销毁，这也不是c，js有自己的垃圾回收机制，只要你没写出内存泄漏的代码，内存中的废弃物是会自动销毁的；换句话说，如果你代码写的倒出是问题，就算手动删了那个script标签又如何？照样内存泄漏！
补充：
如果你想提取.vue文件里的style css内容，那你的loader配置也没配对地方，应该是在vue属性里配置：
vue: {
loaders: {
js: 'babel-loader?presets[]=es2015&plugins[]=transform-runtime&comments=false',
css: ExtractTextPlugin.extract(['css-loader'])
}
},
plugins: [
new ExtractTextPlugin('output.css')
]
『陆』 Web项目开发为何要走前后端分离模式
把前端与后端独立起来去开发，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员，前后端工程师需要约定交互接口，实现同步开发，开发结束后需要进行独立部署，前端通过接口来调用调用后端的API，前端只需要关注页面的样式与动态数据的解析和渲染，而后端专注于具体业务逻辑。具体好处有以下几点：
1.彻底解放前端
前端不再需要向后台提供模板或是后台在前端html中嵌入后台代
2.提高工作效率，分工更加明确
前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。
3.局部性能提升
通过前端路由的配置，我们可以实现页面的按滚册需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上大山宏有所提升。
4.降低维护成本
通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。
5.实现高内聚低耦合，减少后端（应用）服务器的并发/负载压力。
6.即使后端服务暂时超时或者宕机了，前端页面也会正常访问，但无法提供数据。
7.可以使后台能更好的追求高并发，高可用，高性能；使前端能更好的追求页面表现、速度流畅、兼容性、用户唯睁体验等。
我理解的前后端分离，前端是需要起服务器的，减少学习成本，可以用node，前端也要有域名的
如果是半分离， 那么前端提供js文件（css等）这个我也做过，前后端都用node就不说了，如果是两种语言，
如果一个工程文件下开发，webpack下直接打包进后台语言的静态目录下。
如果是两个工程，那么前端只提供生成的js（css）文件，git pull后台项目，扔进静态目录，这样又涉及到版本控制的问题，一般我会生成一个配置文件，直接读取的，内容是xxx.hash.js这种文件名，然后document.wirte动态写入js/css
前端起服务器就不需要动态引入了，直接html插件生成文件，更好的控制版本
半分离 还有一个问题，例如首页同构，如果更改xxx.blade.php文件，这就又动了php文件，甚至包括nginx反向代理啊，ssl这种缓存啊，都比较麻烦，你要是改了点啥，自己的ok了，后台的崩了，那就挺操蛋了，大公司有专门的运维还好，小公司真的是一团糟
后台我们采取全分离，nginx前端管理，至于升级nginx版本，http2，反向代理，https证书，都是前端自己弄，毕竟小公司，每个人水平都不一致，自己负责自己的比较好
但是这个跨域又要稍微处理一下，至今我这边后台还是*，我也没法说什么
阿里云这么便宜，如果把成本浪费在人力上，会变得很贵
一个人的精力有限，前后端分离有助于我们更专注我们所要注重的技术点，俗话说：“术业有专攻”。
比如我们后端，前后端分离有助于我们把注意力放在java基础，设计模式，jvm原理，spring+springmvc原理及源码，linux，mysql事务隔离与锁机制，mongodb，http/tcp，多线程，分布式架构（bbo，bbox，spring cloud），弹性计算架构，微服务架构（springboot+zookeeper+docker+jenkins），java性能优化，以及相关的项目管理等等。
而前端也可以集中精力在前端的展示上。
总的来说，前后端分离利大于弊。这也是越来越少用jsp的原因。
补充两点
1.每次请求的数据量变小，也意味着更少的响应时间。
2.也不是每个应用用前后端分离都是最合适的，要根据应用规模，工期综合判断。
『柒』 webpack开发多页面时，怎样拆分多个css
一. 打包多个页面的js文件 读取src/举燃views下的目录，约定每一个目世橡录当成一个页面，打包成一个js chunk。 二. 打包多个html 循环生成多个HtmlWebpackPlugin插件，把每一个插件的chunks各自指向正返虚上面打包的js chunk
『捌』 前后端分离方案以及技术选型
作者：关开发
一.什么是前后端分离？
理解前后端分离大概可以从3个方面理解：
1. 交互形式
2. 代码组织形式
3. 开发模式与流程
1.1 交互形式
前后端不分离
后端将数据和页面组装、渲染好了之后，向浏览器输出最终的html；浏览器接收到后会解析html，解析引入的css、执行js脚本，完成最终的页面展示。
前后端分离
后端只需要和前端约定好接收以及返回的数据格式（一般用JSON格式），向前端提供API接口。前端就可以通过HTTP请求调用API的方式进行交互。前端获取到数据后，进行页面组装、渲染，最终在浏览器呈现。
1.2 代码组织形式
前后端不分离
在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术（jsp），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。否则前端只能当一个“切图仔”，只输出HTML、CSS、以及很少量与业核或消务逻辑无关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。
前后端分离
前后端代码放在不同的工程下，前端代码可以独立开发，通过mock/easy-mock技术模拟后端API服务可以独立运行、测试；后端代码也可以独立开发，运行、测试，通过swagger技术能自动生成API文档供前端阅读，还可以进行自动化接口测试，保证API的可用性，降低集成风险。
1.3 开发模式与流程
前后端不分离
在项目开发阶段，前端根据原型和UI设计稿，编写HTML、CSS以及少量与业务无关的js（纯效果那些），完成后交给后台人员，后台人员将HTML转为jsp，并通过JSP的模板语法进行数据绑定以及一些逻辑操作。后台完成后，将全部代码打包，包含前端代码、后端代码打成一个war，然后部署到同一台服务器运行。顶多做一下动静分离，也就是把图片、css、js分开部署到nginx。
具体开发流程如下：图略
前后端分离
实现前后端分离之后，前端根据原型和UI设计稿编写HTML、CSS以及少量与业务无关的js（纯效果那些），后端也同时根据原型进行API设计，并与前端协定API数据规范。等到后台API完成，或仅仅是API数据规范设定完成之后。前端即可通过HTTP调用API，或通过mock数据完成数据组装以及业务逻辑编写。前后端可以并行，或者改知前端先行于后端开发了。
具体开发流程如下：图略
二、前后端分离的好处与坏处。
从上面3个方面对比了之后，前后端分离架构和传统的web架构相比，有很大的变化，看起来好处多多。到底是分还是不分，我们还是要理性分析是否值得才去做。
从目前应用软件开发的发展趋势来看，主要有两方面需要注意：
· 越来越注重团激用户体验，随着互联网的发展，开始多终端化。
· 大型应用架构模式正在向云化、微服务化发展。
我们主要通过前后端分离架构，为我们带来以下四个方面的提升：
· 为优质产品打造精益团队
通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。
· 提升开发效率
前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。
· 完美应对复杂多变的前端需求
如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。
· 增强代码可维护性
前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。
那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。。。
二、前后端分离架构方案。
实现前后端分离，主要是前端的技术架构变化较大，后端主要变为restfull 风格API，然后加上Swagger技术自动生成在线接口文档就差不多了。
对于目前用于前后端分离方案的前端技术架构主要有两种：
· 传统SPA
· 服务端渲染SSR
2.1 传统SPA
传统SPA指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过reac全家桶、tvue全家桶，模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。
单页面应用的运行流程
1.用户通过浏览器访问网站url
2.单页面的html文件（index.html）被下载到浏览器，接着下载html里面引用的css，js。
3.css，js下载到浏览器完成之后，浏览器开始解析执行js向后端服务异步请求数据。
4.请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。
2.2 服务端渲染
服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。
它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。
服务端渲染应用的运行流程：
1.用户通过浏览器访问网站url
2.NodeJS服务端接收到请求，读取到对应的前端html，css，js。
3.NodeJS解析执行js向后端API异步请求数据。
4.NodeJs请求数据完成之后，进行数据绑定、渲染，得到一个最终的html。
5.NodeJs向浏览器输出html，浏览器进行展示。
PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。
看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？
2.3 SPA与服务端渲染方案对比
SPA的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的SEO。
so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：
与传统 SPA (单页应用程序 (Single-Page Application)) 相比，服务器端渲染 (SSR) 的优势主要在于：
· 更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。
请注意，截至目前，Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 loading 菊花图，然后通过 Ajax 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。
· 更快的内容到达时间 (time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。
无需等待所有的 JavaScript 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应用程序而言，服务器端渲染 (SSR) 至关重要。
使用服务器端渲染 (SSR) 时还需要有一些权衡之处：
· 开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行。
· 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。
· 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。
以vue为例，实施服务端渲染可以查看官方指南： https://ssr.vuejs.org ，或选择Nuxt.js
2.4 预渲染技术
如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面（例如 /, /about, /contact 等）的 SEO，那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML，而是使用预渲染方式，在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。
如果你使用 webpack，你可以使用 prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应用程序广泛测试 - 事实上，作者是 Vue 核心团队的成员。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前后端分离技术选型
- artTemplate + bootstrap（不推荐， 不算完全前后端分离）
- vue全家桶（推荐）
- react全家桶 （推荐，生态全）
『玖』 webpack 怎么单独打包第三方css库，比如normalize.css
其实有两种方案：第一种是将 css 文件在 js entry 中添加依赖；第二种直接设置 css entry。
第一种方案
// index.jsimport 'normalize.css';
...
// webpack config{ entry: { index: './index.js'
},
...
}
// outputindex.jsindex.css
这种是 Webpack 官方推荐的方案，但是每次都要把 css 放到 js entry 中才可以 extract 出来。
第二种方案（直接设置 css entry）
默认 Webpack 设置 css entry 除了 extract 出 css 文件还会多产生一个 js 文件，其实可以写个 Webpack 插件将其删除就可以了。
『拾』 vue 一部分css 打包进了 js 怎么分离
var ExtractTextPlugin = require('extract-text-webpack-plugin');
普通.css文件
{ test: /\.css$/, loader: ExtractTextPlugin.extract('style', 'css', 'postcss')
}
.vue中的需要单独配置vue: { loaders: { css: ExtractTextPlugin.extract('css'),
html: 'html-loader'http:www..com
}
}
最后，在plugins中添加new ExtractTextPlugin("css/[name].css", { allChunks: true })
注意：如果使用了按需加载，一定要加入这句 { allChunks: true } {http://r.yuzhua.com}，不然css样式无效