## 一、先问你一个小问题：

如果我们在百度上搜索“马云”这两个字，把时间设定在1998年到2005年，能搜出来的信息，大概有多少条呢？是1亿条，还是1000万条，还是100万条？

我在几个群问过，大家普遍的猜想是，应该是百万或者千万的级别。毕竟，互联网信息如此浩如烟海。马云作为那个时代的风云企业家，在网上留下的痕迹肯定是非常多的。


但实际上能搜出的全部结果如下：


![image.png](/static/img/3e4b7648f7e2ae5a80d09490a9480fc4.image.webp)

用百度搜索，选定日期范围为“1998年5月22日到2005年5月22日”，含有马云的信息，总共是1条（2024年5月22日数据）。

而仅有的这一条信息，也是虚假的。点进去会发现，文章的发布时间其实是2021年，不属于上面限定的时间段，只是不知怎么回事，它被莫名其妙地搜索出来。


也就是说，如果我们想要了解那一段时间关于马云的经历、报道、人们对他的讨论、他的讲话、公司的发展史等等，我们能得到的有效的原始信息量，是零。

你可能会觉得，这是不是百度的问题啊？如果换必应或谷歌，会不会能搜出来？

我测试过，这两个网站搜出来的有效信息，和百度没有太大区别，比百度略多一些，但也只是个位数。更多的也都是时间紊乱的无效信息，只不过不知道是什么技术原因，被错误地抓取出来。你可能还会觉得，是不是因为马云属于比较有争议的人，由于某种不可描述的原因，所以他的信息才无法搜到？

但实际上，不仅仅是马云的情况如此，我们去搜马化腾、雷军、任正非等，甚至是罗永浩和芙蓉姐姐这样在那个时候红极一时的网红，或周杰伦、李宇春那样曾经火遍全网的明星，结果也都一样的。如搜雷军的情况，结果是这样的：


![image.png](/static/img/ec22de9f332a24c14039e2fe16f1d85b.image.webp)

在测试过不同网站、不同人名、不同时间段之后，我发现一个令人震惊的现象：

几乎所有在那个年代曾经红火过的中文网站，如网易、搜狐、校园BBS、西祠胡同、凯迪猫眼、天涯论坛、校内网（人人网）、新浪博客、百度贴吧、以及大量的个人网站等，在一定年份之前的信息都已经完全消失不见了，甚至大部分网站是所有年份的信息都消失了。唯一例外的是新浪网，还能找到一些十几年前的信息，但也是极少数的寥寥几条，其他99.9999%以上的内容，全都消失了。

大家都没有意识到一个严重的问题：中文互联网正在迅速崩塌，移动互联网出现之前的中文互联网内容，已经几乎消失殆尽。

我们原以为，互联网是有记忆的，但没有想到，这种记忆，原来是像金鱼一样的记忆。

## 二、网上能找到的原始资料，每年都以断崖式的速度在锐减

我之所以注意到这个问题，是因为何加盐公众号的主题是研究牛人，所以我需要经常查找他们的资料。

这两年来，我有一个非常明显的感觉：网上能找到的原始资料，每年都以断崖式的速度在锐减。之前还能看到一些原始的报道，后来慢慢没有了；之前还能找到主人公的演讲或者他们写的文章，后来慢慢找不到了；之前还能看到很多采访或对谈的视频，后来慢慢消失了。

似乎有一个吞噬网页的怪兽，它沿着历史的时间线，从过去向着现在吞噬，先是小口小口，然后大口大口，把中文互联网的一切内容，以五年、十年为单位，一口吞掉。

等我们回过神来，会发现，在移动互联网之前曾经存在过的中文互联网的一切，不管是门户网站、机构官方网站、个人网页，还是校园BBS、公众论坛，还是新浪博客、百度贴吧，还是文件、照片、音乐、视频等，都已消失不见。

记得十几年前，我曾经因为换电脑，把一些照片和文章打成一个压缩包，存在某BBS上，几年之后发现，那整个BBS都没有了。我曾经用过hotmail的邮箱，里面有很多很珍贵的邮件，后来全都没有了。我还写过人人网、MySpace，后来全都没有了。

我们曾经以为互联网可以保留一切，但结果是一切都没能保留。

这让我想起刘慈欣《三体》里面提到过的“二向箔”。歌者文明发现了太阳系有智慧生物的存在，出于宇宙先进文明的清除本能，他们向太阳系扔出一张二向箔，于是，整个太阳系以光的速度从三维坍塌成二维，变化成一张酷似梵高“星空”的画片。一切生命、一切文明的痕迹，从此都不复存在。

在互联网上，我们已经处于二向箔的吞噬之中。这种二向箔可以称之为“时间的二向箔”，它吞噬的是时间那一维。

太阳系被歌者文明的二向箔拍扁之后，好歹还留下了一幅《星空》图，而互联网被时间的二向箔吞噬后，只留下一片虚空。

## 三、出现这种情况的根本原因

为什么会出现这种情况呢？我猜想，主要原因可能是两个：

### 经济原因。

网站的存在，需要服务器、需要带宽、需要机房、需要人员运维，还有很多杂七杂八的监管和维护费用，这些都是成本。如果是有战略价值（例如需要向外展示公司想要展示的信息），或者有短期流量价值（例如还时不时有较多的人上来看），同时公司账上也不差钱，那么还会有动力去维持。

但是如果公司在商业上走了弯路，没钱了，整个网站就会直接死掉。例如人人网就是典型代表。

即便公司还有钱，从运营的角度来看，如果一个网页一年到头都没有几个人来点击，对公司来说，就成了一笔负担，从经济上最理性的方法，就是直接关掉。搜狐、网易早年的内容大量丢失，以及以天涯论坛为代表的BBS集体消亡，都是这个原因。

### 监管原因。

总体而言，互联网信息的监管，是从无到有，从宽到严，从严到更严的过程。以前可以合法存在的内容，后来不符合监管要求了；或者是以前可以灰色存在的内容，后来被定义为黑色了。这些内容都会直接被咔嚓掉。

还有一些是随着时代的变化，舆论的两极分化越来越极端，以前“只道是平常”的内容，在后来的舆论环境中显得非常尖锐、敏感，尽管不违法，但是可能激化矛盾，形成混乱，监管方也有可能会要求处理掉。

除了官方部门之外，愤怒的网友，也时时充当着舆论监管员的角色。他们会翻出十几年前某人无意中说的某句话，揪着不放，把人网暴至“社会性死亡”。

但监管上最重要的影响，还不是监管部门的处理或愤怒网友的攻击，而是它们会造成公司与个人的“自我审查”。

因为谁也不知道，网站上存在的哪一条内容，某人曾说过的哪一句话，会不会在若干年后，给当事人带来灭顶之灾。最好的办法，就是直接把这些潜在的“定时炸弹”全部清除，也就是把网站关掉或者把内容全部删除。

当然，除了上述两个原因之外，还会有其他很多原因。

例如，在南斯拉夫解体之后不久，所有“yu”（南斯拉夫国名Yugoslavia的缩写）这个国际域名之下的网页内容全部消失了。又如，随着版权保护的加强，曾经随处可下载的音乐和电影网站，就都消失了。还有一些机构和个人，纯粹是由于自己的原因，不想在对外展示信息了，就把官网或个人主页关掉等等。

但这些原因都是次要的、局部的。整个互联网内容系统性的、大规模的消失，主要就是由于经济规律和自我审查。

本质上，互联网内容和生命一样，也受进化论的支配。其存在的标准只有一条：以尽可能低的成本争取尽可能多的注意力。

当一个内容能够在互联网上的海量内容中争取到足够多的注意力，而维持这个内容的成本（包括经济成本、监管成本和对抗监管的成本）比其他方式更低时，这个内容就有可能存活在互联网上。只不过它有可能会换一种呈现方式，例如从文字变为图片，从静图变为动图，从动图变为视频，未来可能从二维视频变为三维全息视频等等。承载这个内容的平台也会变迁，从门户网站到BBS，到个人博客，到微博微信，到抖音视频号，到未来可能一个我们不知道什么平台。

当一个内容不能再吸引到足够多的注意力，或者维持这个内容的成本比其他方式更高时，这个内容就会从互联网上消失。以电脑为浏览端、以网页为载体的传统互联网的集体消亡，只不过是这种“信息进化竞争”的必然结果而已。

生物的进化秘诀是“物竞天择，适者生存”，而互联网内容的进化秘诀是“信息竞，注意力择，适者生存”。由于网络效应，这种竞争比自然界还要猛烈万倍，残酷万倍。传统互联网不是单个物种式的灭绝，而是几乎所有内容的整体性灭绝。

每一代新的互联网崛起，旧的互联网必将崩塌，时间二向箔是所有网站、所有内容无可逃避的宿命。

# 四、我们这一代人，将是没有历史的

如果未来的文明是互联网的文明。我们这一代人，将是没有历史的。因为互联网没有留下我们的痕迹。

“没有历史”，这件事情重要吗？

当然很重要。

我曾经为了写邵亦波的文章，想尽了一切办法，试图找到邵亦波2007年参加《波士堂》节目的原始视频，以及他妻子鲍佳欣以“文爱妈咪”网名在宝宝树社区发了好几年的帖子。最终还是没有找到，只能深深遗憾。

虽然《红尘已忘邵亦波》那篇文章，依然很受大家欢迎，短短一周就有70多万人阅读，2万多人转发，但我十分肯定，我一定还是错过了某些非常重要的信息。如果它们能呈现在那篇文章里，文章质量会更好。

但是我找不到，就只能让文章以不完美的方式呈现。

你可能会觉得：这只是对何加盐这样的研究者和写作者有用，我又不写这样的文章，互联网信息没有就没了，对我又没什么影响。

真的吗？

如果我们已经看不到马云的所有演讲，看不到任正非的以《我的父亲母亲》和《一江春水向东流》为代表的所有文章，看不到段永平在雪球的所有发帖，你会不会觉得有点可惜？好吧，你说你并不觉得可惜。

那如果我们已经搜不到黄峥的公众号，看不到张一鸣的微博，上不了王兴的饭否，你会不会觉得有点遗憾？

好吧，你说你也并不觉得遗憾。

那如果某一天，知乎如同天涯论坛一样没了，豆瓣就像人人网一样消失，B站好比新浪博客一样已无人问津，你会不会有点心痛？

如果某一天，你喜欢的微博博主所有的微博只显示“作者已设置只展示半年内微博，此微博已不可见”，你常看的公众号只显示“此账号已被屏蔽，内容无法查看”，你在抖音或小红书搜索某些信息，结果显示“作者已清空全部内容”……

甚至，微博、公众号、抖音、小红书，就像曾经存在过的bbs、贴吧、空间、博客一样，全部消亡……

你会不会为此难过哪怕是短短的一分钟？

作为传统互联网的一代人，七零后、八零后已经找不回我们的历史。因为它们已经全部消失了。

新生代也许还能看看朋友圈，但是朋友圈也越来越多“三天可见”，越来越沉默不语。

唯一还在热情发圈的，只剩下一水的营销信息。

未来就连这些营销信息，也终将消亡。

# 五、中文互联网正在消亡

如果一件事对我们很重要，而它正在消亡，我们有什么办法挽救它吗？

有人曾作出这样的尝试。美国有一个网站叫做“Internet Archive”，中文译作“互联网档案馆”，保存了很多原始网页。但是我试过，中文的原始网页，保存的很少，而且使用非常麻烦，搜索功能十分原始低效，和没保存差不多。

从技术层面来讲，保存从中国有互联网以来，到移动互联网兴起的十来年时间的所有网页，应该并不难，成本也不高，毕竟比起现在的视频时代，原始互联网的那些图文网页，占的空间几乎可以忽略不计。

问题是，谁来做这件事，有什么动机？

商业机构不会做。因为没有任何商业利益。

政府或许可以像建图书馆、博物馆一样，搞一个能保存所有网页的档案馆。但是政府为什么要花钱费力干这件事？除了保存历史之外，似乎也没有其他理由。再说了，就算是政府做了这件事，对普通网民也没有任何意义，因为这个档案馆肯定也会需要一定的登陆权限，以免信息被滥用。

况且，就算是有机构愿意做这件事，现在也晚了。移动互联网兴起之后，传统互联网的中文内容，几乎已经消失殆尽了。粗略估算，99%以上应该都已经没有了。

从某种意义上，何加盐写的牛人系列文章，也为保存这些牛人们存在过的历史，做出了一点贡献。如果我没有写他们，很多历史就已经在网上找不到了。但毕竟这也不是原始信息，只是经我整合过的二手信息。

现在的中文互联网上，这个世纪前十年发生过的所有重大事件，所有留下过深深痕迹的名人，目前还能找到的信息，几乎已经全是经自媒体编辑过的二手信息，甚至是传过多手，早已面目全非的信息。

关于它们的原始报道没有了，原始视频没有了，原始讲话没有了，原始的网友目击没有了，原始的评论没有了……

再过一些年，这些二手信息和N手信息，也都会消失。就像那些事件从未发生过、那些人从未存在过一样。

我们已经无能为力，只能接受现实。

在未来的互联网时代里，回首看21世纪的前二十年，将是没有历史记录的二十年。

我们是互联网时代消失的一代人。

如果你现在还能看到一些中文互联网的古早信息，那只是夕阳的最后一抹余晖。

如果你明白了它们的转瞬即逝，可能会像临死前的浮士德一样感叹：

你真美啊，请停留一下吧。

但那抹余晖，很快将和你这句感叹一起，被时间的二向箔吞没，陷入虚空。

《三体》中，程心和艾AA还能有幸乘坐唯一的一艘曲率飞船，逃离正在二维化的太阳系。

而我们，连曲率飞船都没有。逃无可逃。

现在你所看到的、你所创造的几乎所有内容，连同这篇文章，这个平台，终究也会淹没在虚空中。

中文互联网时代正在快速崩塌

# 在 JavaScript 中实现和使用 Context



使用过 React 构建应用的开发者对 React Context 一定不会陌生。在 React 的世界中，相比于把 prop 不断透传给下一层子组件（prop-drilling），React Context 可以更优雅地自上而下将数据从父组件传递到深层级的子组件、并确保数据在不同子组件之间保持一致。不过，Context 绝不是仅属于 React，在 JavaScript 中 Context 一样可以大展拳脚。

## 调用栈与参数传递的噩梦

不论是用 UI 库构建应用，亦或者是组织大量的单元测试，亦或者是编写拥有复杂逻辑的后端程序，开发者经常会遇到在一个函数中调用另一个函数的情况。然后在被调用的另一个函数中，又不得不再调用第三个函数，直到整个调用栈已经有数层之深。在这些函数中传递变量很快就会变成一件非常混乱的事情：



```
const A = (a = 1) => {
  const b = fibonacci(a);
  const c = B(b, a);

  return c / d + 1;
}

function B(b, a) {
  return C(a) * b;
}

function C(a) {
  try {
    sideEffect(a);
    return 0;
  } catch {
    return 1;
  }
}

console.log(A(10));
```

在这个例子中，函数 `B` 其实并不直接用到变量 `a`，但是由于函数 `B` 需要调用函数 `C`、而函数 `C` 才需要用到变量 `a`，所以函数 `B`不得不接受 `a` 作为参数、以便将 `a` 传给函数 `C`。

这个例子已经被简化了很多；想象一下如果你的调用栈如果不止三层，而需要传递的变量不止一个，代码的复杂程度的增长速度很快就会让你措手不及。

在 React 的世界中，这个问题叫 prop-drilling，而 React 解决这个问题的办法就是 React Context：

## 在 React 的世界中

> Context lets the parent component make some information available to any component in the tree below it—no matter how deep—without passing it explicitly through props.
> -- [Passing Data Deeply with Context, React Docs](https://react.dev/learn/passing-data-deeply-with-context)

React 的 Context 就好像一个虫洞一样。在父组件之中创建一个 Context、并填充一些数据，然后这个 Context 下的所有子组件都可以通过 `useContext` 获取到这些数据、不论这些子组件有多深：

```
// sidebar-active-context.tsx
const SidebarActiveContext = createContext<boolean>(false);
const SidebarActiveDispatchContext = createContext<React.Dispatch<React.SetStateAction<boolean>>>(noop);

export const useSidebarActive = () => useContext(SidebarActiveContext);
export const useSetSidebar = () => useContext(SidebarActiveDispatchContext);
export const SidebarActiveProvider = ({ children }: React.PropsWithChildren) => {
  const [active, setActive] = useState(false);
  return (
    <SidebarActiveContext.Provider value={active}>
      <SidebarActiveDispatchContext.Provider value={setActive}>
        {children}
      </SidebarActiveDispatchContext.Provider>
    </SidebarActiveContext.Provider>
  );
};

// 上述代码只是一个简单的例子。在实际的 React 应用中，上述代码可以被封装为一个 utility 函数、减少 boilerplate 代码：
// https://foxact.skk.moe/context-state
import { createContextState } from 'foxact/context-state';
const [SidebarActiveProvider, useSidebarActive, useSetSidebarActive] = createContextState(false);
export { SidebarActiveProvider, useSidebarActive, useSetSidebarActive };
```

将应用包裹在 `<SidebarActiveProvider />` 中，任何子组件就可以通过 `useSidebarActive` 获取到当前的 Sidebar 状态、并通过 `useSetSidebarActive` 修改 Sidebar 状态；更棒的是，只有实际使用 `useSidebarActive` 的子组件才会在状态改变时触发 re-render、仅使用 `useSetSidebarActive` 的子组件完全不会 re-render。

跳出 React 去思考，有没有什么办法在 JavaScript 的世界中也实现一个 Context 呢？

## 实现一个自己的 Context

在继续之前，我需要强调一下，实现 Context 需要依靠 JavaScript 的两个非常重要的性质「[闭包](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures)」和「单线程」。这两个性质对于我们接下来实现 Context 来说非常重要。如果你对此很陌生，在理解接下来的内容时可能会有一些困难。

让我们看看 React Context 都是由哪些 API 组成的：

* `createContext`：创建一个 Context，基本上就是为我们创建了一个存储和读写变量的容器。
* `Provider`：Context 返回值的一个属性。在 React 中这是一个组件，也是我们「魔法虫洞」的入口
* `useContext` 和 `Consumer`：这是我们「魔法虫洞」的出口，调用时能从最近的 Context 中把变量拉出来。

为了便于理解，我们在实现 Context 时直接模仿一下 React Context 的 API：

```
const ValueContext = createContext();

// <ValueContext value={42}>
ValueContext.Provider(42, () => {
  callback1();
  callback2();
  // ....
});
// </ValueContext>

function callback1() {
  const value = useContext(ValueContext);
  console.log(value); // 42
}
```

知道了 Context 的 API 的形状，我们就可以开始搭建 Context 的框架了：

```
function createContext() {
  const Provider = (value, callback) => {
    // ...
  }

  const Consumer = () => {
    // ...
  }

  return {
    Provider,
    Consumer
  }
}

function useContext(contextRef) {
  // return ...
}
```

在这里我们声明了两个函数 `createContext`和 `useContext`。`createContext` 会返回一个 Context 对象，这个对象包含两个属性，分别是 `Provider` 和 `Consumer` 两个函数。`useContext` 接受的是 Context 对象本身的引用，我们希望它能够返回当前 Context 的值。

## 在 Context 中存储和读取变量

首先我们需要一个地方来存储 Context 的值。借助 JavaScript 的闭包特性，我们可以将这个值存在 `createContext` 的调用栈里：

```
function createContext() {
  let contextValue = undefined;

  const Provider = (value, callback) => {
  }

  const Consumer = () => {
  }

  return {
    Provider,
    Consumer
  }
}
```

现在，当我们调用 `createContext` 函数时，函数内部的作用域会创建一个变量 `contextValue`。这个变量属于当前函数的调用栈、不泄漏不共享。当多次调用 `createContext` 函数时，每个调用栈都会创建各自互不共享的 `contextValue` 变量。

现在，我们的 `contextValue` 已经储存在 `createContext` 的调用栈里了。接下来我们只需要让 `Provider` 能够从参数中接收一个值并存储在调用栈的变量里、再让 `Consumer` 能够读取这个变量：

```
function createContext() {
  let contextValue = undefined;

  const Provider = (value, callback) => {
    contextValue = value;
  }

  const Consumer = () => contextValue;

  return {
    Provider,
    Consumer
  }
}
```

现在 Context 返回的 `Consumer` 函数已经可以返回 `contextValue` 了，但是为了让我们的 API 更像 React 一些，我们可以通过 `useContext` 间接调用 `Consumer`：

```
function useContext(contextRef) {
  return contextRef.Consumer();
}
```

## 执行回调函数

光光存储和读取变量还不够。我们的 `Provider` 接受一个回调函数，这个回调函数需要在 `Provider` 被调用时执行：

```
function createContext() {
  let contextValue = undefined;

  const Provider = (value, callback) => {
    contextValue = value;
    callback();
  }

  const Consumer = () => contextValue;

  return {
    Provider,
    Consumer
  }
}
```

因为 JavaScript 单线程的特性，我们在调用 `callback` 函数的时候，不会有任何其它代码在执行、因此我们无需担心 `contextValue` 的值在 `callback` 函数执行期间会发生改变。

现在，我们的 Context 已经可以在回调函数中读取变量了。我们只需要在 `Provider` 的回调参数中调用 `useContext`，就可以在回调函数中读取到当前的 `contextValue` 了：

```
const ValueContext = createContext();
ValueContext.Provider(42, () => {
  someFn();
});

function someFn() {
  const value = useContext(ValueContext);
  console.log(value); // 42
}
```

## 嵌套 Context

注意观察我们的 `Provider` 函数：

```
const Provider = (value, callback) => {
  contextValue = value;
  callback();
}
```

每次当我们的 `Provider` 函数结束时，我们的 `contextValue` 依然是我们传入的值。这意味着如果我们在一个 `Provider` 的回调函数中再次调用 `Provider`，那么第二个 `Provider` 结束时就会把整个 Context 的 `contextValue` 设置为新的值。这样的话，我们就无法在第一个 `Provider` 的回调函数中读取到原始的 `contextValue` 了。

幸运的是，我们只需要在 `Provider` 函数中保存当前 `contextValue` 的值、然后在 `Provider` 函数结束时，将 `contextValue`重置为之前的值即可：

```
const Provider = (value, callback) => {
  const currentValue = contextValue;
  contextValue = value;
  callback();
  contextValue = currentValue;
}
```

现在，我们就可以嵌套 `Provider` 了：

```
const ValueContext = createContext();

ValueContext.Provider(42, () => {
  // 现在 contextValue 的值是 42、currentValue 的值是 undefined
  console.log(useContext(ValueContext)); // 42

  ValueContext.Provider(13, () => {
    // 现在 contextValue 的值是 13、currentValue 的值是上一层的 42
    console.log(useContext(ValueContext)); // 13

    ValueContext.Provider(2, () => {
      // 现在 contextValue 的值是 2、currentValue 的值是上一层的 13
      console.log(useContext(ValueContext)); // 2
    });

    // 我们退出了一层 Provider，现在 contextValue 的值被重置为 13，这一层的 currentValue 是上一层的 42
    console.log(useContext(ValueContext)); // 13
  });

  // 我们又退出了一层 Provider，现在 contextValue 的值被重置为 42
  // 已经没有更外面的 Provider 了，这一层的 currentValue 是 undefined
});

// 我们退出了最外层的 Provider，现在 contextValue 的值被重置为 undefined
```

## 最后的画龙点睛

我们已经实现了一个完整的 Context，但是我们的 Context 并不是完美的。例如，React Context 支持默认值，不在 `<Provider />`的子组件中调用 `useContext` 可以获取到默认值；由于我们的 Context 的初始值就是 `undefined`，意味着我们的 Context 就无法存储 `undefined`；即使是 React Context 也不完全是严格的，即使没有给 Context 提供默认值，依然可以在 `<Provider />` 的作用域之外调用 `useContext`。

我们可以通过一些小的改动来优化我们的 Context、并为我们的 Context 加上 TypeScript 类型声明：

```
// 我们使用 Symbol 来标记一个 Context 没有提供默认值
const NO_VALUE_DEFAULT = Symbol('NO_VALUE_DEFAULT');
type ContextValue<T> = T | typeof NO_VALUE_DEFAULT;

function createContext<T>(defaultValue: ContextValue<T> = NO_VALUE_DEFAULT) {
  let contextValue: ContextValue<T> = defaultValue;

  const Provider = (value: T, callback: () => void) => {
    const currentValue: ContextValue<T> = contextValue;
    contextValue = value;
    callback();
    contextValue = currentValue;
  }

  const Consumer = (): T => {
    // 只有当 Consumer 没有在 Provider 的作用域之内调用、且 Context 本身没有提供默认值时，
    // contextValue 才会是 NO_VALUE_DEFAULT 的 Symbol，此时我们可以抛出一个 TypeError
    if (contextValue === NO_VALUE_DEFAULT) {
      throw new TypeError('You should only use useContext inside a Provider, or provide a default value!');
    }
    // 由于 contextValue 的类型是 T | typeof NO_VALUE_DEFAULT，而我们在之前的 type guard 中
    // narrow 掉了 typeof NO_VALUE_DEFAULT，所以这里的 contextValue 的类型一定是 T
    return contextValue;
  };

  return {
    Provider,
    Consumer
  }
}
```

## 在实际场景中运用 Context

在 React 中使用 React Context 构建大型应用时十分方便，但是在更为广阔的 JavaScript 中，对 Context 编程范式的运用也比比皆是。以众多的 JavaScript 测试框架为例：

```
import { describe, it, beforeAll } from 'mocha';
import { expect } from 'chai';
// jest、bun、vitest 也都提供了类似的 API
import { describe, it, beforeAll, expect } from '@jest/globals';
import { describe, it, beforeAll, expect } from 'bun:test';
import { describe, it, beforeAll, expect } from 'vitest';

describe('add', () => {
  it('basic', () => {
    expect(add(1, 1)).toBe(2);
  });
});
```

`describe`、`it` 都是基于 Context 实现的。为了更好地理解 Context 的运用，我们不妨试着简单实现一下单元测试框架中的 `describe` 和 `it` 函数：

```
function describe(description, callback) {
  callback()
}

function it(text, callback) {
  try {
    callback()
    console.log("yeah~ " + text)
  } catch {
    console.log("ohno! " + text)
  }
}
```

在单元测试框架中，打印到控制台的信息不仅仅是来自 `it` 的 `text`，还有来自 `describe` 的 `description`：

```
add > yeah~ basic
add > ohno! basic
```

我们怎样才能在 `it` 函数中获取到上一层调用栈 `describe` 函数的 `description` 参数呢？这就是 Context 的大显身手的时候了：

```
const DescribeContext = createContext();

function describe(description, callback) {
  DescribeContext.Provider({ description }, () => {
    callback();
  });
}

function it(text, callback) {
  const { description } = useContext(DescribeContext);
  try {
    callback()
    console.log(description + " > yeah~ " + text)
  } catch {
    console.log(description + " > ohno! " + text)
  }
}
```

> 在上述代码中，`it` 函数只能打印当前最近一层的 `describe` 函数的 `description` 参数，遇到 `describe`函数嵌套时，就无能为力了。如何修改 Context 以实现记录所有 `describe` 函数的 `description` 参数，就留作读者的思考题了。

## 啊异步，烦人的异步

JavaScripe 语言本身是单线程的、同步的，但是 JavaScript 运行在的环境（浏览器、Node.js）却不是同步的。浏览器支持通过 fetch 发送网络请求，而 JavaScript 代码并不会完全停止运行、卡在那里等待服务器返回结果；Node.js 支持通过 `fs` 内置模块读写文件系统，而 Node.js 的 `fs` API 也同时支持同步和异步两种模式；绝大部分 JavaScript Runtime 都支持 Web 的 `setTimeout` API。

我们的 Context 的实现是建立在同步的基础上的，一旦我们的回调函数引入异步操作，我们就不再能保证 Context 能够正常工作：

```
const ValueContext = createContext(2);

ValueContext.Provider(42, () => {
  console.log(useContext(ValueContext)); // 42
  setTimeout(() => {
    console.log(useContext(ValueContext)); // 2 (?!?)
  }, 0);
  console.log(useContext(ValueContext)); // 42
});
```

在上面的例子中，我们在创建 Context 时设置了一个初始值 2。在 `Provider` 的回调函数中，通过 `setTimeout` 引入了异步操作。等到 `setTimeout` 内部的回调函数再执行的时候，`ValueContext` 内的 `contextValue`已经被重置为 2 了。

JavaScript 引入了 Promise，Generator、async/await，让我们可以更方便地编写异步代码。然而，一旦一个函数被送入了 [事件循环（Event Loop）](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop) 之中，这个函数的原始的调用栈就被替换成了事件循环、来自调用处的隐含信息（例如对调用栈上的变量的引用）也随之丢失了。

本文在这里不再介绍如何实现 AsyncContext。感兴趣的读者可以参考现在已有的实现：

* [Angular zone.js](https://github.com/angular/angular/blob/HEAD/packages/zone.js/lib/zone.ts)
* [Node.js AsyncLocalStorage](https://nodejs.org/api/async_context.html#class-asynclocalstorage)
* [Chrome DevTools Async Tagging API](https://developer.chrome.com/blog/devtools-modern-web-debugging/#linked-stack-traces)

除此之外，也已经有一个 [AsyncContext 的草案 `proposal-async-context`](https://github.com/tc39/proposal-async-context) 被提交给 TC39。截至本文写就，这个草案已经到达了 Stage 2，如果草案通过，那么 JavaScript 语言本身就会内置对 AsyncContext 的支持。

 在 JavaScript 中实现和使用 Context

# AI学绘画001-ComfyUI入门篇


<script async src="https://www.googletagmanager.com/gtag/js?id=G-P8BDTJ8V1Q"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-P8BDTJ8V1Q');
</script>

> 今天开始带大家从0到1学习目前很火的stable diffusion的一个工作流webUI框架ComfyUI。


##  01 介绍


ComfyUI 是由Comfy AnonyMous于2023年1月创建的，他创建了该工具用来学习和研究Stable Diffusion的工作原理。


![image.png](/static/img/a4cb6087e08718be0121694633877a8e.image.webp)


ComfyUI 是一个基于节点流程式的stable diffusion AI 绘图工具WebUI， 通过将stable diffusion的流程拆分成节点，实现了更加精准的工作流定制和完善的可复现性。相较于我们常用的WebUI，ConfyUI有如下这些优势和劣势：



优势：

1：轻量化，比SD更省内存，出图速度比SD快，硬件要求低，3G以上显存GPU也能工作很好。

2：模块化，按需启用不同模块，自由度更高。

3：灵活，工作流机制，可以把以往复杂多个页面切换使用的步骤在一个流程里面都搞定。

4：可以保存和共享工作流，可以使用别人的工作流，也可以分享给别人

5：基于这种架构，适合快速研究新东西

劣势：

1：操作界面复杂，学习曲线更大，对新手不友好

2：需要了解一些关于AIGC的底层的知识，要了解编码器、采样器等相关知识，ComfyUI就像拼积木，你需要了解一个完整的流程需要干嘛，才会挑选对应的积木来拼起来这个工作流。

3：插件数量相对于WebUI偏少，以后会变多。



![image.png](/static/img/48b12dda829113c07d34bf56db16b17b.image.webp)


据说在3G以上显存的GPU上也能工作,单从降低电脑配置方面来说，就值得来学了。

**总的来说，ComfyUI优点大于缺点的，只要你完全掌握了，它能给你带来无限的可能，所以，有兴趣的可以和我一起来学习ComfyUI技术，一起提高。**



## 02 安装教程

安装ComfyUI也很简单，点开下面官网：
https://github.com/comfyanonymous/ComfyUI

安装方式两种：

1：代码安装:
懂代码的，直接在指定目录执行 


```js
git clone https://github.com/comfyanonymous/ComfyUI.git
```
2：直接下载源码

官网上拉到下面这本，点击下载源码即可。

![](https://vlogs.iftballs.com/static/img/bdf4bee84ff88182c511005075ba93fc.image.webp)

安装好后，打开对应的文件夹，会像下图这样：


![image.png](/static/img/5dd1c9f220b3d35a0f66fc32fbd8faf8.image.webp)

大家可以看到两套启动器
run_cpu.bat 是支持没有N卡的同学运行，会使用cpu。

run_nvdia_gpu 是支持N卡的，我是直接运行这个脚本。

运行脚本后，控台看到提示下面这个地址，就说明运行成功了，浏览器也会自动弹出页面


![image.png](/static/img/7c448c9df6e2020aa497b5d6f68ad6e2.image.webp)

打开的页面默认是下图所示：


![image.png](/static/img/baff3979e6c5a15fbf6f5d1c9ef59cfc.image.webp)

这样算是首次启动成功了，但是我相信你看到这个，绝对是懵圈的，不懂从何下手，别着急，每个新人刚开始都这样，我们开始第一个图之前，先跟着教程安装下必备的几个插件。

## 03 必备插件的安装


这里只推荐2个必备的插件，是你开展后续工作的必备选项。

- 插件管理器
- 中文汉化插件

插件管理器这个插件很重要，有了它后，就有了一个统一管理插件的地方，后面需要的一些插件，直接通过这个管理器来安装即可。所以这个插件算是排在第一个要安装的。

插件地址：

https://github.com/ltdrdata/ComfyUI-Manager

ComfyUI 的插件都放在路径：

\ComfyUI_windows_portable\ComfyUI\custom_nodes 下面


![image.png](/static/img/d2b0df097e2abe57512a6db68bf20241.image.webp)

然后重启下 ComfyUI 即可。

这时候你会发现多了个 Manager的按钮

![image.png](/static/img/b67a71bafe4ae5dcf67624fbd4a84eb5.image.webp)

点击它就会弹出插件管理页面了


![image.png](/static/img/ac9a57fcb66ca84e6a1a7365bce7f1e4.image.webp)

到这里，就算成功了， 下面我们就可以通过这个插件管理器安装第二个插件，也就是中文翻译插件

打开 Install Custom Nodes，也就是安装节点。

输入关键词 Translation 就可以看到了， 我们安装 AIGODLIKE-COMFYUI-TRANSLATION 这个。


![image.png](/static/img/0300af321a446814c3d5e9c538dbcfcc.image.webp)

安装好了会会提示，需要我们重启一下，点击下图中这个按钮即可

![image.png](/static/img/66638d5be2607c7d963a147908061ce0.image.webp)

当然，你也可以直接源码安装，把下载的插件也放在

\ComfyUI_windows_portable\ComfyUI\custom_nodes下面即可。

最后也记得重启ComfyUI。

插件地址：

https://github.com/AIGODLIKE/AIGODLIKE-ComfyUI-Translation

重启之后你会发现变成中文了，如果后续还想使用英文版，可以点开设置，然后在语言栏选择你想要切换的语言即可。


![image.png](/static/img/5d938e4f512c61be80f83d74951a0136.image.webp)



## 04 出你的第一张图

到这里就算搞定了基本工作，目前你离画出第一张图就差一个步骤，就是把大模型放进去。

你可以去SD那边拷贝一个模型过来，放到路径：

\ComfyUI_windows_portable\ComfyUI\models\checkpoints


![image.png](/static/img/7e7ac2af9d61876524762acfae03f233.image.webp)

然后最左边节点点击选择你的模型，右边执行提示词队列（也可以快捷键Ctrl+Enter运行）就可以出图了。


![image.png](/static/img/c6e43d76df42fe281beeb9c092f36fa1.image.webp)

如果模型没有，记得刷新下页面。

OK，这样你就可以制作出第一图了，是不是很有成就感。

## 05 可选的步骤配置


### 5.1 共享 Stable diffusion模型
我相信如果你之前用过Stable diffusion的话，一定会有个疑问，我电脑已经有了 Stable Diffusion，我要用ComfyUI，难不成还要每次都要下载或者拷贝模型过来，臣妾的电脑空间撑不住了啊。

哈哈，放心，我一开始也这么纠结，不过呢官方早帮我们想到这一点了，如果你之前有玩Stable diffusion，ComfyUI支持模型共享使用 Stable diffusion的，就不需要额外再下载模型了。

我们打开目录

\ComfyUI_windows_portable\ComfyUI

找到下面的 extra_model_paths.yaml.example


![image.png](/static/img/3350116fa2ef7209276e159e31c4ddcf.image.webp)

改名成 extra_model_paths.yaml，也就是去掉后面的 .example

然后编辑这个文件 把 base_path后面的这个路径，改成你SD的文件路径即可。


![image.png](/static/img/35c53bca556ddf123e19eddbe1fd58fa.image.webp)

改完后的结果如下：


![image.png](/static/img/1381d25ccfe42e39bcc7378df32a0c1a.image.webp)

然后重启下 ComfyUI，你就可以发现可以选择的模型变多了。


![image.png](/static/img/9a4d42a43a2bb28989ea721ae9d10690.image.webp)

### 5.2 内存小于3G设置
如果你的GPU内存小于 3G ，需要调整下脚本

打开 run_nvidia_gpu.bat 在后面添加上 --lowvram


![image.png](/static/img/92b7d31562e638c9feede514c588e3d4.image.webp)


## 06 总结



今天这篇算是入门，后面会把一些常见的基础教程分享给大家， 一起学习ComfyUI，一起精进。


**推荐阅读：**

AI学绘画001-ComfyUI超简单入门篇

> 作者介绍作者：田帅萌，TiDB 社区北京地区组织者，布道师组委会成员，主要负责同程旅行TiDB、Redis、dts等技术栈。原文链接：https://tidb.net/blog/f8fcb853

> 表妹推荐理由：

阅读本文，您将深入了解TiDB从5.0到7.5.1的升级实战，获取性能翻倍、稳定性增强的秘诀。文章涵盖升级策略、问题解决、成本优化，以及如何通过社区互动推动产品进步，是数据库管理员和技术爱好者提升数据库性能的宝典。‍

![image.png](/static/img/9618aa5fe683c216d5ad0212a04b7166.image.webp)

# 一、背景 


为了更好的保障业务稳定性，针对老的 TiDB 集群进行升级操作。期望在五一之前把一部分的 TiDB集 群升级完成。

原因：因为每年五一、十一 这套TiDB集群都会有偶发的性能问题，导致业务报错。本质的原因是业务SQL复杂，索引数量多，导致优化器走错索引，造成全表扫描,Tikv cpu消耗异常，TiDB内存OOM。


在升级完成后，今年的五一期间，这套TiDB集群平稳运行，未造成故障，性能还有一定提升。通过TiDB的可观测性，能够发现问题SQL进行优化。

在跟TiDB的小伙伴交流中，得知当前版本和后续版本的主攻计划：

- 在TiDB 456 系列版本中，主要追求的是性能。
- 在TiDB 7系列版本，要求是主攻稳定性。‍




# 二、收益


## 01 从性能的角度来说：
大概有至少一倍的性能提升,升级之前：‍

![image.png](/static/img/da4a03113a437529de59078be24885a6.image.webp)

升级之后：


![image.png](/static/img/a9a5aaa695f8d8de06c27c6d5a7602e3.image.webp)


## 02 从稳定性和故障角度：

至少今年五一，这套 TiDB 集群平稳运行‍.

02从可观测行的角度：

dashboard 可分享:

可以分享给业务同学，业务也能通过dashboard 更直观的发现慢查询。
之前的版本中，dashboard采用root账户登陆，权限太大。而新的版本中采用了dashboardAdmin 账户更安全。

topSQL 使SQL无处遁行:

比如通过监控发现TiKV cpu升高‍

![image.png](/static/img/64ed39931adb1a15ce0818a1aa9d23ad.image.webp)


完全可以通过top SQL 发现问题SQL


![image.png](/static/img/8f918c565ca70eaf889f957966e2b1f6.image.webp)

**SQL执行计划绑定更方便:**

然后在根据SQL进行优化，比如添加SQL 或者绑定执行计划等手段。

现在SQL执行计划绑定也特别方便，可以在SQL语句分析里面，绑定执行计划:

![image.png](/static/img/dbc2fd98eccce81f247bccf4d393643a.image.webp)

# 三、升级的流程


这套TiDB集群毕竟核心，所有没有采用原地升级的方式，进行升级操作。而是采用新建一套集群 数据导入的方式进行。

主要的考虑 毕竟跨了2个大版本，以及这套集群的重要性。

为了升级这套集群，做了很多准备工作，可以简单分享一下。

表结构和数据导入:

数据校对，业务角度校对，DBA抽样校对，用于保障数据一致性。

历史的绑定计划，人工导入到新的集群。避免SQL走错索引，造成性能问题。

慢查询SQL 在新的集群，手动跑，进行性能校对。（我们自研了一个流量回放工具，主要用于MySQL的升级校对，理论上支持TiDB，但没进行测试，后续计划切换之前，先跑一次流量回放）。也可以先跟业务切预发环境，业务在预发环境进行测试，SQL兼容性以及性能。

# 四、升级期间遇到的问题


## 01 由于参数 设置问题，导致执行计划走错，性能下降严重。
- 参数 tidb_opt_agg_push_down 默认是关闭的。
- 这个变量用来设置优化器是否执行聚合函数下推到 Join，Projection 和 UnionAll 之前的优化操作。当查询中聚合操作执行很慢时，可以尝试设置该变量为 ON。
- 因为这套集群 都是 Join 等复杂SQL，理论上开启这个参数有性能提升，这套集群并没有开启tiflash，导致了执行计划跟旧集群完全不一样，没有正收益，有负收益而且影响很大。
- 由于目前 TiDB 优化器的 CBO 能力还不够完善，类似这样的参数还不能默认打开。这个变量对于 AP tiflash 来说大部分时间都是正收益，需要的时候可以考虑在确定打给 tiflash 的 query 连接上开启。
- 建议：默认参数不要动～‍

## 02 新的集群 copr_cache 没命中

- 通过 explain ANALYZE SQL 发现‍

![image.png](/static/img/0955d7574d8692634bbb132401a60033.image.webp)
- 增加配置 tikv-client.copr-cache.capacity-mb: 3000.0 （默认1000.0）
- TiDB-server的参数，缓存的总数据量大小。当缓存空间满时，旧缓存条目将被逐出。
- 当TiDB-server内存充足的情况下才能调整此参数。

# 五、未来规划

- 后续集群升级到7.x系列，我个人更看好8.1这个版本。
- 8.1这么多稳定性和性能提升。TiDB越来越好。‍

![image.png](/static/img/aaf55fad2d67e3d3217b424c6842d4a6.image.webp)

# 六、给TiDB的建议


## 01 创新和适应力
- 完善复杂SQL的执行计划绑定

    目前此功能不适用于带有子查询的查询、访问 TiFlash 的查询或连接 3 个或更多表的查询。

- 旧集群的执行计划绑定历史

    从7.1开始 及以上版本，可以down出来，导入新集群。（只要把mysql.bind_info 导出到新集群导入即可）

- 需要重新加载  

    强制重新加载绑定信息 ADMIN RELOAD BINDINGS;注：导入进去最好再验证下，新老版本要是有语法兼容变化可能导致部分bind 失效。

- TiDB针对大容量磁盘的支持

    TiDB 针对大容量磁盘支持，比如支持单个tikv 7T容量。

# 七、TiDB降本手段


针对历史数据，归档数据，进一步压缩，利用cpu换空间，比较适用写多，几乎不读历史数据的场景。可以修改参数：


```js
raftdb.defaultcf.compression-per-level:no no zstd zstd zstd zstd  zstd
raftdb.writecf.compression-per-level:no no zstd zstd zstd zstd  zstd
rocksdb.defaultcf.compression-per-level:  no no zstd zstd zstd zstd  zstd
rocksdb.writecf.compression-per-level :no no zstd zstd zstd zstd  zstd
```

如果是6系列版本可以进一步修改：

```js
coprocessor.region-max-size: 128M
coprocessor.region-split-keys: 1280000
coprocessor.region-split-size: 128M
```

增大 region size‍

# 八、总结


这次TiDB集群的升级之旅让我深刻体会到了细致规划和准备的重要性。通过与TiDB社区的交流和反馈，我看到了产品不断进步的可能。

我相信，随着TiDB的不断发展，它将为用户提供更加稳定、高效和易用的数据库解决方案。同时，我也期待未来能够与社区共同探索更多提升性能和降低成本的方法。

我们也可以看到TiDB集群升级对于提升性能、增强稳定性以及优化资源使用具有显著效果。我的亲身经历展示了升级过程中的细致规划和对潜在问题的深思熟虑，同时也反映出了TiDB社区对于产品持续改进的承诺和努力。‍ 总结如下：

**1、性能与稳定性提升**：升级后的TiDB集群在高负载情况下表现出色，性能得到至少一倍的提升，同时在重要的业务高峰期保持了稳定性。

**2、可观测性的增强**：新版本通过改进的dashboard和top SQL功能，使得慢查询和问题SQL的识别变得更加直观和便捷，同时提升了安全性。

**3、升级策略**：采取了新建集群和数据迁移的策略，以避免原地升级可能带来的风险，并通过详尽的准备工作确保了数据的一致性和完整性。
**4、问题解决**：在升级过程中遇到的问题，如参数配置导致性能下降和copr_cache未命中，都通过调整配置和增加缓存容量得到了有效解决。

**5、成本优化**：通过数据归档和压缩，利用CPU资源优化存储空间使用，为写入密集型场景提供了成本效益高的解决方案。

**6、社区互动的重要性**：在与TiDB团队的交流反映了社区的开放性和对用户反馈的重视，这对于开源项目的长期发展至关重要。总体而言，这篇文章不仅为TiDB用户提供了升级的参考经验，也为开源社区的互动和发展提供了宝贵的见解。通过不断的技术创新和社区合作，TiDB正朝着更高效、更稳定、更易用的分布式数据库系统迈进。

同城旅游Tidb集群从v5.0.0升级到v7.5.0性能提升2倍

# 重磅！50条坐月子注意事项来啦！新手妈妈必看！


![微信图片_20240511175957.jpg](/static/img/e3f7b25d44a9175cc2ef25f2bf320efd.384c22d10bd32b7ee4979f281f9e997b.webp)



![微信图片_20240511180027.jpg](/static/img/6de42c017c6639cffc724ff4caa96cce.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180027.webp)

![微信图片_20240511180033.jpg](/static/img/e0dd78be9796e0414382c4b46b946e5f.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180033.webp)

![微信图片_20240511180039.jpg](/static/img/89eef18ec034e592b04c37deca2925ab.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180039.webp)

![微信图片_20240511180044.jpg](/static/img/cbedbc29a9edbbeb16aee65742bdf761.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180044.webp)

![微信图片_20240511180058.jpg](/static/img/4bd041d356b436be4bca4f7384c94a0e.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180058.webp)

![微信图片_20240511180104.jpg](/static/img/c10889e2c5bf6e2f363aa5f0091a8ca6.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180104.webp)

![微信图片_20240511180109.jpg](/static/img/e2eea3c9791b11f754f91dca58c524ad.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180109.webp)

![微信图片_20240511180114.jpg](/static/img/2641550e77404f09bbe79edb6e93d867.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180114.webp)

![微信图片_20240511180119.jpg](/static/img/af02c12b5e8d394e2e120626a7fe4a96.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511180119.webp)

![微信图片_20240511181308.jpg](/static/img/69cd597950a33f301c52a9cb20f0f249.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181308.webp)

![微信图片_20240511181314.jpg](/static/img/9709feaba0347b9b59eb83a1088e8229.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181314.webp)

![微信图片_20240511181322.jpg](/static/img/42c0e425b217a2ca28b7dc17130e4576.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181322.webp)

![微信图片_20240511181326.jpg](/static/img/8d5f3b1e47ef2512b8938612739460a7.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181326.webp)

![微信图片_20240511181330.jpg](/static/img/d5c6e6ec95b319ca2e500815f413ceb9.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181330.webp)

![微信图片_20240511181335.jpg](/static/img/9bd862d8315152eebb7de96e45b63271.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181335.webp)

![微信图片_20240511181340.jpg](/static/img/00df64f70acad9bf361c4a42db754062.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181340.webp)

![微信图片_20240511181347.jpg](/static/img/27f14a19ebbe87282c507a1a817a8d5d.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181347.webp)

![微信图片_20240511181351.jpg](/static/img/5ece2093ba3244192118428e980b82ca.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181351.webp)

![微信图片_20240511181355.jpg](/static/img/aaf43c871df9beca7abf86f8b202cb8e.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181355.webp)

![微信图片_20240511181402.jpg](/static/img/e68327a563b644449aa4c3e17bb82017.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181402.webp)

![微信图片_20240511181407.jpg](/static/img/9292dbd668e1bddf356b05b7f43027e8.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181407.webp)

![微信图片_20240511181412.jpg](/static/img/0effab4745188c405d245a7dfb47d645.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181412.webp)

![微信图片_20240511181416.jpg](/static/img/8377f3ceada3824f90f4a822b47ca3fb.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181416.webp)

![微信图片_20240511181423.jpg](/static/img/3499050eb48bdc08de443800adc2bf1d.%C3%A5%C2%BE%C2%AE%C3%A4%C2%BF%C2%A1%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87_20240511181423.webp)

　　坐月子不能洗澡、不能走动、不能吃盐、不能刷牙…老人常说的这些禁忌，靠谱吗？盲目遵循，有可能损害健康。