1.Entry property(entry属性)
1.1 Single Entry (Shorthand) Syntax（单个入口语法）
用法：entry: string | Array<string>
如果向 entry 属性传入「文件路径(file path)数组」将创建“多个主入口(multi-main entry)”。在你想要多个依赖文件一起注入，并且将它们的依赖导向(graph)到一个“chunk”时，传入数组的方式就很有用。
优劣： 如果你正在寻找为「只有一个入口起点的应用程序或工具（即 library）」快速设置 webpack 配置的时候，这会是个很不错的选择。然而，使用此语法在扩展配置时有失灵活性。
1.2 Object Syntax(对象语法)
用法： entry: { [entryChunkName : string ] : string | Array<string> }
对象语法会比较繁琐。然而，这是应用程序中定义入口的最可扩展的方式。
1.3 Scenarios（使用场景）
Below is a list of entry configurations and their real-world use cases:
1.3.1 分离app和第三库入口
这是什么？从表面上看，这告诉我们 webpack 从 app.js 和 vendors.js 开始创建依赖图(dependency graph)。这些依赖图是彼此完全分离、互相独立的（每个 bundle 中都有一个 webpack 引导(bootstrap)）。这种方式比较常见于，只有一个入口起点（不包括 vendor）的单页应用程序(single page application)中。
这样做的好处是： 此设置允许你使用 CommonsChunkPlugin 从「应用程序 bundle」中提取 vendor 引用(vendor reference) 到 vendor bundle，并把引用 vendor 的部分替换为 __webpack_require__() 调用。如果应用程序 bundle 中没有 vendor 代码，那么你可以在 webpack 中实现被称为长效缓存的通用模式。
1.3.2 多页面应用程序
webpack的配置如下：
上面的配置告诉我们 webpack 需要 3 个独立分离的依赖图（如上面的示例）。
这样配置的好处是： 在多页应用中，（译注：每当页面跳转时）服务器将为你获取一个新的 HTML 文档。页面重新加载新文档，并且资源被重新下载。然而，这给了我们特殊的机会去做很多事：
使用 CommonsChunkPlugin 为每个页面间的应用程序共享代码创建 bundle。由于入口起点增多，多页应用能够复用入口起点之间的大量代码/模块，从而可以极大地从这些技术中受益。