再写项目时难免会出现部分代码写了却没有使用，代码量小没什么影响，但是当开发量多的时候，或是大量遗传代码叠加时，打包体积就会明显比较大。在webpack中可以使用tree-sharking进行代码优化。有两种代码优化策略tree-sharking(useExports)与sideEffect ，可以先大致了解一下什么时副作用

副作用

副作用（effect 或者 side effect）指在导入时会执行特殊行为的代码，而不是仅仅暴露一个或多个导出内容。polyfill 就是一个例子，尽管其通常不提供导出，但是会影响全局作用域，因此 polyfill 将被视为一个副作用。

sideEffect与useExports不同应对策略

使用webpack就会直接sharing掉这些‘死代码’，如import ‘…/…/.css’，了解过react，应该知道其高阶组件部分就是负效应下面会讲到，像

import {button} from ' xx'
...
...
...
withAppProvider()(Button);

sideEffect应对策略

根据官方文档，对于有负效应的code，sideEffect可以添加以下代码直接跳过相关模块的检查，避免被无意删除，因为他作用在模块层面，所以sideEffects 更为有效 是因为它允许跳过整个模块/文件和整个文件子树。

{"name": "your-project","sideEffects": ["./src/some-side-effectful-file.js", "*.css"]
}

最后，还可以在 [module.rules 配置选项]中设置 "sideEffects"。

tree-sharing应对策略

提示：所有导入文件都会受到 tree shaking 的影响。这意味着，如果在项目中使用类似 css-loader 的东西并导入了一个 CSS 文件，则需要将其添加到副作用列表中表示其存在副作用，以免在生产模式中无意中将它删除：
usedExports 依赖的 terser 就尝试去解决这些问题，但在许多情况下它仍然不确定函数的调用是否有副作用。但这并不意味着 terser 会由于无法解决这些问题而运作得不好。根本原因在于像 JavaScript 这类动态语言中很难可靠确定这一点。
主要使用方法，在副作用代码前面加入/*#__PURE__*/提示

var Button$1 = /*#__PURE__*/ withAppProvider()(Button);

光是这样可以删除部分副作用代码，但是引用的内容可能还会有副作用，这需要在我们需要在 package.json 中添加 ["sideEffects"]属性。
注意tree-sharking是静态分析工具，你动态使用import无效

参考文档：webpack