Webpack 从入口点开始处理您在应用程序中使用的每个module，包括您导入的每个module（import或require），并将其包含在您的包中。这__non_webpack_require__是一个将导致简单require调用的函数。

我们以这个入口点为例：

const processedByWebpack = require("./module");
const notProcessed = __non_webpack_require__("./non-webpack");

console.log(processedByWebpack);
console.log(notProcessed);

在这种情况下，webpack 将捆绑该应用程序并包含您导入的每个module，在这种情况下只是./module.js. 所以输出将是：

/******/ ([
/* 0 */
/***/ (function(module, exports, __webpack_require__) {

const processedByWebpack = __webpack_require__(1);
const notProcessed = require("./non-webpack");

console.log(processedByWebpack);
console.log(notProcessed);


/***/ }),
/* 1 */
/***/ (function(module, exports) {

module.exports = "This module is bundled with webpack"


/***/ })
/******/ ]);

该./module.jsmodule包含在包中，如果存在任何适用的规则，它也会被任何加载器处理。另一方面，./non-webpack.js不包含在包中，webpack 调用了require. 这意味着./non-webpack.js将在执行时解析它，如果它不可用或包含无效的 JavaScript，它将失败并显示运行时错误。

__non_webpack_require__是一种解决 webpack 处理所有require调用这一事实的方法。因为 webpack 捆绑了所有module，所以它必须在编译时知道要包含哪些module。这require比 Node.js 中的实际限制更多。例如，您不能使用 dynamic requires，这意味着您不能使用变量作为module的路径（另请参阅webpack dynamic module loader by require）。例如：

// Path to module as a variable (could be an argument to a function)
const modulePath = "./module";

const processedByWebpack = require(modulePath); // Fails
const notProcessed = __non_webpack_require__(modulePath);

在常规requirewebpack 中会失败，因为它不知道要包含哪些module来覆盖所有可以在运行时引用的module。在这个例子中，它可能看起来很明显，但它可以使用用户输入来确定要加载的module。使用__non_webpack_require__它只需创建一个require调用，您就必须Module not found在运行时处理可能的异常。

你应该什么时候使用它？

可能永远不会。这是这些功能之一，应该被视为最后的手段，您需要避开 webpack 以获得一些动态module解析。在大多数情况下，还有其他解决方案可以实现相同的目标（例如，通过使用Externals将导入推迟到运行时），其他一切都是边缘情况。

你会注意到它__non_webpack_require__被转换成一个require呼叫。这意味着它只能在 Node.js 中工作并且在任何浏览器环境中都失败，除非你有一个全局require定义，它可能会或可能不会做一些特殊的事情。另一个缺点是它是特定于 webpack 的，当您想使用其他工具（例如用于测试）时，它不起作用，或者您将很难尝试解决它。