随手记录自己的学习过程
本文适用人群：受到第三方 Cookie 影响，想要一些第三方 Cookie 解决方案的战友
本文可能会是我插图最多的文章之一，因为要解释清楚各种概念，可能需要引用很多张图片辅助消化。
尽管 Google 在 2022 / 2023 疯狂铺垫自己要禁用第三方 Cookie，大家马上改造，但实际上大部分人的工作还是在死线前后死亡冲刺。Google 官方宣称禁用第三方 Cookie 是为了「减少跨网站跟踪，同时确保让每个人都能免费访问在线内容和服务的功能」，但实际上好处还没感受到，却带来了一大堆麻烦。
上回我们说到 DNS 的基本知识以及 DNS 劫持的科普，那么 DNS 安全上又有哪些措施呢？
如同 HTTP 通信一样，默认的 DNS 查询同样也是明文的，那么必然也可能遭受到攻击，比如下图中表示了一次中间人攻击（图源 cloudflare）：
![dns-traffic-unsecured.jpg][1] 那么同样的，我们也可以通过加密流量的方式来保证数据的可靠性。对于 DNS 来说，主要有 DoT 和 DoH 两种。
本文为科普向，文字描述较为浅显易懂，不适合想要深入了解的读者。
在了解 DNS 劫持是怎么进行之前，我们需要先了解 DNS 是怎么进行的。这里回到一道经典的面试题：
当你在浏览器里输入 www.baidu.com 时做了哪些事情？
这道题之所以经典，是因为千人千面，你能从「前端」、「后端」、「运维」、「Devops」这几种工种中得到截然不同的答案。
而今天讨论的就是这个问题的第一步：「DNS」。
折腾群晖以来写过了好几篇文章，这次买了白群晖，因此这应该是黑群晖的最后一篇文章了，故事是这样的。
![16883043150658.jpg][1]
痛定思痛，连夜买了个白群晖——痛，非常痛，为双十一刚过而扭曲变形。从 PDD 买了 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]