大型项目通常有很多环境，开发环境、测试环境、灰度环境、生产环境等，对于前端来说，不同环境的接口前缀（域名或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){
    })
    });