起源

最原始的前端开发就是写一系列静态的html、css、JavaScript然后扔到服务器上，访问域名然后渲染网页。随着前端要求的越来越复杂，更多的工程化概念引入了进来，出现了node以及衍生出的打包工具webpack。前端的日益工程化带来了开发效率的飞跃，与此同时也带来了一些问题。本文要讲的就是在现代浏览器中，由于跨域的限制导致在开发环境下不能直接进行请求线上服务，因此有了代理的需要。

一般的开发流程及相关环境

目前主流的开发流程通常包含了开发(dev)、测试(beat)、与生产(prod)环境。其中开发环境通常是程序员在本地搭建的用于开发调试的环境，开发的过程中及时同步代码到仓库。

开发及联调阶段

目前主流的前后端分离的开发方式，在开发前前后端会有一个约定好的api、以此为依据在开发过程中mock一个接口。前期后端没有完成该接口时前端靠mock的接口来代替，这个mock接口可以是本地的数据，也可以是搭建在远程的mock服务器（如Yapi）。在联调阶段，后端完成了接口后会将自己的代码部署在beta服务器上，然后前端以切hosts的方式将前端请求打到后端的beta接口上进行联调。

测试阶段

待程序员开发完成后，需要QA测试开发好的代码，因此QA会从代码仓库中拉取代码并在QA的beta环境中部署。一旦QA发现问题及时通报开发，待开发修改后再验证，如此往复直到到达上线标准。

发布阶段

代码到达上线标准后，应将代码部署到正式的线上服务器。通常前端的部署都是增量更新的，即本次的更新只是在之前已经发布代码基础上的部分替换，以保证项目整体的稳定性。

不同环境带来的问题

由于一般的开发涉及到多个不同的环境，那么我们就需要一套机制来保证开发好的代码能在这些不同的环境中顺利的对接上。正如上面所说的，浏览器的跨域机制会限制前端发起的请求，从而给开发带来了不便。

如何克服开发时带来的繁琐的环境切换问题？下面介绍三种常用的工具👇

nginx + hosts

传统的方式，首先利用hosts文件拦截线上域名到本地nginx服务器，再根据nginx反向代理的特点，将拦截到的请求转发到本地的各个路径上去。

优点

兼容性好–hosts映射是所有系统都支持的，同时nginx作为经典服务器应用在各平台都支持的很好。绝大多数环境的配置都可以复用。

不足

nginx对于新前端的学习成本略高，要理解nginx的配置，并且理解nginx反向代理的机制

同时需要维护nginx和hosts比较麻烦，容易导致混乱，在团队之间分享配置就更麻烦了（互相拷贝）

此外，修改系统hosts会导致DNS缓存问题，需要等待缓存过期或者重启浏览器。

charles

有名的一款抓包软件，也包括了很多开发调试的常用功能。借助这种GUI工具，可以很轻松的用map remote（远程映射）功能实现指定域名到本地开发环境的映射

charles的远程映射功能

优点

图形化界面，易于上手和配置，同时支持批量导出配置，开发团队之间分享配置比较方便

缺点

在开发流程之外还是需要单独安装软件，无法与项目的开发很好的结合在一起，并且不能保证在任何环境中都支持使用。

hiproxy

敏锐的开发者看到了配置前端开发环境的不便性，写了一款开源的工具：https://github.com/hiproxy/hiproxy，以nginx配置为基础的环境切换工具。这个工具解决的最大痛点就是借助一个配置文件，用Node.js命令行工具一套完成了前端环境的搭建与切换。

正如该工具的开发者所说：

作为前端开发工程师，我们会经常遇到一些环境问题。比如本地调试线上页面、跨域、DNS缓存、网络请求抓包、HTTPS请求开发调试以及证书等等。为了解决这些问题，我们需要使用hosts、Nginx、Fiddler/Charles以及各种各样的hosts切换管理工具等。在使用这些工具的同时，还存在一些问题需要解决。

我们每天都要花费很多时间在环境的配置、切换问题上，因此需要一个更好的方案来统一解决这些问题。

该工具通过一个核心的rewrite文件，以nginx的方式，在不需要配hosts的情况下实现了前端开发环境的搭建。

一个rewrite文件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# variables
set $local 127.0.0.1:8800

# simple rewrite rul
api.hiproxy.org/mock => $local/mock;

# domain and location
domain blog.hiproxy.org {
    set_header Access-Control-Allow-Origin *;

    set $node_server 127.0.0.1:3008;
    set $order order;

    location /$api/$order/detail {
        proxy_pass http://$node_server/user/?domain=$domain;
        set_header Set-Cookie userID 200908204140;
    }

    location ~ /\/(usercenter|userinfo)/ {
        proxy_pass http://127.0.0.1:3008/info/;

        set_cookie userID 200908204140;
    }

    location ~ /\/local\/(.*)(\?(.*))?/ {
        send_file ./mock/$1.json;
    }

    location /dev {
        alias ./src/view/;
        root app.html
    }

    location /multiple {
        echo <h1>hello_echo</h1>;
        echo <p>test echo directive</p>;
        echo <p>finish</p>;
    }
}

是不是跟nginx很像？开发的时候只需要将rewrite文件置于开发文件夹的根目录上，开发前用命令行启用rewrite文件就可以一键搭建开发环境了。

hiproxy的开发与使用

优点

易于分享，开发团队中一人写好配置，其他人可以直接用，极大的提高了团队开发效率，减少沟通成本。

与项目融为一体，可以伴随其他代码一起上传到Git上。

缺点

需要学会nginx的配置才能很快上手hiproxy的rewrite文件的编写

不够稳定，开发时偶尔有崩溃的时候，需要花时间去检查崩溃原因

总结

可以看到随着开发的需要，前端开发环境的配置最终的发展方向是便于轻松搭建，便于分享、易于学习上手的。