大型项目通常有很多环境，开发环境、测试环境、灰度环境、生产环境等，对于前端来说，不同环境的接口前缀（域名或ip端口）往往是不同的，所以每次切换环境发布代码时，接口的前缀都需要进行修改，在前端趋于自动化的今天，我们可以有两种方式，避免手动修改这些前缀：
- 方案1：webpack + cross-env
- 方案2：webpack + 自定义脚手架
cross-env :
这是一款运行跨平台设置和使用环境变量的脚本，在使用cross-env之前，你的scripts脚本大概是：
window系统:
"scripts": {
"build": "set NODE_ENV=production webpack --config webpack/webpack.build.js"
}
mac系统:
"scripts": {
"build": "export NODE_ENV=production webpack --config webpack/webpack.build.js"
}
使用cross-env之后，无需关心运行环境问题：
"scripts": {
"build": "cross-env NODE_ENV=production webpack --config webpack/webpack.build.js"
}
回归正题，通过cross-env设置的NODE_ENV是可以在代码中访问的，因此可以新建多条打包命令，并将NODE_ENV作为不同环境的标记，从而在代码中根据NODE_ENV来使用不同环境的接口前缀
"scripts": {
"build:test": "cross-env NODE_ENV=test webpack --config webpack/webpack.build.js",
"build:prod": "cross-env NODE_ENV=production webpack --config webpack/webpack.build.js",
"start": "cross-env NODE_ENV=development webpack-dev-server --config webpack/webpack.dev.js"
}
自定义脚手架：
假如我们不但要实现NODE_ENV的动态化，还想要在打包的时候向构建过程传入更多的参数呢，例如webpack的output中配置publicPath。
可以封装一个私有cli进行打包的管理，下边是包的入口：
/**
* 项目构建
*/
program
.command('release')
.alias('rel')
.description('项目构建')
.option('--static [url]','静态资源前缀')//url前缀是可选参数
.action((options)=>{
//通过options拿到static值，并组织修改webpack配置的publicPath，得到webpackConfig
//.......
//创建打包实例
const compiler = webpack(webpackConfig);
//进行打包，并设置文字提示和结果提示
compiler.run(function(err,stats){
})
});
