本文为科普向，文字描述较为浅显易懂，不适合想要深入了解的读者。

Get Started

在了解 DNS 劫持是怎么进行之前，我们需要先了解 DNS 是怎么进行的。这里回到一道经典的面试题：

当你在浏览器里输入 www.baidu.com 时做了哪些事情？

这道题之所以经典，是因为千人千面，你能从「前端」、「后端」、「运维」、「Devops」这几种工种中得到截然不同的答案。

而今天讨论的就是这个问题的第一步：「DNS」。

折腾群晖以来写过了好几篇文章，这次买了白群晖，因此这应该是黑群晖的最后一篇文章了，故事是这样的。

![16883043150658.jpg][1]

痛定思痛，连夜买了个白群晖——痛，非常痛，为双十一刚过而扭曲变形。从 PDD 买了 923+。

下文会介绍：

• 我是怎么把黑群晖修好的
• 怎么把黑群晖升级到 7.2
• 为什么买了 923+，数据迁移
• 周边设备

故事的背景来源于，今天产品提了一个需求：对某个模块更新了一种文案，理论上来说，其实这是一个 k-v 结构，比如我有一个 getTexts 接口，返回如下：

[
    { title: '你好', desc: '世界' },
    { title: '效果不错', desc: '追加一条' } // 本次追加
]

好久没更新了，本来想更新《前端是不是真的死了》，但是正好工作中发生了一些讨论，所以就改成先更新缓存了。 本文适宜对象：不太常设计缓存的各类工程师。

背景故事

今日的一个场景是：有一段国家信息数据，结构大概是：[{ region: 'CN', code: 12345, text: '中国' }] 这样的一个国家数组（实际字段不太一样），而在此之前这段信息存储在了一个提供给前端的外部接口中，你是一个提供给前端的 BFF，想基于这些数据进行二次处理。

之前本来在 12 月就应该写这一篇文章的，大致是同事需要做 SDK 开发，我要求必须要有对应测试，但对于怎么去设计测试比较迷茫，本来早在 19 年就写过一篇如何构造一些有意义的测试，但从某种角度来说这更偏后端一些，对于前端的测试来说有一些不同。 然后被裁了，本来不想写了，但之前帮做模拟面试以及被面试时其实都有提到一些内容，所以这里简单谈下我对前端测试的一些看法。 新读者注意：本人屁话较多，不喜勿喷，上角点叉。（我好脆弱啊哥哥.jpg）

什么时候我们需要测试

如果你的回答是：「当然是什么时候都需要测试」——那么恭喜你，你还没有接受过现实排期和业务的毒打（这里指的是国内互联网的情况）。

在过去的几个月里，除了写后端接口以外，大部分时间都在搞一些前端基础建设、技术方案的确立和整个链路的监控告警体系的搭配，而在整条链路中，SSR 起到了比重很大的一环。

有许许多多的文章都致力于教大家：怎么样去做一个 SSR 的 demo（包括一些库的文档），而作为系统的一环，除了怎么开发外，有许多更现实的问题等着我们去解决，而本文就以我们遇到的一些问题来抛砖引玉。

曝光埋点，顾名思义，是当元素出现在视口范围内上报的埋点。

这里有两个要点：

• 在视口范围内
• 元素可见

这两个内容决定了一个元素是否被曝光。

最近因为拉勾的会员要到期了，正好极客时间也送了免费会员，但是他们的客户端在电子书上的效果都比较差，而且是一个比一个差，所以就萌生了转成 epub 的想法（没错，pdf 只是顺便的）。

当然，pdf 对于平板来说更友好一点，而 epub 对于水墨屏电子书来说更友好，两者都比客户端更适合阅读和做笔记。

数据源

在数据源的获取中，简单介绍，我们会分为几段去获取数据，之后根据数据去制作目录：

![i-love-study-design.drawio.png][1]

从使用的角度去看，这可能是个老生常谈的问题，就连 TypeScript 官方文档都会给你一个个介绍：

Interfaces vs Types in TypeScript

Documentation - Everyday Types

Learn about difference between Type & Interface in Typescript

具体来说（翻译成中文来说）：

好久没更新博客了拿着很久之前记的笔记凑个更新吧。

package.json | npm Docs

package.json，一个前端项目的归属——万万没想到的是，它有很多学问，因此现在我们就来完整的盘点一下。