1. 怎么把网页发布到Web服务器
1、远程登录到自己的服务器，进入到存羡运放网页的根目录。我用的是阿里云服务器Ubuntu14.04版本，根目录路径为 /var/www/html。
2. 一个前端页面如何部署
一个前端页面，在本地直接打开就能访问。另外如果是要放到服务器下的话，可以装个nginx，或者apache，或者tomcat，直接放到网页路径下，就行。
3. web前端项目部署到服务器：
执行成功后会生成dist文件
4.1 进入到nginx配置目录：/usr/local/nginx/conf,对 nginx.conf 文件进行配置
使用include可以配置多个.conf文件，如一个项目一个配置文件。在同目录下创建demo文件夹，并创建demo.conf配置文件
下面使用是以ip地址的方式创建的的配置文件
访问地址：
其中dist名称时可以修改，保持与/usr/local/nginx/html下cp名称一致，否则会访问不到;并且/usr/local/nginx/html目录可存在同一ip下多个web项目。
域名与ip绑定
配置域名demo.conf
eg: 域名 - demo.cn
4.2阿里云配置域名前缀
阿里云->域名->域名列表—>域名 管理-> 域名解析->解析设置
如图：记录值 填写当前服务ip
学习过程中所记录，有问题或者有好的方式欢迎指点。不胜感激 🤗 🤗 🤗
4. nginx部署前端纯页面
1.进入nginx配置文件vim .../nginx-1.9.12/conf/nginx.conf。
如上图所示：第一个红框中的内容就是应用服务器的地址；第二个红框中的内容就是前端包的位置。
此时，配置文件已经准备完毕。这个包和端口可以存在多个。
2.进入.../nginx-1.9.12/sbin 找到nginx的启动程序。
nginx -c ../nginx-1.9.12/conf/nginx.conf 启动nginx程序，并指定配置文件。
3.如果要替换包，则直接替换就行，nginx为热加载自动更新的。但是以防有缓存之类的存在，可以使用nginx -s reload命令进行重载一次。
追加 一 ：
如果前端包的构造如下图
则location配置依然如下图
但是访问地址则需要指定到具体的html文件上。。
绑定： http://127.0.0.1:48110/binding.html
成功： http://127.0.0.1:48110/success.html
失败： http://127.0.0.1:48110/error.html
追加 二：
同一个端口部署多个页面：
一个server下，多个 location。
location的作用就是是否有后缀，并且这个后缀会去拼接root后的地址。
比如第二个location /sis/。
则在访问127.0.0.1:8080/sis时，会去自动寻找/apps/svr/nginx-1.9.12/pagefile/0921/sis这个包。 （Ps：location后的地址一定要用 / 关闭，比如 location /sis/，不然访问127.0.0.1:8080/sis时，会报错，只有用127.0.0.1:8080/sis/才行。）
这样就部署好了一个 端口支持多个页面。
5. 怎么开发和部署前端代码
先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。
- 总之，前端性能优化绝逼是一个工程问题！
好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。
但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！
这个奇葩问题，起源于资源的 覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。
<img src="https://pic4.mg.com/50/_hd.jpg" data-rawwidth="631" data-rawheight="456" class="origin_image zh-lightbox-thumb" width="631" data-original="https://pic4.mg.com/_r.jpg">
好了，目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这™让工程师怎么写码啊！！！
要解释优化与工程的结合处理思路，又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题，以上只是开了个头，解决方案才是精髓，但要说的太多太多，有空再慢慢展开吧。或者大家可以去我的blog看其中的一些拆解：fouber/blog · GitHub
以上不是我YY的，可以观察 网络 或者 facebook 的页面以及静态资源源代码，查看它们的资源引用路径处理，以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平，跪舔了。
建议前端工程师多多关注前端工程领域，也许有人会觉得自己的产品很小，不用这么变态，但很有可能说不定某天你就需要做出这样的改变了。而且，如果我们能把事情做得更极致，为什么不去做呢？
另外，也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决，大家总是把自己不关心的问题丢给别人，那么前端工程师的开发过程将受到极大的限制，这种情况甚至在某些大公司都不少见！
6. 前端怎么把网页部署到tomcat 怎么启动tomcat
首先配置下Myeclipse里Tomcat服务 在Windows-->Preferences-->MyEclipse-->Application Servers 中选择你的tomcat版本，在右侧的面板里指定tomcat的安装路径后，点击Apply或OK保存
7. 常见的前端集成部署方案有哪些各自的优缺点是什么
前端行业经历了这么长时间的发展，技术元素非常丰富，这里列举出一般web团队需要用到的技术元素：
开发规范：包括开发、部署的目录规范，编码规范等。不要小瞧规范的威力，可以极大的提升开发效率，真正优秀的规范不会让使用者感到约束，而是能帮助他们快速定位问题，提升效率。
模块化开发：针对js、css，以功能或业务为单元组织代码。js方面解决独立作用域、依赖管理、api暴露、按需加载与执行、安全合并等问题，css方面解决依赖管理、组件内部样式管理等问题。是提升前端开发效率的重要基础。现在流行的模块化框架有requirejs、seajs等。
组件化开发：在模块化基础上，以页面小部件(component)为单位将页面小部件的js、css、html代码片段放在一起进行开发、维护，组件单元是资源独立的，组件在系统内可复用。比如头部(header)、尾部(footer)、搜索框(searchbar)、导航(menu)、对话框(dialog)等，甚至一些复杂的组件比如编辑器(editor)等。通常业务会针对组件化的js部分进行必要的封装，解决一些常见的组件渲染、交互问题。
组件仓库：有了组件化，我们希望将一些非常通用的组件放到一个公共的地方供团队共享，方便新项目复用，这个时候我们就需要引入一个组件仓库的东西，现在流行的组件库有bower、component等。团队发展到一定规模后，组件库的需求会变得非常强烈。
性能优化：这里的性能优化是指能够通过工程手段保证的性能优化点。由于其内容比较丰富，就不在这里展开了，感兴趣的同学可以阅读我的这两篇文章 [1] [2]。性能优化是前端项目发展到一定阶段必须经历的过程。这部分我想强调的一点是性能优化一定是一个工程问题和统计问题，不能用工程手段保证的性能优化是不靠谱的，优化时只考虑一个页面的首次加载，不考虑全局在宏观统计上的优化提升也是片面的。
项目部署：部署按照现行业界的分工标准，虽然不是前端的工作范畴，但它对性能优化有直接的影响，包括静态资源缓存、cdn、非覆盖式发布等问题。合理的静态资源资源部署可以为前端性能带来较大的优化空间。
开发流程：完整的开发流程包括本地开发调试、视觉效果走查确认、前后端联调、提测、上线等环节。对开发流程的改善可以大幅降低开发的时间成本，工作这些年见过很多独立的系统（cms系统、静态资源推送系统）将开发流程割裂开，对前端开发的效率有严重的阻碍。
开发工具：这里说的工具不是指IDE，而是工程工具，包括构建与优化工具、开发-调试-部署等流程工具，以及组件库获取、提交等相关工具，甚至运营、文档、配置发布等平台工具。前端开发需要工具支持，这个问题的根本原因来自前端领域语言特性（未来我会单独写一篇文章介绍前端领域语言缺陷问题）。前端开发所使用的语言（js、css、html）以及前端工程资源的加载与定位策略决定了前端工程必须要工具支持。由于这些工具通常都是独立的系统，要想把它们串联起来，才有了yeoman这样的封装。前面提到的7项技术元素都直接或间接的对前端开发工具设计产生一定的影响，因此能否串联其他技术要素，使得前端开发形成一个连贯可持续优化的开发体系，工具的设计至关重要。
8. 前端的代码怎么部署到服务器
1、安装护卫神主机大师，一键配置全能网站环境
2、用主机大师开设网站，并绑定域名
3、解析域名到服务器IP
4、FTP上传前端代码到服务器
5、输入域名即可访问前端代码了
9. 使用Tomcat和Nginx部署前端项目
第一种方式，将我们的前端项目放置在webapps目录下
进入tomcat安装路径下的conf目录，在server.xml文件中<Host>标签内配置虚拟路径
简单的解释一下参数
path 对应用户请求过来的url路径, /static 匹配所有以 /static 开头的请求
docBase 表示实际匹配到的路径，这里可以使用绝对路径，也可以使用相对路径
reloadable 如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化。（对于静态资源来说，个人觉得这个配置用处不大）
总结起来就是，对于ip:8080/static的资源请求，会通过虚拟路径匹配到我们实际的资源路径music_client/static。
配置好后重启，我们可以发现已经能够看到我们的前端项目了
对于ROOT目录下的资源，tomcat可以直接在根目录下进行访问。通过这种方式，我们可以让项目的路径去适配tomcat访问的路径。
但是这种方式不是特别推荐，当有多个项目在同一个tomcat服务器上的时候，会不方便管理。
Nginx是当下热门的服务器，使用起来只需要进行简单的配置即可。对于Nginx的安装大家可以自行网络解决。
我们先进入到usr/local/nginx（具体以实际nginx安装目录为准）下的conf目录，vim编辑nginx.xml。主要进行下面的配置
简单的解释一下
listen 表示nginx监听的端口号，也就是你希望暴露哪个端口给用户进行访问
server_name 表示nginx接受请求的域名，一般默认localhost就行
location 模块用于响应请求，这里的 / 表示匹配8082端口的所有请求
root 表示静态资源/项目的路径
index 表示默认的访问资源
配置完成后，进入 sbin 目录下，通过 ./nginx -t 检查配置文件的格式是否正确
如正确 ./nginx 进行启动或者 ./nginx -s reload 进行重启
启动完，我们就可以直接ip:8082直接访问我们的前端项目啦
开启nginx的反向代理也比较简单，只需要加上proxy_pass 配置即可
出现这个问题的原因是： 在history模式下，只是动态的通过js操作window.history来改变浏览器地址栏里的路径，并没有发起http请求，但是当我们直接在浏览器输入这个地址的时候，就会对服务器发起http请求，但是这个目标在服务器上又不存在，所以会返回404。
我们可以通过把所有请求都转发到首页上来解决这个问题。只需要在 Nignx 中的配置文件加入如下配置：
事实上，上面的解决方式也是Vue-Router官方推荐的解决方式（ https://router.vuejs.org/zh/guide/essentials/history-mode.html#nginx ）。
那上面的 try_files 为什么能帮助我们解决这个问题呢？我们可以看一下这个属性的作用
try_files ：按选项所指定的顺序去检查用户请求的文件是否存在，如果本地存在的话则返回该请求；不存在的话将该请求转发到指定的其它路径。也就是说，比如我们当前的前端项目部署在 /usr/myproj 目录下，现在我们在浏览器发起 ip:port/testApi 请求，那么此时 uri 为testApi,nginx会先去 $root/testApi （即/usr/local/myproj/testApi）找是否存在该静态资源，若不存在，则继续寻找 $root/testApi/index （即/usr/local/myproj/testApi/index）文件是否存在，如果还是不存在，则会把请求转发到首页。
而我们的项目本事就是由Vue-Cli创建的 单页面应用 ，当index页面接收到请求的时候，对应的history模式路由就可以发挥作用了，根据浏览器的路由跳转到对应的页面，这也就保证了我们的路由请求都能够转发给index页面来进行处理。
这种问题一般是出现在服务器一开始安装Nginx的时候，没有安装SSL模块。在不重装Nignx的情况下，可以安装如下方式进行操作：
执行如下命令
这一步只是以防万一，可以省略
也可以直接执行 ./usr/local/nginx/sbin/nginx -t 看还会不会报错就行
nginx报错: [emerg] https protocol requires SSL support in /usr/local/nginx/conf/nginx.conf:50