什么是事件代理（事件委托） 有什么好处
事件代理（也称为事件委托）是一种在 JavaScript 中处理事件的技术，它利用了事件冒泡机制。事件代理将事件处理程序绑定到一个父元素上，而不是将事件处理程序直接绑定到子元素上。当事件发生时，事件将在子元素上触发，并通过事件冒泡逐层传递给父元素，在父元素上执行事件处理程序。
事件代理的好处包括：
1. 减少内存消耗
通过将事件处理程序绑定到父元素上，而不是每个子元素上，可以减少页面中所需的事件处理程序数量，从而减少内存消耗。特别是在有大量动态生成的子元素的情况下，使用事件代理可以更好地管理事件处理。
2. 简化代码
通过使用事件代理，可以将事件处理逻辑集中在一个地方，减少重复的代码。当有多个子元素需要绑定相同的事件处理程序时，只需要在父元素上绑定一次即可，避免了在每个子元素上设置事件处理程序的繁琐工作。
3. 动态响应
事件代理使得在动态添加或删除子元素时，无需重新绑定事件处理程序。因为事件处理程序是绑定在父元素上的，当新的子元素被添加到父元素中时，它们会自动继承父元素的事件处理逻辑。
4. 处理未来元素
对于通过异步加载或其他方式动态生成的元素，事件代理可以处理这些未来元素。因为事件处理程序是绑定在父元素上的，所以无论何时新的元素出现，都能够正常地处理事件。
总的来说，事件代理通过将事件处理程序绑定到父元素上，简化了代码结构，提高了性能，并且能够动态响应和处理未来元素。它是一种常见的优化技术，在处理大量元素或动态元素的情况下特别有用。
路由原理 history 和 hash 两种路由方式的特点
history 和 hash 是两种常见的前端路由方式，它们在实现原理和特点上有一些区别。
1. history 路由方式
- 实现原理：使用浏览器的
pushState和replaceState方法来对浏览器历史记录进行修改，同时依赖 HTML5 的 History API。 - 特点：
- URL 更加美观：使用 history 路由方式时，URL 中不包含
#符号，看起来更加美观。 - 无需刷新页面：通过修改浏览器历史记录，可以实现在页面内容变化时，不需要刷新整个页面。这使得用户体验更加流畅。
- 更好的兼容性：history 路由方式依赖于 HTML5 的 History API，因此对于支持 History API 的现代浏览器，具有很好的兼容性。但对于不支持的旧版浏览器，需要提供回退方案。
- 需要服务器配置：使用 history 路由方式时，需要在服务器端进行配置，以确保刷新或直接访问某个子路由时，返回正确的 HTML 页面。
2. hash 路由方式
- 实现原理：通过修改 URL 中的 hash（
#）部分来改变路由状态，监听hashchange事件来响应路由变化。 - 特点：
- 兼容性好：hash 路由方式在各种浏览器中都具有很好的兼容性，包括旧版浏览器。
- 简单易用：使用 hash 路由方式相对简单，不需要服务器端配置，并且可以直接在浏览器中进行测试。
- URL 可见性差：hash 路由方式会将路由信息放在 URL 的 hash 部分，看起来不够美观。同时，因为 hash 的改变不会触发页面刷新，所以无法通过查看 URL 的变化来获取当前显示的页面状态。
- 存在安全隐患：如果在 URL 的 hash 中包含敏感信息，可能会有安全风险，因为 hash 信息会在请求中传递给服务器。
综上所述，history 路由方式使用 HTML5 的 History API，URL 更美观，无需刷新页面，但需要服务器配置；而 hash 路由方式兼容性好，简单易用，但 URL 可见性差，存在安全隐患。选择使用哪种方式取决于项目需求、目标用户和浏览器兼容性要求。
Webpack 有哪些优化手段
Webpack 是一个强大的前端构建工具，可以通过一些优化手段来提高构建性能和代码质量。下面列举了一些常见的 Webpack 优化手段：
1. 使用生产模式（production mode）
切换到生产模式可以启用各种优化，默认开启代码压缩、作用域提升等功能，减小输出包的体积。
2. 代码分割（Code splitting）
将代码拆分成多个较小的文件，按需加载，以减少初始加载时间。可以通过动态导入（Dynamic Import）或使用 Webpack 的 SplitChunksPlugin 来实现。
3. 按需加载（Lazy loading）
将某些模块延迟加载，只在需要时才进行请求和加载，以减少初始加载时间。可以使用动态导入（Dynamic Import）或 React 的 Suspense 和 lazy 函数来实现。
4. Tree shaking
通过静态分析的方式，去除未使用的代码，减小最终打包文件的体积。需要确保项目使用 ES6 模块语法，并在配置中开启相关选项（如 mode 设置为 production）。
5. 使用缓存
利用 Webpack 的持久化缓存功能（如 cache-loader 插件），将构建结果缓存起来，在下次构建时可以复用之前的缓存，加快构建速度。
6. 多线程/多进程构建
通过使用 Webpack 的 parallel-webpack、thread-loader 或 HappyPack 等插件，将构建过程拆分为多个子进程或线程，并行执行，提高构建速度。
7. 文件大小分析
使用工具（如 Webpack Bundle Analyzer）来分析打包文件的大小和组成，找出体积较大的模块或库，优化它们的引入方式。
8. 压缩优化
使用 Webpack 的插件（如 terser-webpack-plugin）对输出的代码进行压缩和混淆，减小文件体积。
9. 合理配置 resolve
通过合理配置 resolve.extensions 和 resolve.alias，可以缩短模块解析的时间，加快构建速度。
10. 懒加载第三方库
使用 Webpack 的 externals 配置项或动态导入的方式，将常用但体积较大的第三方库单独打包，实现按需加载。
这些是一些常见的 Webpack 优化手段，可以根据具体项目需求和性能瓶颈选择适合的优化策略。同时，了解 Webpack 的不同配置选项和插件也能更好地进行优化。
常用设计模式有哪些并举例使用场景
常用的设计模式有很多，以下列举几个常见的设计模式，并给出它们的使用场景：
1. 单例模式（Singleton Pattern）
用于确保一个类只有一个实例，并提供全局访问点。常用于需要共享资源的场景，例如日志记录器、数据库连接池等。
2. 工厂模式（Factory Pattern）
通过工厂类创建对象，而不是直接调用构造函数。常用于根据不同的条件创建不同类型的对象，例如根据配置文件类型创建不同的数据库连接对象。
3. 观察者模式（Observer Pattern）
定义了一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖它的对象都会得到通知并自动更新。常用于事件处理、UI 组件与数据模型之间的交互。
4. 装饰者模式（Decorator Pattern）
动态地将责任附加到对象上，扩展其功能。常用于在不修改原有对象的情况下，为对象添加新的行为或功能。
5. 适配器模式（Adapter Pattern）
将一个类的接口转换成客户端所期望的接口，使得原本不兼容的类能够协同工作。常用于集成已有代码或系统，以使其能够与新代码或系统进行交互。
6. 策略模式（Strategy Pattern）
定义了一系列算法，并将其封装起来，使得它们可以互相替换。常用于根据不同情况选择不同的算法或策略。
7. 模板方法模式（Template Method Pattern）
定义一个操作中的算法骨架，而将一些步骤延迟到子类中实现。常用于在父类中定义算法的结构和顺序，而将具体实现延迟到子类中。
8. 迭代器模式（Iterator Pattern）
提供一种顺序访问集合对象元素的方法，而不需要暴露集合的内部表示。常用于遍历和访问集合对象的元素。
以上只是一些常见的设计模式，不同的设计模式适用于不同的场景，具体使用哪种设计模式还需要根据具体需求和问题进行判断。同时，设计模式并非必须要使用，应根据实际情况判断是否需要引入设计模式来解决问题。
