# 为什么要这样做？

原生的 localStorage 只能监听同源地址下不同页面的 localStorage 变化，作为单页面应用，显然不实用。所以我打算自定义一个 hook 监听 localStorage 的变化。

# 思路

首先我们需要重写 localStorage 下的所有方法，这样在每个方法被使用的时候就可以被监听到了。

此时就需要一个事件机制，用于传递消息。

在 Vue3 移除了 $on 、 $emit 事件接口后，我们可以借助第三方库实现： mitt 、 tiny-emitter .

不过我打算使用自己实现的 中介者模式 作为通信方法。

# 简介

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

中介者模式（Mediator Pattern）又称为 调解者模式 或 调停者模式。属于行为型模式。

中介者模式 包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使它们可以松散耦合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。

中介者模式 是用来降低多个对象和类之间的通信复杂性。这种模式通过提供一个中介类，将系统各层次对象间的多对多关系变成一对多关系，中介者对象可以将复杂的网状结构变成以调停者为中心的星形结构，达到降低系统的复杂性，提高可扩展性的作用。

中介者模式 核心：通过中介者解耦系统各层次对象的直接耦合，层次对象的对外依赖通信统统交由中介者转发。

使用 Object.prototype 上的原生 toString () 方法判断数据类型，使用方法如下：

Object.prototype.toString.call(value)

# 前言

在开发过程中要求对 PDF 类型的发票提供 预览 和 下载 功能， PDF 类型文件的来源又包括 H5 移动端 和 PC 端 ，而针对这两个不同端的处理会有些许不同，下文会有所提及。

针对 PDF 预览 的文章不在少数，但似乎都没有提及可能遇到的问题，或是提供对应的具体需求场景下如何选择，因此，本文的核心就是结合实际需求场景下，看看目前各种实现方案到底哪一个更适合，当然希望大家可以在评论区对文中的内容进行斧正，或是提供更优质的方案。

基本要求：

• 支持 pdf 文件 内容的 完整预览
• 多页 pdf 文件 支持 分页查看
• PC 端 和 移动端 都需支持 下载 和 预览

产品要求：

• PC 端 的预览要支持在 当前页 进行预览
• pdf 文件 预览时的字体要 和 实际文件的 字体保证一致性

不辜负每一个阅读的人。

反思一下现实中，你有没有发现这样的现象：

• 当你想认认真真做点正事的时候，总会有各种因素干扰你。

• 学习没一会，你心痒难耐想打两把游戏，然后一打就是两小时；

• 工作刚开展，你又忍不住点开某短视频，然后一刷就是老半天。

其实这些 **“奶头乐” 的背后，都是 “多巴胺陷阱”**。

本文主体部分 翻译 + 搬运 自外网著名技术博客网站 medium.com 的一篇点赞数 2.7k 的文章 (文章链接在结尾处）

# 什么是 JavaScript 模块

JavaScript 模块指的是一段可复用的，独立的代码。他们通常都有特定的功能，能在整个代码系统里被引进或删除 —— 这个概念多少类似于 Java 或者 Python 中的类。

模块通常是独立的 —— 与其他代码解耦，因此方便修改。这也提高了代码的可读性和可维护性。模块化在使部分代码保持私有，仅暴露公共部分的的同时，还解决了命名空间模糊性的问题。

# 问题描述

• 面试官：后端一次性返回 10万条 数据给你，你如何处理？
• 我：歪嘴一笑，`what the f**k!

# 问题考察点

看似无厘头的问题，实际上考查候选人知识的广度和深度，虽然在工作中这种情况很少遇到...

• 考察前端如何处理大量数据
• 考察候选人对于大量数据的性能优化
• 考察候选人处理问题的思考方式（关于这一点，文末会说到，大家继续阅读）
• ......

文末会提供完整代码，供大家更好的理解

# 看似无处不在的 OOP

OOP 即 面向对象编程 （Object Oriented Programming）毫无疑问是软件设计和发展中的一大进步。事实上，一些编程语言如 Java 、C++ 就是基于 OOP 的核心概念 class 开发出来。

在高校的 CS 相关专业中，无论教授什么编程语言，OOP 的学习是绝对不会被落下的。

同时，OOP 在业界中也的确被大量使用，尤其是的后端服务领域、桌面软件、移动 APP 开发等。

因此，OOP 看起来在软件行业无处不在，在这种有点教条主义的氛围下，很多程序员甚至以为 class 是编程固有的概念 —— 然而并不是。

OOP 只是一套帮助开发者设计和编写软件的方法论，但并不代表它能解决所有领域的问题，也不是能在所有编程语言的任何场景下都适用。我们应避免陷入这种教条主义。

渲染优化是前端开发中非常重要的一部分，它涉及到提高页面加载速度、减少资源消耗、优化用户体验等方面。下面本人将结合自己所学知识，对一些常见的渲染优化技巧以及具体的示例进行说明。

# 1. 禁止使用 iframe

# 原因：

1. 阻塞主页面加载： iframe 会阻塞主页面的 onload事件 ，因为当 iframe 加载完毕之后，才会触发主页面的 onload事件 。这会导致主页面的加载速度变慢，影响用户体验。
2. 不利于搜索引擎优化（SEO） ：搜索引擎的爬虫程序无法解读 iframe 中的内容，因此 iframe 中的内容对于网页的 SEO 没有帮助。如果网页的重要内容被放在 iframe 中，可能会导致搜索引擎无法正确索引页面内容，降低网页的排名。
3. 影响页面并行加载： iframe 和主页面共享连接池，而浏览器对相同域的连接有限制，所以当页面中包含多个 iframe 时，会影响页面的并行加载能力，导致页面加载速度变慢。
4. 性能影响： iframe 的加载会消耗网络带宽和浏览器资源，尤其是当页面中包含大量的 iframe 时，会增加浏览器的负担，影响页面的性能和响应速度。