fix

47.精读《webpack4.0 升级指南》.md

@@ -196,15 +196,15 @@ webpack --mode production
 
 兼容性自己查 [Caniuse](https://caniuse.com/)，笔者重点在功能上。`preload` 收集当前用到的资源，`prefetch` 收集未来用到的资源。
 
-页面本质上也是未来一种资源，如果认为用户会点击另一个页面（如果对产品没自信，或者 pv 过低可以忽略这个功能），就可以用 `prefetch` 让浏览器在空闲时间下载下一个页面的 chunk 文件。
+页面本质上也是未来一种资源，如果认为用户会点击另一个页面（如果对产品没自信，或者 pv 过低可以忽略这个功能），就可以用 `prefetch` 让浏览器在空闲时间下载下一个页面的 chunk 文件。
 
-前端包体积优化效率一般和用户体验是违背的，既然下一个页面在另一个 chunk 中，用户点击后必然会产生 loading。可是如果结合了 `prefetch`，鱼和熊掌就兼得了（正常用户不可能页面还没加载完就立刻点按钮跳页，所以唯一的缺点几乎不会对正常用户产生影响）。
+前端包体积优化效率一般和用户体验是违背的，既然下一个页面在另一个 chunk 中，用户点击后必然会产生 loading。可是如果结合了 `prefetch`，鱼和熊掌就兼得了（正常用户不可能页面还没加载完就立刻点按钮跳页，所以唯一的缺点几乎不会对正常用户产生影响）。
 
 api 有了，那么最大的问题就是，当前页面怎么知道要加载哪些 chunks？一般两种做法：
 
-**全量模式** 使用比如 [preload-webpack-plugin](https://github.com/GoogleChromeLabs/preload-webpack-plugin) 插件，将所有生成的 chunk 都作为 `prefetch` 资源，在所有页面中。几乎所有规模的项目都不会产生过多的 chunks，所以这个方案理论上不够优雅，但能解决实际问题。
+**全量模式** 使用比如 [preload-webpack-plugin](https://github.com/GoogleChromeLabs/preload-webpack-plugin) 插件，将所有生成的 chunk 都作为 `prefetch` 资源，在所有页面中。几乎所有规模的项目都不会产生过多的 chunks，所以这个方案理论上不够优雅，但能解决实际问题。
 
-**按需模式**，是理论和实践双重优雅的方案，是否要这么做取决于您是否有代码洁癖。方法是提供一个定制的 `Link` 标签，根据 URL 地址按需生成 `prefetch` 标签。这种方案最大缺陷是，如果用户不按照约定使用内置的 `Link`，`prefetch` 规则将会无效。
+**按需模式**，是理论和实践双重优雅的方案，是否要这么做取决于您是否有代码洁癖。方法是提供一个定制的 `Link` 标签，根据 URL 地址按需生成 `prefetch` 标签。这种方案最大缺陷是，如果用户不按照约定使用内置的 `Link`，`prefetch` 规则将会无效。
 
 ## 5 更多讨论