lei4519 / blog Goto Github PK

2024-04-21

一点点运动生理学

想聊训练，必须要知道练的是什么，更重要的是要知道底层发生了什么

骨骼肌纤维的类型

骨骼肌由两种肌纤维组成：

• I 型肌纤维（慢肌纤维）
• II 型肌纤维（快肌纤维）：快肌纤维也分为两个亚组，称为 IIa 型 和 IIb 型

肌纤维收缩遵循顺序募集模式，其中 I 型肌纤维是最先募集的。随着运动强度的增加，肌肉收缩需求增加，I 型肌纤维无法维持必要的需求。IIa 型肌纤维开始发挥作用，最终，随着强度的不断增加，IIb 型肌纤维最终将被招募

简而言之，慢肌纤维用于较慢的速度，快肌纤维用于较快的速度

每种肌纤维具有不同的生物特性，因此在运动和比赛期间具有不同的行为

• I 型肌纤维具有最高的线粒体密度和容量，因此在利用脂肪获取能量方面非常有效
• IIa 型纤维具有较低的线粒体密度和较高的利用葡萄糖的能力
• IIb 型肌纤维具有较小的线粒体密度，并且具有非常高的利用储存在这些纤维中的葡萄糖和 ATP 来提供即时无氧能量的能力

因此，每种运动强度意味着不同的代谢反应和肌纤维募集模式，这也对应于不同的训练区域，总结如下

三大供能系统

肌肉运动（收缩）需要能量，汽车需要汽油，肌肉需要「三磷酸腺苷」（ATP, Adenosine Triphosphate）

我们摄入碳水化合物、脂肪、蛋白质都会分解成更小的能源底物，并且通过 不同的化学反应 提供运动时肌肉收缩所需的 ATP

不同的化学反应就是指三种产生能量的方式，即三大供能系统：

• 有氧氧化系统（Aerobic Energy System ）
• 糖酵解系统（Glycolytic System）
• 磷酸元系统（ATP-CP System）

不同系统产生 ATP 的速度不同，产生 ATP 越快的系统，持续时间就越短

磷酸元系统（ATP-CP System）

不需要氧气，是提供 ATP 最快的途径

磷酸原系统的反应机制是依靠磷酸肌酸（PCr，又记作 CP）与 ADP（ATP 高能磷酸键断裂后的产物）反应重新合成 ATP。因为中间只涉及到一步反应，因此这一机制可以完成 ATP 的快速补充

但由于肌肉中 PC 的含量是有限的，所以只能提供短时的爆发能量（冲刺、爆发）

糖酵解系统（Glycolytic System）

糖酵解过程（葡萄糖分解为丙酮酸）是糖类分解供能的第一步，糖酵解系统分为快速糖酵解和慢速糖酵解

快速糖酵解是无氧反应，慢速糖酵解是有氧反应，因此在反应机制和能源底物方面，糖酵解系统和有氧氧化系统是一致的，只不过在氧气不足的情况下，接下来的有氧氧化反应无法继续进行

糖酵解和有氧氧化的能源底物是储存在肌肉中的肌糖原，这部分糖原分解、氧化后直接就可以产生 ATP 供肌肉使用了

而肝糖原以及血糖主要是起到支持的作用，因为从毛细血管扩散到肌肉中需要一定的时间（变为肌糖原？），并不直接参与上面的反应

但这不意味着肝糖原和血糖不重要，当肌糖原不足时，需要血糖即时补充，否则运动员将「力竭」而无法继续运动

在相同的一分子糖原消耗下，糖酵解过程净产生 ATP 数量（4ATP-2ATP=2ATP）只有 2 分子；而如果继续有氧氧化过程，则可以继续产生 34 分子的 ATP！

因此，糖酵解过程的能量效率是很低的。同时这也意味着，相同的运动能量消耗，如果是由糖酵解过程提供，大概要比有氧过程多消耗约 17 倍的糖原！

这就是骑行时过多的无氧输出（糖酵解供能）容易「爆掉」的原因之一： 在糖酵解供能下，糖原消耗速率太快，很容易造成肌糖原的枯竭

有氧氧化系统（Aerobic Energy System ）

在有氧供能条件下，能量底物与氧气充分反应生成 ATP

尽管单位能量底物的氧化只能提供为数不多的 ATP，但有氧氧化可以在运动过程中源源不断进行，在底物消耗殆尽或电解质失衡之前，有氧运动可以一直持续下去

什么是乳酸？

多年来，人们一直认为乳酸只是无氧运动产生的废物。甚至一度认为它会在运动后结晶，从而导致肌肉酸痛（现在我们知道这不是真的）

乳酸是骨骼肌细胞利用（消耗）葡萄糖的天然副产品（糖酵解系统），进入细胞的葡萄糖流量越高，乳酸的产量就越高（与氧气的可用性无关）

在高强度训练中，由于骨骼肌产生能量 (ATP) 的高收缩需求，II 型快肌纤维被充分募集，II 型肌纤维具有高度糖酵解能力（使用大量葡萄糖），所以会产生大量的乳酸

在剧烈运动期间，乳酸的产生量比静息水平高许多倍。与乳酸相关的氢离子 (H+) 的释放会导致收缩肌 pH 值显着降低，从而导致酸中毒（肌肉酸痛的原因）

但乳酸并不是废物，恰恰相反：乳酸是体内最重要的糖异生前体（新的葡萄糖生成剂）。我们在运动过程中消耗的所有葡萄糖中，约有 30% 来自乳酸「回收」（从乳酸重新变回葡萄糖，这是有氧氧化系统的能力）

而且不管你相信与否，乳酸对于大脑来说甚至至关重要，它是神经元使用的主要燃料。乳酸实际上对于长期记忆至关重要，甚至可能参与了解阿尔茨海默病。 （一些研究表明，当神经元对乳酸的摄取受到抑制时，长期记忆就会受到抑制）

乳酸与运动表现

在表 1 中可以清楚的观察到：运动员的竞技和训练水平越高，观察到的血乳酸积累就越少，功率输出和表现就越高

表 1. 不同级别的自行车运动员血乳酸水平（mmol/L）差异。表由 San Millán 等人修改，2009 年

这是一个重要的观察结果，科罗拉多大学的运动生理学家圣米兰博士将其归因于某种能力：「顶级运动员观察到的较低血乳酸水平是由于 乳酸清除能力的增强」

乳酸穿梭理论

当氧气充足时（即在较低或中等强度的运动期间），肌肉通过有氧能量途径获取能量（上）
在剧烈运动期间（当糖酵解率非常高时），更多地依赖红色途径，导致乳酸积累（右下）
然而，这种乳酸可以通过「乳酸穿梭」途径（最右边的红色箭头）分解为能量，提供充足的氧气。身体通过将乳酸从工作肌肉输送到身体含氧量较高的区域来实现这一目标

乳酸穿梭理论描述了身体将乳酸从工作肌肉（乳酸水平升高的地方）通过血液运送到氧合更好的区域的能力，在那里乳酸可以用作燃料。这些地方就是你的肝脏或肾脏、心脏，然后是你的大脑

乳酸可以被供应到血液中，然后被运送到几乎每个需要利用的器官

但这里有一个问题：这个过程需要时间（分钟级），而乳酸在运动过程中会不断产生（当乳酸被成功转化成能量时，对决/比赛可能已经结束了）

训练有素的运动员血乳酸水平低的原因是他们清除乳酸（乳酸再利用）的效率很高，向血液输出的乳酸较少，因为他们在产生乳酸的肌肉中就清除了大量乳酸，这只需要几秒或几毫秒的时间

这是非常有利的，因为它可以使收缩肌肉更快地去除 H+，并更快地「回收」乳酸以获得额外的能量 (ATP)

因为乳酸主要在快肌纤维中产生（糖酵解系统），而在慢肌纤维中清除（有氧氧化系统）。这是一个复杂的过程，这个过程涉及不同的乳酸转运蛋白和酶

• 快肌纤维富含一种称为 MCT-4（单羧酸盐 -4）的转运蛋白，可将乳酸从这些纤维中转运出去
• 慢肌纤维拥有一种称为 MCT-1 的转运蛋白，它在慢肌纤维内吸收乳酸。然后，乳酸在线粒体中通过一种称为 mLDH（线粒体乳酸脱氢酶）的酶转化为丙酮酸，最终合成 ATP（能量）

我们的训练目标似乎很明显：我们需要增加这些转运蛋白、酶和线粒体的数量，以提高我们的乳酸清除能力，从而大幅提高我们的整体运动表现

热身

良好的训练从热身开始，这是一个大致 的热身流程，你可以根据自己的需要进行调整

1. 通过骑行 10-30 分钟开始热身，逐渐将强度从约 45-50% FTP（2-3/10 努力水平）提高到约 65-80% FTP（3-4/10 努力水平），这将有助于温和地预热您的肌肉和韧带，并降低肌肉骨骼受伤的风险
2. 以约 103-108% FTP 或约 8/10 的努力水平完成约 6 分钟的努力
3. 轻松骑行（45-60% FTP 或 2-3/10 努力水平）5-15 分钟，然后开始训练

四种训练方式

1. Zone 2 Endurance Training（长有氧）

根据过去 18 年的经验，2 区耐力训练已证明是提高乳酸清除能力效果最好的训练区
-- San Milan

如前所述，有氧训练（Zone 2）的目的主要是通过增加在慢肌纤维中清除乳酸的 线粒体数量，以及增加 MCT-1 和 mLDH 的数量来提高乳酸清除能力

高强度和耐力训练都会增加 MCT-4 的数量，从而增加乳酸从快肌纤维的转运

这里的关键不是仅仅去了解它，而是要做到这一点：2 区耐力训练应占训练的大部分。你需要掌握基础知识以在无聊的训练中找到安慰

强度和持续时间在耐力训练中的作用

通过刺激使生成更多的线粒体，增强慢肌纤维 (I 型) 周围的毛细血管化，训练身体更有效地使用脂肪作为主要燃料来源，减少碳水化合物作为燃料的使用，从而提高乳酸门槛，因为相比糖酵解产生的乳酸更少

最终，这些耐力运动有助于乳酸门槛、肌肉耐力、更大的有氧能力 (关于肌肉通过毛细血管向线粒体输送氧气的能力) 和降低 VLamax(最大乳酸生成速率)

减少乳酸产生

为了减少无氧代谢的贡献，需要增加肌肉的有氧能力。有氧代谢在肌肉细胞内的线粒体中进行氧化脂肪和丙酮酸（或间接乳酸）以产生能量

因此，促进线粒体含量（肌肉内的数量/密度）和线粒体功能（参与氧化过程的酶的速度和效率）的训练将提高这种有氧能力，并相应地减少无氧代谢的贡献

最能刺激线粒体「含量」积极变化的训练方法似乎在很大程度上 与强度无关，而是与训练量和 训练持续时间 密切相关，线粒体「含量」已被证明是外周有氧能力（即肌肉内）的最大影响因素

因此，这些适应的关键刺激因素似乎是持续时间较长、强度较低、肌肉大量收缩的锻炼

此外，考虑到脂肪氧化不会产生任何乳酸，特别有利于与改善脂肪氧化而不是碳水化合物氧化相关的适应的训练将特别有利于减少乳酸的产生

同样，以脂肪氧化率最大化（通常约为 55-75% FTP）的强度进行长时间、低强度的骑行是实现这一目标的最佳选择

对于那些在训练中难以控制功率输出（即强度纪律不佳）的自行车手来说，重申这一点很重要：线粒体的这些适应并不会通过强度的增加而得到改善，即在锻炼中更加努力并不会增加适应性刺激或由此产生的适应的幅度

事实上，这样做会增加因疲劳而缩短锻炼时间的风险，并且不太重视脂肪氧化系统的工作，从而降低锻炼的质量

Warmup  
  
- 1m 55%  
- 2m 62%  
- 2m 65%  
  
7x  
- 30m 68%  
  
# 有氧锻炼的后期，增加几组低踏频的锻炼，增加肌肉力量  
4x  
- 2m 90%  
- 2m 55%  
- 10m 68%  
  
Cooldown  
  
- 2m 65%  
- 2m 60%  
W1m 55%  

2. Sweet Spot Training（甜区）

「甜蜜点」 是一种刚好低于乳酸门槛的强度，可以持续相当长的时间

然而，当它被纳入一个更平衡的训练计划时，它仍然是一种有用的训练形式

特别是，甜区训练也显示出对乳酸清除能力的有益适应，有助于增加快肌纤维的有氧能力

因为低节奏和中等高功率会导致这些纤维被招募的比例更高，但在足够低的强度下，这种激活仍然主要是有氧的，所以这会使它们的有氧效率变得更好，因此线粒体密度增加、MCT-4、MCT-1 和 mLDH 增加

脂肪氧化也得到改善，并且随着肌肉毛细血管化的增强，可以提供更好的氧气供应，从而进一步改善乳酸清除率

除此之外还有如下益处：

• 增加耐力
• 增加肌肉力量和在低节奏下产生力量的能力
• 提高了后期骑行的效率和经济性

甜区训练一般在 FTP 的 88-94% 下进行

SS: Lower Cadence Blocks

逐浙热身，然后在大约 88-94% 的 FTP 之间进行 2-3 组 10-30m 的训练

最好使用 50-70 RPM 的踏频（除非你的膝盖有问题，在这种情况下使用你最自然的、舒服的踏频）

训练的 RPE 应该在 7/10 左右（即相当舒适，但并不「容易」）

你会注意到在这些努力过程中你的呼吸适度加快，但你仍然可以在呼吸之间说简短的句子，心率通常会上升到 75-85% Max HR

WU  
- 1m 55%  
- 1m 60%  
- 2m 68%  
- 1m 75%  
- 1m 82%  
- 1m 90%  
- 2m 65%  
  
3x  
- 20m 89%  
- 3m 50%  
  
CD  
- 2m 65%  
- 2m 60%  
- 2m 55%  

3. Over/Under Intervals（上/下间歇块）

在 2010 年，Tim Kerrison 接任了天空车队（现为英力士）的运动主管。他是整个车队转型的一部分，是边际收益大师，Kerrison 和天空队至今闻名的一件事是他们的上/下间歇训练

这种方式的训练包括多个「上/下」间歇块，主要目标是在「无氧阈值 (AT) 以上」部分积累乳酸，然后在「降至无氧阈值以下」部分恢复以清除乳酸

AT 通常称 为 FTP，尽管它们不是同一件事，但这是构建训练区的简单方法

如上所述，这种类型的训练就是教你的身体在持续的压力下有效地清除乳酸并重新获得葡萄糖作为燃料

功率和持续时间的正确组合应该允许每个区块持续至少 8-10m

很难给出具体的强度和持续时间的目标，因为这些可能是非常可变的，这取决于你的乳酸产生率和清除率

不过，总的来说，RPE 应该在 7/10 左右，心率应该大致在 80-90% Max HR 之间

这些锻炼不仅可以激发乳酸清除能力，还可以保持自行车训练的针对性：比赛节奏往往变化很大。进攻、爬坡、侧风、鹅卵石和狭窄的道路都塑造了一个动态的比赛结构，使用上/下块，您就已经为即将发生的事情做好了准备

训练计划

这种训练有很多变种，你可以混合进行不同形式的训练，并根据自己的情况进行功率区间的微调（甚至可以自定义自己的训练）

• 3 个 12 分钟的块，每个块使用 1-2m 105-110% + 1-2m 80-85% 的交替 3 次，之后是 5m 55% 的休息

Warmup  
...  
  
3x  
- 2m 110%  
- 2m 80%  
  
- 5m 55%  
  
3x  
- 2m 110%  
- 2m 80%  
  
- 5m 55%  
  
3x  
- 2m 110%  
- 2m 80%  
  
- 5m 55%  
  
Cooldown  
...  

• 1:4 的上/下比例，3 个 15 分钟的块，每个块以 1m 120-125% + 4m 70% FTP（有氧区间以下）交替 3 次，之后是 5m 55% 的休息

Warmup  
...  
  
3x  
- 1m 125%  
- 4m 68%  
  
- 5m 55%  
  
3x  
- 1m 125%  
- 4m 68%  
  
- 5m 55%  
  
3x  
- 1m 125%  
- 4m 68%  
  
- 5m 55%  
  
1ooldown  
...  

• 3 个 12 分钟的区块，每个块在 45s 115-125% + 2m15s 80-85% 交替 4 次，之后以 55% 休息 5m

Warmup  
...  
  
3x  
- 45s 125%  
- 2m15s 80%  
  
- 5m 55%  
  
3x  
- 45s 125%  
- 2m15s 80%  
  
- 5m 55%  
  
3x  
- 45s 125%  
- 2m15s 80%  
  
- 5m 55%  
  
Cooldown  
...  

4. Steady State Lactate Threshold Intervals（稳态乳酸阈值间隔）

值得注意的是，上面的「乳酸阈值」间隔不会直接提高乳酸清除率

阈值间隔几乎都在使用快肌纤维，清除是通过慢肌纤维完成的。这就是为什么我们需要在乳酸堆积后进行较低强度的配速变化

然而，在 FTP 上进行的间歇训练对于增加 MCT-4 转运蛋白、从肌纤维中提取乳酸并提高乳酸耐受性仍然非常有效

我们还希望能够在比赛中通过 FTP 产生动力，因此需要练习在 98-103% FTP 下进行 3x15m 或 2x20m 的锻炼

值得注意的是，即使间歇性最大摄氧量间隔也可以提高乳酸清除率。例如，Billat 30/30 间隔（30 秒开启，30 秒关闭），对于训练有素的运动员来说尤其如此。因为 30 秒的休息时间太长，无法保持足够高的摄氧量，因此作为乳酸清除锻炼效果更好

中枢适应 (central factors)

作为骑车人如何增加最大摄氧量

目标：保持最大心率的 90-95% 左右尽可能长的骑行

原因：通过以下方式促进每搏输出量的适应

1. 左心室体积和壁厚度的改善
2. 增加的体积带来更大的拉伸，从而产生更大的弹性反冲力

本质上是想通过向心肌填充大量血液来「拉伸」心肌，这样它就可以增加容量并提高其收缩强度，从而在每次跳动时输送更多的血液

4 分钟恒定功率间隔

warm up  
  
- 1m 55%  
- 1m 63%  
- 1m 70%  
- 1m 78%  
- 1m 85%  
  
3x  
- 1m 100%  
- 1m 55%  
- 1m 130%  
- 2m 55%  
  
6x  
- 4m 120%  
- 4m 55%  
  
CD  
  
- 5m 45%  

外周适应 (peripheral factors)

目标：在高强度肌肉纤维内部和周围建立更大的毛细血管和线粒体密度

原因：

• LSD 训练可以说是增强线粒体和毛细血管密度的最佳但压力最小的训练方法之一，因为它可以促进许多肌肉收缩：特别是通过有效的慢肌收缩（I 型）和可塑性肌肉收缩（IIa 型），这些收缩在线粒体生物发生的信号传导中发挥关键作用
• 与慢肌纤维相比，快肌纤维（ IIb 型）需要 I 型和 IIa 型纤维都无法完全承受的负荷才可发生这种激活
• 因此，需要通过不同强度的骑行来刺激不同肌肉纤维的毛细血管和线粒体密度的适应：较长时间、较低强度的有氧骑行激活 I 型和 IIa 型纤维；冲刺中是理想的激活 IIb 型纤维的募集

VO2 动力学解释：骑行者需要了解的知识

VO2max: Hard Start Intervals

一组持续 3-8 分钟的间歇，从远高于阈值 (大约 120-130% FTP 或 8.5/10 的努力水平，持续 20 到 60 秒) 的硬起步开始，以迅速提高心率和耗氣量

然后根据间隔的长度调整到大约 100-115% FTP 之间的强度 (更短的间隔功率更高)，这一部分应该保持在 90% Max HR 以上

使用 1:1 或 2:1 的恢复间隔，例如 5 次硬启动间隔，每次在 120-130% FTP 时开始 30 秒，然后在 100-108% FTP 骑行 4.5 分钟，在 45-55% 的 FTP 下每次间隔恢复 3 分钟

目的：这个训练的主要目的是提高最大摄氧量 (即你可以吸收和处理氧气以产生能量的最大速率)

这种训练被认为在帮助提高心输出量 (心脏每秒可以泵出的血量) 方面特别有效，因为心率非堂接近最大值

研究表明，像这样的硬启动间隔比恒定的功率间隔可以更快的启动心跳速率（接近最大值）

WU  
  
- 1m 55%  
- 1m 63%  
- 1m 70%  
- 1m 78%  
- 1m 85%  
- 1m 100%  
- 1m 85%  
- 1m 100%  
- 3m 55%  
  
7x  
  
- 30s 130%  
- 4m30s 110%  
- 4m 45%  
  
CD  
  
- 5m 40%  

VO2max: Microbursts

这种间隔设计包括 2-4 个区块的「微爆发」间隔，或者换句话说，非常短、剧烈的努力，由同样短的恢复分开

每次微爆发通常持续 15 到 45 秒，在每个区块内，工作恢复比通常在 1:1 到 2:1 之间 (根据我们的经验，2:1 的间隔往往效果最好）

例如：3 个 9 分钟的方块，30 秒 「难」，15 秒「容易」

微爆通常在 120-130% FTP 左右，你可能需要增加或减少功率目标

微爆发的恢复间隔应该非常容易（45% FTP）

你应该看到心率至少达到 85% Max HR，总体来说，每一次努力的感觉应该是 8/10 的努力水平，你应该呼吸困难

每个块通常持续 9-15 分钟，中间大约有 3-5 分钟的轻松骑行

目的：和之前的训练一样，这次训练的目标是提高最大摄氧量

这些间歇训练的原理是，心率和耗氧量在每个区城向上漂移到最大水平。在每个区块中包含「微恢复」 允许实现合理的长时间区块，从而在最大心率和 VO2max 的高百分比下花费更长的总时间

warm up  
  
- 1m 55%  
- 1m 63%  
- 1m 70%  
- 1m 78%  
- 1m 85%  
- 1m 96%  
- 1m 105%  
- 1m 120%  
- 1m 55%  
  
15x  
  
- 30s 130%  
- 30s 45%  
- 3m 40%  
  
15x  
  
- 30s 130%  
- 30s 45%  
- 3m 40%  
  
15x  
  
- 30s 130%  
- 30s 45%  
- 3m 40%  
- 5m 110%  
  
cold down  
  
- 5m 40%  

VO2max: Microbursts 2

warm up  
  
- 1m 55%  
- 1m 63%  
- 1m 70%  
- 1m 78%  
- 1m 85%  
- 1m 96%  
- 1m 105%  
- 1m 120%  
- 1m 55%  
  
12x  
  
- 40s 130%  
- 20s 40%  
- 4m 40%  
  
12x  
  
- 40s 130%  
- 20s 40%  
- 4m 40%  
  
12x  
  
- 40s 130%  
- 20s 40%  
- 4m 40%  
- 5m 110%  
  
cold down  
  
- 5m 40%  

More

RCA

如何在限制碳水化合物供应 (RCA) 的情况下进行训练

限制碳水化合物的可用性（RCA）可以让身体更有效的使用脂肪，延缓碳水化合物（「糖原」）储存的消耗，还可以通过减少给定功率输出下乳酸（以及相关的疲劳代谢物）的产生来帮助提高乳酸阈值（以及类似的阈值功率/FTP/临界功率）

RCA 主要有以下三种方法：

1. 「隔夜禁食」方法包括在早上吃或喝任何含有碳水化合物的东西之前进行训练。肝糖原储存和血糖水平在一夜之间逐渐下降，并且在早上开始训练时通常会低于基线
2. 「每天两次」方法包括一天训练两次，在两次训练之间消耗最少的碳水化合物。第一个疗程会耗尽肌糖原储备，这意味着第二个疗程的肌糖原水平较低
3. 前两种方法的结合，我们称之为「低睡眠」策略，在 RCA 训练前一天晚上完成高强度训练，消耗肌肉糖原储存。在那次训练之后，碳水化合物的摄入量就会受到限制，这意味着这些储存不会得到补充。 在隔夜禁食后的早晨进行 RCA 训练，这意味着 RCA 训练以低肌肉糖原、肝糖原和血糖开始

VT1 Test（有氧阈值测试）

在 45-55% FTP 之间骑行 5 分钟

然后，尽可能地控制你的力量，以大约 2 - 3% 的 FTP 增量骑 5m，从 55% FTP 开始，到 85% FTP 结束

在每个阶段的最后一分钟，大声背诵字母表，并注意说话的舒适程度

对于每个阶段，将其分为「易说」、「难说」或「不确定」。请在活动后评论中记录你对每个阶段的分类

然后在 55-75% 的 FTP 之间稳定地骑行剩余的路程

你的 VT1 是呼吸感觉舒适的最高功率。如果你的呼吸感觉不舒服，或者你不确定，那么这个能力被归类为高于你的 VT1

目的: 本课程的目的是确定您的第一个通气阈值 (VT1) 位于何处。你的 VT1 是你的呼吸频率从舒适过渡到稍微升高的一个点，它与你开始从碳水化合物中获得大量能量的强度相关。这也是一个接近你的「脂肪最大值」的强度 (即你以最大速率氧化脂肪的强度)。VT1 的位置对于长距离耐力比赛非常重要，因为它标志着你可以持续数小时的强度上限

REF

• What is Lactate and Lactate Threshold
• The Lactate Shuttle Theory - Roberto Vukovic
• Sports Performance Bulletin - High intensity training - Pump your lactate shuttle: make lactate your friend, not foe!
• 分而治之与人体三大供能系统
• **時的能量來源是什麼？三大能量系統為何？營養師來告訴你。 - 營養麵包 - 呂孟凡營養師
• The Ultimate Interval Training Guide for Cyclists: Why and How to Do Intervals

2021-03-01

前言

好的程序员懂得如何从重复的工作中逃脱：

- 操作DOM时，发现了Jquery。  

- 操作JS时，发现了lodash。  

- 操作事件时，发现了Rx。  

Rxjs 本身的 概念 并不复杂，简单点说就是对观察者模式的封装，观察者模式在前端领域大行其道，不管是使用框架还是原生 JS，你一定都体验过。

在我看来，Rxjs 的强大和难点主要体现对其近 120 个操作符的灵活运用。

可惜官网中对这些操作符的介绍晦涩难懂，这就导致了很多人明明理解 Rxjs 的概念，却苦于不懂的使用操作符而黯然离场。

本文总结自《深入浅出 Rxjs》一书，旨在于用最简洁、通俗易懂的方式来说明 Rxjs 常用操作符的作用。学习的同时，也可以做为平时快速查阅的索引列表。

阅读提醒

• 流的概念

• 订阅：调用 subscribe
• 吐出：调用 next
• 完成：调用 complete

需要注意流的完成和订阅时间，某些操作符必须等待流完成之后才会触发。

其实根据操作符的功能我们也可以大致推断出结果：如果一个操作符需要拿到所有数据做操作、判断，那一定是需要等到流完成之后才能进行。

创建流操作符

创建流操作符最为流的起点，不存在复杂难懂的地方，这里只做简单的归类，具体使用查阅官网即可，不再赘述。

同步流

• create：new Observable
• of
• range
• repeat
• empty
• never
• throw
• generate

异步流

• interval/timer
• form：string/number/数组/类数组/promise/generator
• formPromise
• formEvent
• formEventPattern
• ajax
• repeatWhen
• defer：订阅时再创建

合并类操作符

订阅多条流，将接收到的数据向下吐出。

Concat

首尾连接

• 依次订阅：前一个流完成，再订阅之后的流。

• 当流全部完成时 concat 流结束。

  

concat(source1$, source2$)  

Merge

先到先得

• 订阅所有流，任意流吐出数据后，merge 流就会吐出数据。

• 对异步数据才有意义。

• 当流全部完成时 merge 流结束。

  

merge(source1$, source2$)  

Zip

一对一合并（像拉链一样）

• 订阅所有流，等待所有的流都触发了 i 次，将第 i 次的数据合并成数组向下传递。
• 其中一个流完成之后，等待另一个流的同等数量数据到来后完成 zip 流。
• 当我们使用 zip 时，期望第一次接受到的数据是所有的流第一次发出的数据，第二次接受的是所有的流第二次发出的数据。

zip(source1$, source2$)  

combineLatest

合并所有流的最后一个数据

• 订阅所有流，任意流触发时，获取其他所有流的最后值合并发出。

• 因为要获取其他流的最后值，所以在刚开始时，必须等待所有流都吐出了值才能开始向下传递数据。

• 所有的流都完成后，combineLatest 流才会完成。

  

combineLatest(source1$, source2$)  

withLatestFrom

合并所有流的最后一个数据，功能同 combineLatest，区别在于：

• combineLatest：当所有流准备完毕后（都有了最后值），任意流触发数据都会导致向下吐出数据。

• withLatestFrom：当所有流准备完毕后（都有了最后值），只有调用 withLatestFrom 的流吐出数据才会向下吐出数据，其他流触发时仅记录最后值。

  

source1$.pipe(withLatesFrom(source2$, source3$))  

Race

胜者通吃

• 订阅所有的流，当第一个流触发后，退订其他流。

race(source1$, source2$)  

startWith

在流的前面填充数据

source1$.pipe(startWith(1))  

forkJoin

合并所有流的最后一个数据

• 订阅所有流，等待所有流全部完成后，取出所有流的最后值向下发送。

forkJoin(source1$, source2$)  

辅助类操作符

Count

当前流完成之后，统计流一共发出了多少个数据。

source$.pipe(count())  

mix/max

当前流完成之后，计算 最小值/最大值。

source$.pipe(max())  

Reduce

同数组用法，当前流完成之后，将接受的所有数据依次传入计算。

source$.pipe(reduce(() => {}, 0))  

布尔类操作符

Every

同数组，需要注意的是：如果条件都为 true，也要等到流完成才会吐出结果。

原因也很简单，如果流没有完成，那怎么保证后面的数据条件也为 true 呢。

source$.pipe(every(() => true / false))  

find、findIndex

同数组，注意点同 every

source$.pipe(find(() => true / false))  

isEmpty

判断流是不是一个数据都没有吐出就完成了。

source$.pipe(isEmpty())  

defaultIfEmpty

如果流满足 isEmpty，吐出默认值。

source$.pipe(defaultIfEmpty(1))  

过滤类操作符

Filter

同数组

source$.pipe(filter(() => true / false))  

First

取第一个满足条件的数据，如果不传入条件，就取第一个

source$.pipe(first(() => true / false))  

Last

取第一个满足条件的数据，如果不传入条件，就取最后一个，流完成才会触发。

source$.pipe(last(() => true / false))  

Take

拿够前 N 个就完成

source$.pipe(take(N))  

takeLast

拿够后 N 个就结束，因为是后几个所以只有流完成了才会将数据一次发出。

source$.pipe(takeLast(N))  

takeWhile

给我传判断函数，什么时候结束你来定

source$.pipe(takeWhile(() => true / false))  

takeUntil

给我一个流 (A)，什么时候这个流 (A) 吐出数据了，我就完成

source$.pipe(takeUntil(timer(1000)))  

Skip

跳过前 N 个数据

source$.pipe(skip(N))  

skipWhile

给我传函数，跳过前几个你来定

source$.pipe(skipWhile(() => true / false))  

skipUntil

给我一个流 (A)，什么时候这个流 (A) 吐出数据了，我就不跳了

source$.pipe(skipUntil(timer(1000)))  

转化类操作符

Map

• 接受上游传入的值，返回一个其他的值给下游。（如果你还返回上游的值，那就没有任何意义了）

source$.pipe(map(() => {}))  

mapTo

• 将传入的值给下游。

source$.pipe(mapTo("a"))  

Pluck

• 提取上游吐出对象的某个 key，传给下游。

source$.pipe(pluck("v"))  

有损回压控制

对防抖、节流不了解的请自行查阅相关说明。

Throttle

传入一个流 (A)，对上游数据进行节流，直到流 (A) 吐出数据时结束节流向下传递数据，然后重复此过程

source$.pipe(throttle(interval(1000)))  

throttleTime

根据时间 (ms) 节流

source$.pipe(throttleTime(1000))  

Debounce

传入一个流 (A)，对上游数据进行防抖，直到流 (A) 吐出数据时结束防抖向下传递数据，然后重复此过程

source$.pipe(debounce(interval(1000)))  

debounceTime

根据时间 (ms) 防抖

source$.pipe(debounceTime(1000))  

Audit

audit 同 throttle，区别在于：

• throttle：将节流期间接受的第一个数据发出
• audit：将节流期间接受的最后一个数据发出

source$.pipe(audit(interval(1000)))  

auditTime

同上，不再赘述

source$.pipe(auditTime(1000))  

Sample

• 正常的流，上游触发，下游就会收到数据。
• 使用了 sample 之后的流，会将上游发出的最新一个数据缓存，然后按照自己的节奏从缓存中取。
• 换句话说，不管上游发出数据的速度是快是慢。sample 都不管，他就按照自己的节奏从缓存中取数，如果缓存中有就向下游吐出。如果没有就不做动作。

传入一个流 (A)，对上游数据吐出的最新数据进行缓存，直到流 (A) 吐出数据时从缓存中取出数据向下传递，然后重复此过程

source$.pipe(sample(interval(1000)))  

sampleTime

根据时间 (ms) 取数

source$.pipe(sampleTime(1000))  

Distinct

• distinct 前缀表示去重操作

所有元素去重，返回当前流中从来没有出现过的数据。

传入函数时，根据函数的返回值分配唯一 key。

source$.pipe(distinct())  
Observable.of({ age: 4, name: "Foo" }).pipe(distinct((p) => p.name))  

distinctUntilChanged

相邻元素去重，只返回与上一个数据不同的数据。

传入函数时，根据函数的返回值分配唯一 key。

source$.pipe(distinctUntilChanged())  

distinctUntilKeyChanged

• distinctUntilChanged 的简化版，帮你实现了取对象 key 的逻辑。

source$.pipe(distinctUntilKeyChanged("id"))  

ignoreElements

忽略上游的所有数据，当上游完成时，ignoreElements 也会完成。（我不关心你做了什么，只要告诉我完没完成就行）

source$.pipe(ignoreElements())  

elementAt

只获取上游数据发出的第 N 个数据。

第二个参数相当于默认值：当上游没发出第 N 个数据就结束时，发出这个参数给下游。

source$.pipe(elementAt(4, null))  

Single

• 检查上游的所有数据，如果满足条件的数据只有一个，就向下发送这个数据。否则向下传递异常。

source$.pipe(single(() => true / false))  

无损回压控制

• buffer 前缀：将值缓存到数组中，吐出给下游。
• window 前缀：将值缓存到一个流中，吐出给下游。

bufferTime、windowTime

缓存上游吐出的数据，到指定时间后吐出，然后重复。

source$.pipe(bufferTime(1000))  

bufferCount、windowCount

缓存上游吐出的数据，到指定个数后吐出，然后重复。

第二个参数用来控制每隔几个数据开启一次缓存区，不传时可能更符合我们的认知。

source$.pipe(bufferCount(10))  

bufferWhen、windowWhen

传入一个返回流 (A) 的工厂函数

流程如下：

1. 触发订阅时，调用工厂函数拿到流 (A)，开始缓存
2. 等待流 (A) 发出数据时，将缓存的值向下吐出
3. 重新调用工厂函数，拿到一个新的流 (A)，开启缓存，循环往复。

randomSeconds = () => timer((Math.random() * 10000) | 0)  
source$.pipe(bufferWhen(randomSeconds))  

bufferToggle、windowToggle

第一个参数为开启缓存流 (O)，第二个参数为返回关闭缓存流 (C) 的工厂函数

流程如下：

1. 当开启流 (O) 吐出数据时，调用工厂函数获取关闭流 (C)，开始缓存
2. 等待关闭流 (C) 吐出数据后，将缓存的值向下吐出
3. 等待开启流 (O) 吐出数据，然后重复步骤 1

source$.pipe(bufferToggle(interval(1000), () => randomSeconds))  

buffer、window

传入一个关闭流 (C)，区别与 bufferWhen：传入的是流，而不是返回流的工厂函数。

触发订阅时，开始缓存，当关闭流 (C) 吐出数据时，将缓存的值向下传递并重新开始缓存。

source$.pipe(buffer(interval(1000)))  

累计数据

Scan

scan 和 reduce 的区别在于：

• reduce：只有当流完成后才会触发
• scan：每一次流接受到数据后都会触发

区别于其他流，scan 拥有了保存、记忆状态的能力。

source$.pipe(scan(() => {}, 0))  

mergeScan

同 scan，但是返回的不是数据而是一个流。

• 当上游吐出数据时，调用规约函数得到并订阅流 (A)，将流 (A) 返回的数据向下游传递，并缓存流 (A) 返回的最后一个数据。当上游再次吐出数据时，将缓存的最后一个数据传给规约函数，循环往复。

source$.pipe(mergeScan(() => interval(1000)))  

错误处理

Catch

捕获错误

source$.pipe(catch(err => of('I', 'II', 'III', 'IV', 'V')))  

Retry

传入数字 N，遇到错误时，重新订阅上游，重试 N 次结束。

source$.pipe(retry(3))  

retryWhen

传入流 (A)，遇到错误时，订阅流 (A)，流 (A) 每吐出一次数据，就重试一次。流完成，retrywfhen 也完成。

source$.pipe(retryWhen((err) => interval(1000)))  

Finally

source$.pipe(finally())  

多播操作符

Multicast

接收返回 Subject 的工厂函数，返回一个 hot observable（HO）

当链接开始时，订阅上游获取数据，调用工厂函数拿到 Subject，上游吐出的数据通过 Subject 进行多播。

• 返回的 HO 拥有 connect、refCount 方法。
• 调用 connect 才会真正开始订阅顶流并发出数据。
• 调用 refCount 则会根据 subscribe 数量自动进行 connect 和 unsubscribe 操作。
• 多播操作符的老大，较为底层的设计，日常使用不多。
• 后面的多播操作符都是基于此操作符实现。

source$.pipe(multicast(() => new Subject()))  

Publish

• 封装了 multicast 操作符需要传入 Subject 工厂函数的操作，其他保持一致。

source$.pipe(publish())  

Share

基于 publish 的封装，返回调用 refCount 后的结果（看代码）

source$.pipe(share())  
// 等同于  
source$.pipe(publish().refCount())  

publishLast

当上游完成后，多播上游的最后一个数据并完成当前流。

source$.pipe(publishLast())  

publishReplay

传入缓存数量 N，缓存上游最新的 N 个数据，当有新的订阅时，将缓存吐出。

• 上游只会被订阅一次。

source$.pipe(publishReplay(1))  

publishBehavior

缓存上游吐出的最新数据，当有新的订阅时，将最新值吐出。如果被订阅时上游从未吐出过数据，就吐出传入的默认值。

source$.pipe(publishBehavior(0))  

高阶合并类操作符

• 高阶操作符不是高级操作符
• 当一个流吐出的不是数据，而是一个流时，这就是一个高阶流，就像如果一个函数的返回值还是一个函数的话，我们就称之为高阶函数
• 高阶操作符就是操作高阶流的操作符

如下代码示例，顶层的流吐出的并不是普通的数据，而是两个会产生数据的流，那么此时下游在接受时，就需要对上游吐出的流进行订阅获取数据，如下：

of(of(1, 2, 3), of(4, 5, 6))  
	.subscribe(  
		ob => ob.subscribe((num) => {  
			console.log(num)  
		})  
	)  

上面的代码只是简单的将数据从流中取出，如果我想对吐出的流运用前面讲的操作符应该怎么办？

cache = []  
of(of(1, 2, 3), of(4, 5, 6))  
	.subscribe({  
		next: ob => cache.push(ob),  
		complete: {  
			concat(...cache).subscribe(console.log)  
			zip(...cache).subscribe(console.log)  
		}  
	})  

先不管上述实现是否合理，我们已经可以对上游吐出的流运用操作符了，但是这样实现未免也太过麻烦，所以 Rxjs 为我们封装了相关的操作符来帮我们实现上述的功能。

总结一下：高阶操作符操作的是流，普通操作符操作的是数据。

concatAll

对应 concat，缓存高阶流吐出的每一个流，依次订阅，当所有流全部完成，concatAll 随之完成。

source$.pipe(concatAll())  

mergeAll

对应 merge，订阅高阶流吐出的每一个流，任意流吐出数据，mergeAll 随之吐出数据。

source$.pipe(mergeAll())  

zipAll

对应 zip，订阅高阶流吐出的每一个流，合并这些流吐出的相同索引的数据向下传递。

source$.pipe(zipAll())  

combineAll

对应 combineLatest，订阅高阶流吐出的每一个流，合并所有流的最后值向下传递。

source$.pipe(combineAll())  

高阶切换类操作符

Switch

切换流 - 喜新厌旧

高阶流每吐出一个流时，就会退订上一个吐出的流，订阅最新吐出的流。

source$.pipe(switch())  

Exhaust

切换流 - 长相厮守

当高阶流吐出一个流时，订阅它。在这个流没有完成之前，忽略这期间高阶流吐出的所有的流。当这个流完成之后，等待订阅高阶流吐出的下一个流订阅，重复。

source$.pipe(exhaust())  

高阶 Map 操作符

看完例子，即知定义。

例子

实现如下功能：

• mousedown 事件触发后，监听 mousemove 事件

普通实现

mousedown$ = formEvent(document, "mousedown")  
mousemove$ = formEvent(document, "mousemove")  
  
mousedown$.pipe(  
  map(() => mousemove$),  
  mergeAll()  
)  

1. 当 mousedown 事件触发后，使用 map 操作符，将向下吐出的数据转换成 mousemove 事件流。
2. 由于返回的是流而非数据，所以需要使用 mergeAll 操作符帮我们将流中的数据展开。
3. 这样我们最终接受到的就是 mousemove 的 event 事件对象了。

注：由于只有一个事件流，所以使用上面介绍的任意高阶合并操作符都是一样的效果。

高阶 Map 实现

mousedown$.pipe(mergeMap(() => mousemove$))  

不难看出，所谓高阶 map，就是

concatMap 	= map + concatAll  
mergeMap 		= map + mergeAll  
switchMap 	= map + switch  
exhaustMap 	= map + exhaust  
concatMapTo = mapTo + concatAll  
mergeMapTo 	= mapTo + mergeAll  
switchMapTo = mapTo + switch  

Expand

类似于 mergeMap，但是，所有传递给下游的数据，同时也会传递给自己，所以 expand 是一个递归操作符。

source$.pipe(expand((x) => (x === 8 ? EMPTY : x * 2)))  

数据分组

groupBy

输出流，将上游传递进来的数据，根据 key 值分类，为每一个分类创建一个流传递给下游。

key 值由第一个函数参数来控制。

source$.pipe(groupBy((i) => i % 2))  

Partition

groupBy 的简化版，传入判断条件，满足条件的放入第一个流中，不满足的放入第二个流中。

简单说：

• groupBy 根据 key 的分类，可能会向下传递 N 条流。
• partition 只会向下传递两条流：满足条件的和不满足条件的。

source$.pipe(partition())  

结语

以上就是本文的全部内容了，希望你看了会有收获。

如果有不理解的部分，可以在评论区提出，大家一起成长进步。

祝大家早日拿下 Rxjs 这块难啃的骨头。

参考资料

• 官方文档
• 《深入浅出 Rxjs》

2024-04-16

TL;DR

年前自己的 Mac 进水了，考虑良久（穷...）还是组了台台式机，作为一个终端重度使用者，Windows 用的真要发疯，果断切换到 Linux...

查了半天资料，对 Arch 比较感兴趣，主要想在使用的过程中实践一下操作系统相关的知识

本文记录一下折腾的过程（万一后面滚挂了...）

ArchWiki 在手，万事不愁

Pre Install

制作 U 盘引导工具

在 U 盘里制作一个微型系统，用于安装真正的系统

我用的 Mac，所以按照 U 盘安装介质 - Arch Linux Wiki

# 查看自己的 U 盘名称，一般是 /dev/disk2  
diskutil list  
# 先卸载 U 盘  
diskutil unmountDisk /dev/diskXA  
# 将镜像写入到 U 盘中  
dd if=$path/$archlinux.iso of=/dev/rdiskX bs=1m  

进入 U 盘系统

先通过 BIOS 进入 U 盘系统中

联网

首先需要联网 WIFI

# 进入交互式提示符  
iwctl  
# 如果不知道你的网络设备名称，列出所有 WiFi 设备  
device list  
# 扫描网络，注意替换设备名（注意：这个命令不会输出任何内容）  
station $device scan  
# 列出所有可用的网络  
station $device get-networks  
# 连接到一个网络  
station $device connect $SSID  
# 退出 or Ctrl+d  
quit  

ping baidu.com 试下网络是否连接成功

验证引导模式

先看一下系统目前的引导模式，后面要用到

检查 UEFI 位数：

cat /sys/firmware/efi/fw_platform_size  

如果命令结果为  64，则系统是以 UEFI 模式引导且使用 64 位 x64 UEFI
如果命令结果为  32，则系统是以 UEFI 模式引导且使用 32 位 IA32 UEFI，虽然其受支持，但引导加载程序只能使用  systemd-boot
如果文件不存在，则系统可能是以 BIOS 模式（或  CSM  模式）引导。

分区

因为我已经有一个 Windows 系统了，并且还要接着使用，所以不能直接格式化

扩展 Windows EFI 分区

之前的 EFI 分区只有 300M 大小，需要扩大一点，这里我扩到了 1G，参考 Create EFI

对已有 EFI 分区的进行扩展，可以自行搜索教程

简单点说就是先把已存在的 ESP 分区中的内容 Copy 出来，分好新区之后把内容再放回去就行了

Windows 软件分区

因为已经有 Windows 了，所以我直接在 Win 中用 DiskGenius 分好 Linux 所需要的区了：分别是一个主系统分区和一个同内存大小的 SWAP 分区（我还专门给系统备份分了一个区）

进入到 U 盘系统之后，通过命令找到自己的主系统分区和 SWAP 分区的设备名

# 列出所有的设备  
fdisk -l  

先通过如下命令更改一下主系统分区的文件系统的格式

滚动升级发行版建议用 btrfs ，滚之前做个快照，滚挂了能立即恢复。

挂载系统盘到 U 盘系统

# 格式化  
mkfs.btrfs $dev -f  
mount $dev /mnt  
# btrfs 系统的子卷，备份用（参考 timeshift, Ubuntu 的类型布局）  
btrfs subvolume create /mnt/@  
btrfs subvolume create /mnt/@home  
umount $dev  
mount $dev /mnt -o subvol=@  
mount $dev /mnt/home -o subvol=@home --mkdir  

挂载启动分区（Windows 已经有了，所以不用创建直接挂载即可，正常应该创建一个分区用来放引导）

EFI system partition - ArchWiki

# timeshift 需要是这个路径  
mount $efi_dev /mnt/boot/efi --mkdir  

制作 SWAP 分区

mkswap $dev  
# 启用  
swapon $dev  

镜像

使用 vim /etc/pacman.d/mirrorlist，在开头加上镜像源

Server = https://mirrors.ustc.edu.cn/archlinux/$repo/os/$arch  
Server = https://mirrors.tuna.tsinghua.edu.cn/archlinux/$repo/os/$arch  

更新一下 pacman -Syu

Install

人生苦短，我用 archinstall

好处是根据配置项一个一个选择，一些相关的依赖会提示你选择 or 自动帮你选择

坏处自然就是帮你做了选择... 囧（对于想完全自定义的人来说是坏处吧

但对于新手来说，推荐的反而更省心

下面根据需要配置的选项顺序一个一个说

Mirrors

上面已经配置了，所以这一步可以直接跳过

主要是这一步虽然可以通过选择 Mirror region 后选 Chind，但安装速度依然很慢（可能默认的地理位置离我都比较远

Disk Configuration

如果像我一样已经分好区了并挂载到 U 盘系统中了，这里就选择 Pre-mounted configuration，然后输入 /mnt 回车

正常的话会看到 /mnt 中已挂载的分区名称

Bootloader

根据上面 验证引导模式 的结果选择合适的引导，我的是 64，所以选了 Grub

Hostname

设置一下主机名字，我直接用的 root

Root Password

设置一下 root 密码

User account

再创建一个普通用户，日常用的就是这个

Profile

选择桌面环境、驱动之类的，可以按照自己的需要选择

🔍 linux 桌面环境（kde/gnome/xface）、窗口管理器 (dwm/i3/bspwm)

Type

我选的是 Desktop -> Hyprland

硬件访问选了 polkit ，其实我也不知道应该选哪个，但是我在 Must have – Hyprland Wiki 上搜到了 polkit ，没有搜到 seatd

Graphics driver 显卡驱动默认所有 all open-source

Greeter 默认 sddm （如果有多个桌面环境/窗口管理器，可以在登录时进行选择切换

Audio

我选择了 pipewire ，简单说 pipewire 是更新的产物，兼容 PulseAudio

这里有一篇文章可以详细查看：PipeWire vs PulseAudio: What's the Difference?

Kernels

默认了 linux

Kernel - Arch Wiki

Additional Packages

archinstall 已经默认安装了如 base base-devel linux linux-firmware efibootmgr 等包

如果有其他需要安装的包，可以在这里输入（使用空格分隔多个包）

我需要如下包：man git zsh neovim openssl btrfs-progs os-prober grub linux-headers

Network Configuration

选择 Use NetworkManager

Timezone

时区选 上海 （直接 / 搜 shanghai）

More

其他的根据自己的需要选择就好

都弄完后然后执行 Install 等待安装成功

Post Install

全部安装成功之后，会提醒你是否使用 chroot 进入系统中配置后续的内容，点击否

回到 U 盘系统中执行

# 挂载配置  
genfstab -U /mnt >> /mnt/etc/fstab  

之后通过 arch-chroot /mnt 进入系统

设置中文语言

nvim /etc/locale.gen  
# 取消 zh_CN.UTF-8 前的注释（en_US.UTF-8 已经取消了  
locale-gen  

Initramfs 配置

mkinitcpio - ArchWiki

# 在HOOKS中加入 btrfs  
nvim /etc/mkinitcpio.conf  
mkinitcpio -P  

Pacman 配置

nvim /etc/pacman.conf  
# 取消 Color 和 ParallelDownloads 前的注释  
# 加上一行 ILoveCandy  吃豆人彩蛋  
pacman -Syu  

设置用户 Shell

su <用户名>  
# 查看 shell 位置  
whereis zsh  
chsh -s /usr/bin/zsh  
# Ctrl+D 退出用户登陆  

引导

Boot Loader - Arch Wiki

双系统需要设置一下引导

# 检查  
sudo grub-install --recheck /dev/你的硬盘  
# grub-install --target=x86_64-efi --efi-directory=/boot  
sudo nvim /etc/default/grub  
# 将最后一行的注释去掉，启用 os-prober 检测双系统  
  
# 设置引导界面的分辨率  
# 在文件内搜索 GRUB_GFXMODE 变量，如果没有的话就新加一个  
# 将 `GRUB_GFXMODE` 的值设置为你希望的分辨率，例如 `GRUB_GFXMODE=1920x1080`  
  
# 如果之前为 Arch 创建了单独的 EFI，那么现在将 windows 的EFI分区挂载到任意目录 例如(/mnt)  
# 运行 sudo os-prober 看看能不能检测到windows  
sudo os-prober  
# 重新生成配置文件  
sudo grub-mkconfig -o /boot/grub/grub.cfg  

重启

# Ctrl+D 退出登陆  
umount -R /mnt #取消挂载  
reboot #重启  

配置完后重启电脑并拔掉 U 盘

之后就可以进入 arch 系统了，后面的继续参考 Arch Linux 系统配置篇

2023-06-18

声明

声明一下，下文中提到极化训练，不是在谈 极化训练方法，只是指其提出的 三区间划分 方式，三个区间所对应的不同的生理反应。

跟极化训练 80%-20% 的训练方式是没有关系的，在我看来每个区间的生理反应都是独特的、不可代替的。

究竟要在哪个区间花费多少精力取决去你想要练什么，你想得到什么

前言

国内关于训练的文章并不少，不管是极化训练还是金字塔训练大家都在说一个论点，多骑二区（有氧）。

那为什么要多骑二区呢？其他的运动向来都是想要提升什么就去练什么

• 所以如果我想要提 FTP，那我就应该在 FTP 附近去骑行，为什么要让我在二区骑行呢？
• 如此低的强度，它真的有用吗？
• 骑二区时我们身体发生了什么变化，背后的生理原理是什么？

在各篇文章里我都没有找到直观的答案，大家只是说这是在打基础，但是这个基础要打多久、打到什么程度呢？

我相信不少人，包括我自己都会有上述的疑惑

尤其是当你真正开始长达四个小时以上、枯燥的二期训练时，你难免会怀疑，它真的有用吗？

• 也许我应该试试甜区的训练，也许我应该加大点强度...

我们会在不同的训练计划中摇摆不定。

所以上述的答案是什么呢？当我在外网逛了一圈后，我找到了一些答案，希望这篇文章能为你揭开长有氧训练的面纱。

七层分区

在此之前，必须要讲清楚功率训练划分七个区间的不足之处，如果只从七区间的视角去看待二区（有氧），的确会让我们很难理解二区（有氧）训练的作用。

这张图片里有功率、最大心率、阈值心率、RPE 所对应的区间百分比

功率训练的七个区间，它使用了一个生理指标「乳酸阈值」（FTP）作为参照点划分百分比，其中 55% 到 75% 为有氧区间，也就是二区。

思维误区

这会让我们进入一个思维误区：

• 那就是只有在这个百分比内，我们才是在骑有氧。一旦超出这个区间，就不在是有氧。
• 而我们想要提升自己的有氧能力，就只能提高自己的 FTP，这样对应百分比的绝对值才会增加。

这里面最大的问题就在于我们以乳酸阈值这个生理指标去估算有氧能力，它真的合理吗？

55%~75% 就是一个绝对的有氧区间吗？

对于不同能力的运动员这个数值是否不会变化？

答案是否定的。

有氧能力强的人，他的有氧区间是会变大的，有可能 55% 到 85%，甚至 90% 都是有氧区间，那对他而言，55% 到 90% 都算是二区。

我们谈二区时，其实真正想表达的是其对应的有氧区间，是指有氧能力。当我们专项的对有氧能力进行训练时，它变得越来越强是很符合逻辑思维的。

只不过是有氧能力的增强会影响到 FTP，所以我们误以为是 FTP 增长带动了有氧能力的变强，这是颠倒了因果关系

极化分区

接下来我们要讲一下极化训练的区间划分，它的区间有三个，划分标准是血液内的「乳酸含量」，划分节点有两个：第一通气阈 和 第二通气阈。

有氧阈值

第一通气阈就是我们的有氧阈值

在这个区间以下骑行，我们的身体通过脂肪氧化进行供能，脂肪氧化并不会产生乳酸，所以血液中的乳酸含量是稳态的，并不会随着骑行时间的增加而增加。

在这个区间我们可以骑行很长的时间，即使是一个很瘦的人，他的脂肪供能也足以连续骑行两到三天。

在这个阶段，只需要水和氧气，理论上就可以无限制地骑行下去（当然这只是理论上的，实际即使我们躺着不动，身体依然会消耗能量）

乳酸阈值

第二通气阈，也就是乳酸阈值，熟悉的 FTP 强度。

在这个节点之下骑行，脂肪氧化来不及提供身体所需的能量，我们的身体转而使用糖酵解供能，也就是碳水氧化进行供能。

碳水氧化会使身体产生乳酸，在这个区间骑行，血液内的乳酸含量会随着骑行时间的增长而增长，但仍然是线性的。

一个普通人的碳水化合物能量，一般可以支持一到一个半小时的供能，如果没有及时补充能量就会出现“撞墙”的情况

超乳酸阈值

高于乳酸阈值的区间就是我们的无氧区间（其实并不准确，依然是有氧气功能的）

在这个区间骑行身体会非线性的大量的产生乳酸，所以我们无法长时间在此区间骑行。

这与七区间的五区及之上是一样的，不再多说。

优点

我们可以看到相比七区间使用一个生理指标 乳酸阈值 进行区间划分，极化训练的划分使用了两个生理指标 有氧阈值 和 乳酸阈值。

并且通过血液内乳酸含量来决定有氧区间的划分，相比七区间使用固定用百分比进行有氧划分，是更加合理和符合科学依据的。

总结

回到训练黄金定律：想提高什么就去练什么，训练应该为目标去服务，想清楚你的目标是什么

• 如果想要提高乳酸阈值，也就是 FTP，那就应该在乳酸阈值的强度区间去进行骑行，考虑到疲劳和超量恢复，一到一个半小时的甜区的确是不错的选择
• 如果想提升有氧阈值，就应该在有氧阈值附近进行骑行，有氧训练时长建议 2-5 小时（越长越好）

值得一提的是，乳酸阈值和有氧阈值并不是独立的，它们是相互影响的，所以我们看到新手即使只骑二区 FTP 依然会快速增长；而很少骑二区的高 FTP 车手有氧能力也不会很差。

但当我们的 FTP 达到瓶颈时（增长缓慢），不同能力的车手差距就会显现出来

试想一下两个同样是 350 瓦的运动员

• 其中一个的有氧阈值就是功率 75% 的强度
• 而另一个有氧阈值则是 90%

当他们同样以 90% 功率的强度骑行时

• 前者是在使用糖酵解供能，这只能让他坚持一到一个半小时后
• 而后者则是在有氧骑行，他可以骑行四六甚至八个小时

当骑行时间较短的时候，我们并不能很好地看出两者的差距，但当骑行时间变长两者的差距显而易见

如何测试有氧阈值？

讲完原理我们来讲一下怎么确定二区的范围，显然我们不能方便的去测量血液乳酸含量（倒是有相应的仪器售卖）

波加查教练的二区视频中提到过这个问题，他建议使用 心率 + RPE

方法

我们可以所有手段结合一下，起始依然用功率二区去练，比如 65%-68%。然后观察心率和本体感受，你应该可以轻松的说上几句话（谈话测试）：

最后我们查看有氧解耦率，如果在 5%-10% 说明这个区间正合适你，如果超过了 10% 说明强度太高了。如果只有 0%-5% 说明强度需要增加了，你可以测 FTP 或提高百分比。

最后总结一下，如果你只是一个普通爱好者，如果你没有太多的时间，那就去练甜区，提高 FTP。

如果你有时间，那就多骑有氧，提高 FTP 的同时也在提高你的骑行下限，让你能以更低的心率骑出更高的功率

以上，是下午四小时二区骑行时写的，共勉

补充

甜区指功率的 88% - 93%

不用太过纠结某个指标具体的数字，自身的感受（RPE）也是训练中很重要的一部分。不管是心率、功率、解耦率还是 RPE 都是在给我们提供一个观察自身状态的指标而已，结合越多的指标去观察，它的参考意义也就越大。

对 11 名挪威 XC 滑雪者奥运冠军一年训练的研究（下面的区间都是极化区间）

他们大部分训练时间都是在“1 区”低强度下度过的，其中乳酸水平低于 1.1 毫摩尔/升，然而，这项研究中的运动员已经拥有高度发达的 LT1（有氧阈值）。

平均而言，运动员的 Zone 1 的顶端位于最大心率的 73%。对于大多数普通人来说，73% 的最大心率将稳固地处于 2 区，甚至可能进入 3 区，乳酸水平通常约为 2-3 毫摩尔/升。

更重要值得考虑的是，虽然 XC 运动员测得的乳酸水平较低，但乳酸生成率和肌纤维募集程度可能相对较高，这些运动员能够在高乳酸生成率的情况下维持低乳酸水平的原因是因为他们接受过高度有氧训练，因此非常擅长清除产生的乳酸。

Inigo San Milan 在他关于有氧训练和执教 Tadej Pogačar 的经验讨论中提出的一个观点：训练有素的自行车运动员的乳酸通量非常高，在大部分训练时间里，这些运动员需要根据乳酸水平以低于“正常”的强度骑行，以避免积累太多很多代谢压力。

在实践中，这意味着训练有素的自行车手可能会以大约 50-65% 的 FTP 为目标进行长距离耐力骑行。

相比之下，相对新手的自行车手可能更适合 70-80% 的 FTP，因为他们的绝对功率输出较低，而且他们可以忍受以较高百分比的 FTP 骑行，同时代谢和肌肉紧张较少。

由于女性相对于男性产生的绝对功率也较低，因此有一种理论认为，出于同样的原因，她们也应该略微增加强度。

同样，这是我们在指导各种能力水平的运动员时注意到的事情；Zone 2 骑行的“传统”定义需要根据个人情况进行迭代

国家冠军级选手低强度骑行的原因可能是新陈代谢压力太高，这是由于持续的「绝对高功率/速度」（FTP 450w，70% 依然有 315w 的功率输出，速度在 40+ 以上），所以即使在 Zone 1 训练，乳酸生成率和肌纤维募集程度依然较高，而这些运动员能够在高乳酸生成率的情况下维持低乳酸水平的原因是因为他们接受过高度有氧训练，因此非常擅长清除乳酸

参考

• Articles — High North Performance

2024-04-23

书接上回 Arch Linux 系统安装篇

进入系统之后需要对新系统进行设置

必要系统设置

要先保证电脑的 wifi/键盘/鼠标 等可以正常使用，不然一切都是空谈

联网

NetworkManager - ArchWiki

因为之前选的是 NetworkManager 管理网络，所以可以以下步骤任选其一

• 命令行操作：nmcli device wifi connect <网络名> password <密码>
• TUI 操作：nmtui
• 图形界面操作：nm-connection-editor

还可以安装 networkmanager-dmenu: Control NetworkManager via dmenu ，可以通过 dmenu 或 rofi 管理 NetworkManager

蓝牙

Bluetooth - ArchWiki

有几种方式

• bluetoothctl
  • 最基础稳定的命令行管理，但是 UI 交互什么的肯定就很不友好了（相对其他工具
• bluetuith: A TUI bluetooth manager for Linux.
  • 一个 TUI 工具用来管理 bluetoothctl，交互就舒服多了
• bluetui: 🛜 TUI for managing bluetooth devices
• Overskride
  • GTK4 中简单但功能强大的蓝牙客户端（GUI，很漂亮）

bluetoothctl

这里以最基础的 bluetoothctl 为例

安装

pacman -Syu bluez bluez-utils  
systemctl enable bluetooth.service  
systemctl start bluetooth.service  

使用

bluetoothctl  
default-agent  
power on  
# 扫描  
scan on  
# 设备开启蓝牙，会看到 [NEW] Device MAC_address Name  
# 找到自己的设备  
# 配对  
pair MAC_address  

系统升级和备份

这位同学你也不想辛辛苦苦装好的系统又被玩崩了吧～

建议安装 informant: An Arch Linux News reader and pacman hook

这是一个 pacman hook，可以保证你在升级系统前必须先阅读 Arch Linux 的新闻，否则就会中断升级动作

升级之后 检查孤立包和丢弃的包，命令在下面 [ > [Pacman](https <//wiki.archlinux.org/title/Pacman>) 速览](Arch%2520Linux%2520%E7%B3%BB%E7%BB%9F%E9%85%8D%E7%BD%AE%E7%AF%87.md##%5BPacman%5D(https%2520%3C//wiki.archlinux.org/title/Pacman%3E)%2520%E9%80%9F%E8%A7%88)

Timeshift

sudo pacman -S timeshift  
# 参考 https://github.com/linuxmint/timeshift/issues/147  
# 它在 Wayland 中运行正常，只是它当前的启动方式（以 root 身份）正在丢失 Wayland 环境  
# 并且会回退到 x11。通过运行 sudo -E ，它可以在启动时保留 OP 的环境（因此它作为 wayland 客户端运行）  
sudo -E timeshift-launcher  

启动之后选择 Wizard 根据自己的需要配置，我选择每天进行一次快照，保留 15 天的记录

与计划在一天中的固定时间进行备份的类似工具不同，Timeshift 设计为每小时运行一次，并且仅在快照到期时才拍摄快照。

这更适合每天打开笔记本电脑和台式机几个小时的台式机用户。

为此类用户安排固定时间的快照将导致备份丢失，因为在安排快照运行时系统可能尚未运行。

通过每小时运行一次并在到期时创建快照，Timeshift 可确保不会错过备份。

其他系统设置

Pacman 速览

pacman

# 安装  
pacman -S package_name  
# 删除，保留依赖项  
pacman -R package_name  
# 删除，不保留依赖项（推荐）  
pacman -Rs package_name  
  
# 升级包/系统  
pacman -Syu  
  
# 查询  
# queries the local package database with the `-Q` flags  
pacman -Qs package_name  
# the sync database with the `-S` flag  
pacman -Ss package_name  
# files database with the `-F` flag  
pacman -F string  
  
# 列出所有显示安装的包  
pacman -Qqe  
  
# query package information  
pacman -Si package_name  
pacman -Qi package_name  
  
# 列出不再需要作为依赖项（孤立项）的所有包  
pacman -Qdt  
  
# 列出所有显式安装且不需要作为依赖项的包：  
pacman -Qet  
  

系统升级后的清理动作

# 列出不再需要作为依赖项（孤立项）的所有包  
pacman -Qdt  
# 对于递归删除孤立包及其配置文件  
pacman -Qdtq | pacman -Rns -  
# 如果某些包不希望被当作孤立包，可以改为显示安装  
pacman -D --asexplicit package  
# 找到所有损坏的软链接  
find / -xtype l -print  

清理包缓存

pacman - ArchWiki

sudo systemctl enable paccache.timer  
sudo systemctl start paccache.timer  

yay

# 安装 yay，ARU 助手 或者可以选择 paru  
# 但是 hyprland 中推荐使用 yay  
git clone https://aur.archlinux.org/yay.git  
cd yay  
makepkg -si  
# 首次安装后配置  
yay -Y --gendb  
yay -Syu --devel  
yay -Y --devel --save  
  
yay -S google-chrome  
yay -S rofi  

Hyprland 配置

Arch Linux 系统安装篇 里已经选了 hyprland，所以这里基本的配置应该已经完成了

我们直接进行配置的安装即可，可以在 hyprland · GitHub Topics · GitHub 中挑选自己喜欢的配置，我选择的方案和配置参考 dotfiles#hyprland

基本上安装完这个之后，系统就已经完全可用了

按键映射

底层映射

我习惯把 ctrl 放在 alt （command）的位置，所以要改一下按键

对于这种无脑重映射，最好是从底层修改，以不需要用运行程序的方法以提高性能 Map scancodes to keycodes - ArchWiki

步骤如下

查找键盘设备

先安装 pacman -S evtest 用来查看按键的 scancode，安装好后，执行 sudo evtest

先选择自己的键盘设备 /dev/input/event$，如果不确定就一个一个试，试对了按键后屏幕会有输出

输出内容格式如下：

Event: time 1628668903.193667, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70039  
Event: time 1628668903.193667, type 1 (EV_KEY), code 58 (KEY_CAPSLOCK), value 0  

其中 KEY_CAPSLOCK 表示我按下的是 capslock 键，MSC_SCAN 后面的 value 70039 是 scancode ，code 58 是 keycode

有了按键信息之后还需要设备信息做匹配，上面我们已经找到了自己的设备号了，通过以下命令查看设备

把 event$ 中的 $ 换成具体的设备号

cat /sys/class/input/event$/device/modalias  

在 /etc/udev/hwdb.d/ 中创建一个 90-remap-keyboard.hwdb 的文件

evdev:input:b0003v05ACp0259*  
  # leftalt 和 leftctrl 交换  
  KEYBOARD_KEY_700e2=leftctrl  
  KEYBOARD_KEY_700e0=leftalt  
  # capslock 映射到 leftmeta  
  KEYBOARD_KEY_70039=leftmeta  

保存退出，更新 hwdb 数据库：

systemd-hwdb update  

激活配置

udevadm trigger  

程序映射

我喜欢把 ctrl 单击映射为 esc 按键，而与其他键组合时仍然是 ctrl 键，参考 Vim ESC 键的解决方案，这种功能就必须使用程序来实现了

最终选用了 kanata，因为我对 rust 比较熟。也可以看看 kmonad

kanata

• GitHub -kanata
• Kanata simulator

具体配置和使用参考 dotfiles

evremap

参考 Input remap utilities - ArchWiki

这种方案的问题是，一旦换了键盘或者连接方式，就要重新修改配置文件

安装 evremap

yay -S evremap  

配置 evremap

copy https://github.com/wez/evremap/blob/master/pixelbookgo.toml 内容至自己本地，命名为 evremap.toml，记住存放的路径，后面要用

修改 evremap.toml ，参考 GitHub - evremap 进行个人配置，主要是 device_name 要配置对，不然会报错无法启动

配置好之后先测试一下

sudo evremap remap evremap.toml  

如果没有报错就可以正常使用了，可以去其他地方试一下按键有没有生效

开机自启动

udev

参考

• udev - ArchWiki
• Issue #35 · wez/evremap · GitHub
• Create UDEV-Rule for Bluetooth-Headset / Newbie Corner / Arch Linux Forums

这种方式可以在设备（蓝牙）触发相应事件时（自动连接后）执行命令

查看设备信息，$device_name 就是上面 查找键盘设备 中的路径 eg: /dev/input/event18

udevadm info --attribute-walk --name=$device_name  

然后找到可以唯一标识自己设备的一些信息，比如 id/product、id/vendor、phys 之类的，用于规则匹配使用

编写规则

sudo nvim /etc/udev/rules.d/90-evremap.rules  

写入规则

ACTION=="add", SUBSYSTEM=="input", ATTRS{id/product}=="0220", ATTRS{is/vendor}=="05ac", ATTRS{phys}=="64:49:7d:a2:7d:34", RUN+="/usr/bin/evremap remap /evremap.toml"  

根据自己的设备情况把匹配条件写好

然后重启测试

systemd

也是 evremap Readme 中推荐的方式，但是！

所以这种方法对于蓝牙键盘来说完全不能用，因为系统没启动前蓝牙肯定没有连上啊，但如果你是有线键盘，这种还是比较省事

使用如下命令创建 systemd service

sudo nvim /etc/systemd/system/evremap.service  

把 https://github.com/wez/evremap/blob/master/evremap.service 中的内容写入，并把 evremap.toml 的绝对路径替换成你自己的本地路径

然后使用 systemctl 控制开机自启动

sudo systemctl daemon-reload  
sudo systemctl enable evremap.service  
sudo systemctl start evremap.service  

Dotfiles

TUI、shell、输入法、nvim、terminal 等安装和配置，可以参考 GitHub - lei4519/dotfiles: vim、linux、mac 配置，这里不再赘述

有用的软件

我平时喜欢用终端，所以比较钟意 TUI

awesome-tuis
awesome-shell
awesome-zsh-plugins
awesome-cli-apps

• sysz: An fzf terminal UI for systemctl
• xdg-ninja: A shell script which checks your $HOME for unwanted files and directories.
• sahib/rmlint: Extremely fast tool to remove duplicates and other lint from your filesystem
• yadm: Yet Another Dotfiles Manager

固态硬盘清理

Solid state drive - ArchWiki

sudo systemctl enable fstrim.timer  
sudo systemctl start fstrim.timer  

睡眠和休眠

完善的 dots 配置应该会自动配置好睡眠和休眠

Power management/Suspend and hibernate - ArchWiki

中文字体设置

参考：

• Localization/Chinese - ArchWiki
• Font configuration/Chinese - ArchWiki

# 安装中文字体  
sudo pacman -S ttf-roboto noto-fonts noto-fonts-cjk adobe-source-han-sans-cn-fonts adobe-source-han-serif-cn-fonts ttf-dejavu  
# 配置字体  
nvim ~/.config/fontconfig/fonts.conf  

复制以下内容，然后重启电脑即可

<?xml version="1.0"?>  
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">  
<fontconfig>  
  <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">  
    <its:translateRule  
      translate="no"  
      selector="/fontconfig/*[not(self::description)]"  
    />  
  </its:rules>  
  
  <description>Android Font Config</description>  
  
  <!-- Font directory list -->  
  
  <dir>/usr/share/fonts</dir>  
  <dir>/usr/local/share/fonts</dir>  
  <dir prefix="xdg">fonts</dir>  
  <!-- the following element will be removed in the future -->  
  <dir>~/.fonts</dir>  
  
  <!-- Disable embedded bitmap fonts -->  
  <match target="font">  
    <edit name="embeddedbitmap" mode="assign">  
      <bool>false</bool>  
    </edit>  
  </match>  
  
  <!-- English uses Roboto and Noto Serif by default, terminals use DejaVu Sans Mono. -->  
  <match>  
    <test qual="any" name="family">  
      <string>serif</string>  
    </test>  
    <edit name="family" mode="prepend" binding="strong">  
      <string>Noto Serif</string>  
    </edit>  
  </match>  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>sans-serif</string>  
    </test>  
    <edit name="family" mode="prepend" binding="strong">  
      <string>Roboto</string>  
    </edit>  
  </match>  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>monospace</string>  
    </test>  
    <edit name="family" mode="prepend" binding="strong">  
      <string>DejaVu Sans Mono</string>  
    </edit>  
  </match>  
  
  <!-- Chinese uses Source Han Sans and Source Han Serif by default, not Noto Sans CJK SC, since it will show Japanese Kanji in some cases. -->  
  <match>  
    <test name="lang" compare="contains">  
      <string>zh</string>  
    </test>  
    <test name="family">  
      <string>serif</string>  
    </test>  
    <edit name="family" mode="prepend">  
      <string>Source Han Serif CN</string>  
    </edit>  
  </match>  
  <match>  
    <test name="lang" compare="contains">  
      <string>zh</string>  
    </test>  
    <test name="family">  
      <string>sans-serif</string>  
    </test>  
    <edit name="family" mode="prepend">  
      <string>Source Han Sans CN</string>  
    </edit>  
  </match>  
  <match>  
    <test name="lang" compare="contains">  
      <string>zh</string>  
    </test>  
    <test name="family">  
      <string>monospace</string>  
    </test>  
    <edit name="family" mode="prepend">  
      <string>Noto Sans Mono CJK SC</string>  
    </edit>  
  </match>  
  
  <!-- Windows & Linux Chinese fonts. -->  
  <!-- Map all the common fonts onto Source Han Sans/Serif, so that they will be used when Source Han Sans/Serif are not installed. This solves a situation where some programs asked for a font, and under the non-existance of the font, it will not use the fallback font, which caused abnormal display of Chinese characters. -->  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>WenQuanYi Zen Hei</string>  
    </test>  
    <edit name="family" mode="assign" binding="same">  
      <string>Source Han Sans CN</string>  
    </edit>  
  </match>  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>WenQuanYi Micro Hei</string>  
    </test>  
    <edit name="family" mode="assign" binding="same">  
      <string>Source Han Sans CN</string>  
    </edit>  
  </match>  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>WenQuanYi Micro Hei Light</string>  
    </test>  
    <edit name="family" mode="assign" binding="same">  
      <string>Source Han Sans CN</string>  
    </edit>  
  </match>  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>Microsoft YaHei</string>  
    </test>  
    <edit name="family" mode="assign" binding="same">  
      <string>Source Han Sans CN</string>  
    </edit>  
  </match>  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>SimHei</string>  
    </test>  
    <edit name="family" mode="assign" binding="same">  
      <string>Source Han Sans CN</string>  
    </edit>  
  </match>  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>SimSun</string>  
    </test>  
    <edit name="family" mode="assign" binding="same">  
      <string>Source Han Serif CN</string>  
    </edit>  
  </match>  
  <match target="pattern">  
    <test qual="any" name="family">  
      <string>SimSun-18030</string>  
    </test>  
    <edit name="family" mode="assign" binding="same">  
      <string>Source Han Serif CN</string>  
    </edit>  
  </match>  
  
  <!-- Load local system customization file -->  
  <include ignore_missing="yes">conf.d</include>  
  
  <!-- Font cache directory list -->  
  
  <cachedir>/var/cache/fontconfig</cachedir>  
  <cachedir prefix="xdg">fontconfig</cachedir>  
  <!-- the following element will be removed in the future -->  
  <cachedir>~/.fontconfig</cachedir>  
  
  <config>  
    <!-- Rescan configurations every 30 seconds when FcFontSetList is called -->  
    <rescan>  
      <int>30</int>  
    </rescan>  
  </config>  
</fontconfig>  

Ref

• Btrfs：认识、从 Ext4 迁移与快照方案
• config/INSTALL.txt at main · HeaoYe/config · GitHub
• pacman 常用命令-昨夜星辰

2020-12-18

实现方案分类

• 编译型：Taro 1、2
  • 通过 babel 对代码进行转换，编译结束后完全是小程序的代码。
• 半编译、半运行时：uni-app、mpvue
  • 模板层编译转换、运行时做语法兼容
• 运行时：Remax、Taro next、Kbone
  • 纯运行时，模板层只有一个固定的模板 wxml，通过运行时生成的 vnode 来渲染视图。

编译型

Taro 1、2 可以让我们使用类 react 语法开发小程序，之所以说是类 react 语法，是因为这些“react”代码在编译完成之后，会被全部编程小程序的原生语法，里面是没有 react 参与的。

这也导致在 Taro 1、2 中写 JSX 时，需要遵照官方文档中的规范，否则运行时就会出现问题。

并且由于 JSX 的灵活性，将 JSX 转换成小程序模板时，是一件工作量非常大的事情。

Taro 就是用穷举法硬生生的将 JSX 全部转换成了模板。但即使这样，依然会有问题，比如无法实时的享受 react 的新语法、新特性，大多数 react 生态都无法直接使用。即使用了穷举法，转换过程中还是会出现各种问题，Taro 的大多数 commit 提交都是有关于模板转换的。

半编译、半运行时

小程序的设计很明显是借鉴了 vue，不管是模板的写法还是逻辑层的写法。所以相比起 JSX 转换的困难，vue 代码在转换时就轻松很多了。

所以像 mpvue、uni-app 就是利用这一特性，将 vue 的模板转换成了小程序的 wxml，这是其编译型的特性。

在编译时，并没有将逻辑层的代码转换成小程序原生的语法，而是完全的保留了 vue 的能力，这是其运行时的特性。

由于完全保留了 vue 的能力，也使得上述纯编译型框架的痛点得以解决。我们可以享受最新的语法特性，不用担心由于写法问题导致转换错误，可以方便的复用 vue 生态。

那现在留下的疑问就是：vue 是浏览器中的运行时框架，它是怎么去操作改变小程序视图的呢？

运行时原理

首先，vue 在浏览器中的运行流程如下：

new Vue() -> render() -> patch() -> 浏览器视图  

1. 初始化 vue，监听响应式等工作。
2. 调用 render 函数（手写或者通过 vue-loader 编译 template 生成），拿到虚拟 dom（vnode）
3. patch 函数用来做 diff 工作，然后将需要显示在视图中的 vnode，使用原生的 DOM API 插入到 DOM 树中。

观察上述流程，发现只在第三步中涉及到了浏览器相关的东西。所以 1、2 步是完全可以在小程序中运行的。

所以只需要对第三步做适配，就可以将 vue 运行在小程序中了。

那如何做适配呢？当 patch 函数 diff 出需要更新渲染的 vnode，就会去调用更新视图的 API，在浏览器中那是 DOM 系列的 API。而在小程序中，其只为我们提供了 setData 这个用来更改视图的方法，所以很明显，我们只需要在 diff 结束后，调用 setData 来更新视图就可以了。

这就又引出了另一个问题，patch 出来的是 vnode，而我们在模板中用的是 data 中的数据，所以肯定不能直接将 vnode 传到 setData 中，应该给 setData 传入 data 中改变的数据才对，那我们怎么才能拿到 data 中改变的数据呢？

说起改变的数据，可能第一反应是 diff，我们将老的数据保存一份，当数据改变之后。对新旧数据进行 diff，然后拿到差异数据，传入 setData 更新视图。

这样当然是可行的，我们只需要将 patch 中对比 vnode 的代码干掉，换成 diff 新旧数据的代码，这样 diff 结束后将结果传入 setData 即可。

但是这么做会有一个性能问题，如果 data 中有很多的数据，而在视图中我们只用到了一个简单的变量，这时对 data 数据进行全量 diff 就是一个很浪费时间的工作了。

所以我们可以用另一个方案来更高效的实现，让我们回到上一个问题，patch 出来的是 vnode，而传入 setData 的是 data 数据。那我们可不可以通过 vnode 来获取到 data 中改变的数据呢？

答案是可以的，因为我们会编译模板层的代码，所以在编译时，我们完全可以将相关的信息记录下来。

不废话，上代码：

<!-- vue template -->  
<view>  
  <view>{{ text }}</view>  
  <view v-for="item in list">{{ item }}</view>  
</view>  
  
<!-- 编译后的wxml -->  
<view>  
  <view>{{ text }}</view>  
  <view wx:for="list" wx:for-item="item" wx:for-index="i">{{ list[i] }}</view>  
</view>  
  
<!-- template编译的render函数 -->  
render(h) { return h('view', null, [ h('view', {path: 'text'}, text),  
list.map((_, i) => { return h('view', {path: 'list[i]'}, list[i]) }) ]) }  

通过观察上面的三段代码，我们可以看到，在编译时，我们是可以感知到模板中使用的响应式数据，相对于 data 的访问路径。所以我们就可以将这些路径记录在 vnode 中，这样通过 patch 之后的 vnode，我们就可以获取到对应数据的路径了。

并且通过这种方式，我们也可以避免给视图层传递无用的数据，每次 diff 之后，只会将视图层中用的数据传入 setData。

运行时

上面的半编译、半运行时框架只能用于 vue，对 react 而言，其灵活的语法特性和底层架构注定与之无缘。难道说 react 就不能再小程序中运行了吗？

我们来回顾一下上一节中提到的

vue 的 patch 函数 diff 之后的结果是 vnode，而模板中用的是 data 数据，所以我们不能将 vnode 传给 setData，而应该找到对应的数据传给 setData。

再来回顾一下第一节中所说的

JSX 的灵活性导致转换成 wxml 时的工作量巨大，并且要严格遵守规范，否则就会出问题。

放飞你的大脑，我们来刚一下

vue 的 patch 函数 diff 之后的结果是 vnode，而模板中用的是 data 数据，所以我们不能将 vnode 传给 setData

那就是说，如果模板中没有使用 data 数据，那我就可以将 vnode 传入 setData 喽。

JSX 的灵活性导致转换成 wxml 时的工作量巨大，并且要严格遵守规范，否则就会出问题

转换起来那么难，那我干脆不转了。JSX 最后生成的是什么？vnode 啊，我直接把 vnode 传给 setData 喽。

所以现在的问题变成了，小程序模板可以根据 vnode 对象来渲染视图吗？

答案是可以，方案就是小程序的 template 语法可以动态递归的调用渲染。

<template name="tpl_view">  
  <view class="{{ className }}">  
    <block wx:for="{{children}}">  
      <template is="tpl_view" data="{{ item }}"></template>  
    </block>  
  </view>  
</template>  

以上为伪代码，只为方便理解，实际上微信小程序不允许模板调用自身。

上面定义了一个模板，我们只需要构建如下的数据结构，将其传入模板内，这个模板就可以根据数据生成对应结构的 view 元素

const data = {  
  className: '1',  
  children: [  
    {  
      className: '1-1'  
      children: [  
        {  
          className: '1-1-1',  
          children: []  
        }  
      ]  
    }  
  ]  
}  

也就是说，如果我们将小程序的所有基础组件，全部都使用模板的形式定义一遍。那我们就可以传入一个描述对象（vnode，注意这个 vnode 不是 vue 或者 react 的），让 wxml 根据这个对象生成视图。

这也是目前 Taro next、Remax 在视图层的实现方式，如果打开 Taro next 编写的小程序代码就会发现里面有一个 base.wxml，其中就是实现了所有的小程序基础组件的模板。

到此为止，视图层我们已经解决了，但是这个解决方案好像和 react 没有什么关系，理论了只要能产生 wxml 渲染模板的 vnode，任何框架都可以这样实现。

事实上也是，用这种方案，可以很轻松的同时支持 Vue 和 React 这两种框架。Taro next 就是如此。

接下来就说一说 react 的事

实现原理

react 的源码相比 vue 更加复杂，但整体的**并无太多差距，可以简单总结为

React.render() -> reconciler() -> renderer() -> 浏览器视图  

1. React.render 做初始化工作
2. reconciler 做 diff 工作，找出需要更新的 vnode
3. renderer 负责调用浏览器 API 将 vnode 渲染

看过 vue 的实现之后，我们不难猜到，这里要动刀的肯定是 renderer 这一步了。

那如何做呢？别忘了我们的核心点是什么：构建出 wxml 用来遍历渲染的 vnode。

我们重新翻译一下上面的第三步：

renderer 负责将需要更新的虚拟 vnode，通过 DOM API 转换成真实的 dom。

然后想想我们怎么实现呢？

renderer 负责将需要更新的虚拟 vnode，通过【自定义 API】转换成 wxml 用来遍历渲染的 vnode。

是的，就是这么“简单”，我们只需要将原本操作生成 DOM 的那套 API，更改成操作生成 vnode 的 API 就可以啦~~~ 完结！撒花 ❀❀❀❀❀❀❀❀❀❀❀

开玩笑，当然没那么“简单”，但是**就是这样，不管是 vue 还是 react，其实我们需要做的就是将更改 DOM 的 API，换成更改 vnode 的 API。

举个例子：

// DOM API  
function createElement(type) {  
  return document.createElement(type)  
}  
  
// vnode API  
function createElement(type) {  
  return {  
    template_name: "tpl_" + type,  
  }  
}  

还有一个好消息就是，不管是 React 还是 Vue，当需要操作 DOM 时，都不会直接在代码中调用 DOM API，而是将操作统一封装到了工具函数中，这样我们就可以很方便的对这些 API 进行改写了。

更具体的实现，这里就不在赘述，可以看下面的参考链接去详细了解。

参考资料

• 深入浅出主流的几款小程序跨端框架
• 自己写个 React 渲染器: 以 Remax 为例(用 React 写小程序)

2024-03-25

咬文嚼字

REF

我的大前端世界观 - 黄玄 Hux - 哔哩哔哩

TL;DR

如今的前端已经不局限在语言（JS）、环境（Browser）中了，我们几乎可以做任何与用户进行交互的界面或工具

我们想要表达：所有服务于设计和开发用户可以直接看到和交互的部分这件事情

其实「前端」这个词本身的含义已经足够好了，但是因为时代的原因被绑上了固有的标签

所以不得不用一些新词/概念来区别时代的变化

TUI ( Terminal UI )

开始之前先说一下 TUI，就是运行在终端里的用户界面，不知道有多少人了解/使用过这个

简单列一些比较常用的：

lazygit	fzf	ranger/ yazi	bottom	wtf

除此之外还有诸如音乐播放器、邮箱、游戏（口袋妖怪）等等等，感兴趣可以访问 awesome-tuis

开发 TUI 的技术栈各种各样：Go / Python / Rust...

当然也少不了 JS：React TUI - Ink：

• React - 扫雷: npx mnswpr
• React - Git

能用 JS 写的终将会用 JS 写
能用 Rust 写的终将会用 Rust 写

什么是前端？

提到前端很容易会联想到这些标签：HTML + CSS + JS / Browser / Web / React / Vue

但现在 (2024) 的前端已经完全不限于上述的标签里了

• Rust 工具链、WebAssembly
• BFF
• TUI
• RN、Flutter
• 鸿蒙
• ......

-- 我的大前端世界观 - 黄玄 Hux

国内把这种拥有更全面能力的前端称为「大前端」，但我觉得这个词不好的地方是：会让人自以为了解其含义

并且由于里面存在「前端」的字眼，所以大概率还是会局限在固有标签里

把 终端的异步状态管理 这篇文章的「终端」换为「大前端」，我觉得就不能很好的表达其意思了

终端？

终端（Terminal）固有印象：黑窗口/命令行窗口

-- Terminal

此终端（end device）非彼终端（Terminal）

鸿蒙 HarmonyOS 系统是面向万物互联的全场景分布式操作系统，支持手机、平板、智能穿戴、智慧屏等多种终端设备运行

更接近我们要表达的意思：人机交互入口、链路的终点，而不是局限在 Web/Native/Terminal，又或是手机、电脑、电视等

而且终端这个词的“好处”是人们的第一反应是疑惑与好奇：这跟前端有什么关系？这会驱使其进一步了解，而不是自以为了解

Omni-FrontEnd

黄玄视频中提到的词

Front-end

其实我觉得前端（Front-end）这个词本身是挺好的：设计和开发用户可以直接看到和交互的部分

单看这一句完全可以把 end device 相关的都算到前端里，但由于时代的固有印象，不得不用一些新词/概念来进行区分

2024-03-28

前言

最近刷到了一个讲跑步训练的视频，发现里面讲的训练方法和骑行的侧重点并不相同，明明两者都是有氧运动，不免让人产生疑惑 🤔

但细思之下又发现其底层逻辑和之前讲的 极化训练，为什么要多骑二区（有氧）？ 不谋而合

文中跑步特指长跑、马拉松，骑车特指公路车

差异点

以三区模型为例

Frontiers | The Polarization-Index: A Simple Calculation to Distinguish Polarized From Non-polarized Training Intensity Distributions

从上到下依次为

• 极化型
• 金字塔型
• 阈值型
• 高强度型

骑行 🚴

骑行训练中目前流行的是极化训练，基本**是把训练的总时间 80% 分给 Zone1 训练，20% 分给 Zone3 的训练，在临近赛期的时候才会去 Zone2 训练

跑步 🏃

而跑步训练中，则更多是阈值或金字塔型，会发现相比之下 Zone2 训练时间变长了

Why? 🧐

目标

训练是有目的性的，是为目标所服务的。从这个点出发，可以看一下跑步比赛和自行车比赛的差别

跑步我们都知道马拉松就是 42 公里，顶尖的运动员的时间大概是在两小时到两个半小时之间

那骑车呢？我们需要去对比单日赛，五大古典赛的里程数是 240KM 到 300KM 之间，完赛时间五小时到六小时之间

战术

然后可以再看一下比赛过程中的差异

跑步的话，过程中并没有太多战术性的东西，大家的对手只是自己，所以都在顶着自己的阈值去完成比赛，尽可能多的提高自己的成绩

而公路车就复杂的多了，里面充斥着各种心机战术

由于速度和空气动力的原因，车手跟车骑行时会极大的节省体力，尤其当车手处于大集团中，他们的功率是相当低的

所以比赛的基本原则是

1. 以尽可能低的消耗跟住集团（跟风）
2. 保留体力以在关键时刻发起进攻甩掉对手

供能

同时也可以从供能系统去看，由于骑车完赛时间过长，我们无法全程依靠糖原供能去进行比赛

非常粗略/不严谨的说，糖原大概会在 90 分钟左右消耗完毕

所以不得不想办法提高有氧供能的能力，让自己二区的速度越来越快

在可以跟住主集团的同时保留糖原，以在关键时刻发起进攻决定胜负

Conclusion

所以结论也不言自明，对跑步来说，更像是公路车的计时赛，我们没有太多的对手，更多是对自己的比拼，所以要全力完成比赛（全程阈值输出），所以要尽可能多的提高自己的阈值的能力

而公路车整个赛程中大多数都是以有氧的强度进行的，只在关键时刻才会发起进攻以阈值以上的强度输出，所以会尽量提高自己的有氧和无氧能力

2021-01-05

源起

公司要开发一个 Chrome 扩展，用来模拟人为操作，爬取目标网站的数据。

通过这篇文章来记录和分享一下开发过程中的经验与心得。

此扩展开发时，Chrome 扩展 v3 版本的文档已经发布。但是只有最新的 Chrome 才支持，考虑兼容性问题，扩展使用的仍然是 v2 版本，本篇文章中的相关介绍，也都是以 v2 版本为主。

虽然标题是使用 Umi 开发 Chrome 扩展，但是本篇 95% 都是在讲扩展本身，最后会简单说一下开发扩展时 Umi 的配置。

Chrome 扩展

官方介绍

扩展程序是可以定制浏览体验的小型软件程序。它使用户可以根据个人需要或偏好来定制 Chrome 功能和行为。它们是基于 Web 技术（例如 HTML，JavaScript 和 CSS）构建的。
扩展由相互联系的各种组件组成，组件可以包括 后台脚本，内容脚本，选项页，UI 元素 和各种逻辑文件。

常用的扩展组件和功能概述

本节介绍一下常用的扩展组件和功能，带你了解扩展在浏览器中能做什么事情。

browserAction、pageAction

浏览器右上角（工具栏）展示的小图标，每一个图标就代表一个扩展程序。

action 有三种操作方式：

• toopli：鼠标 hover 后的文字提示
• badge：徽标
• popup：点击后弹窗

其中弹出窗口是 action 的主要交互区域。

Commands（键盘快捷键）

顾名思义，可以增加和修改浏览器的键盘快捷键操作。

说起这个功能，就不得不提一个非常热门的扩展：Vimium

这个扩展可以让你用 vim 的快捷键操作浏览器，让你完全脱离鼠标操作。

contextMenu(右键菜单)

向右键菜单中加入自定义项。

Override

使用 override 可以将 Chrome 默认的一些特定页面替换掉，改为使用扩展提供的页面。

可以替代的页面如下：

• Chrome://history 历史记录页
• Chrome://newtab 新标签页
• Chrome://bookmarks 书签页

一个扩展只能替代一个页面，不能替代无痕模式窗口的新标签页。

新标签页扩展：掘金、Infinity

omnibox（多功能框）

在地址栏中注册关键字，用户输入指定关键字后按下 tab 键即可输入内容，每次用户按下回车键，地址栏中输入的内容都会被发送到扩展中。

百度、必应、Github 等网站在 Chrome 中都有对应的关键字搜索功能，相信不少人都用过。在地址栏中输入 github.com 或者 baidu.com，然后按下 tab 键，地址栏就会变成下面的样子。在这种状态下我们输入的内容都会在相应网站中进行搜索执行。

devtools(开发者工具)

向开发者工具中的增加功能，如 Vue devtools、React devtools，前端一定不会陌生，本文不会重点讲解，建议查阅官网。

option(选项页)

对着 action 图标右键，菜单中就会显示 选项 菜单，如果菜单是亮起的，说明此扩展开启了选项功能。

选项页一般情况下，都会作为扩展的配置页面，如下

当然，所谓的选项页其实就是加载了一个指定的 HTML，至于 HTML 中是展示扩展的配置还是别的东西，这个完全取决于你自己。

上面讲的都是使用者可以直观感受的功能，接下来这两个脚本功能是使用者无法直接感知但又在扩展中无比重要的功能。

background-script（后台脚本）

后台脚本就是指伴随扩展的整个生命周期进而运行的 JS 文件，在这个 JS 中可以使用 Chrome 提供的 API 来监听浏览器、扩展的各种事件，通过对这些事件的监听，进而对扩展其他功能进行协调和处理。

content-script（内容脚本）

content-script 可以把指定的 JS、CSS 文件放在当前正在浏览的网页上下文中执行。

CSS 可以修改的网页的样式，JS 可以访问和更改当前页面的 BOM、DOM，进而对网页的样式、行为进行控制和更改。

以上就是插件中比较常用的一些功能，除了这些常用的功能 Chrome 还给我们提供了很多强大的 API，下面我们罗列一些常用的。

• Management: 管理已安装和运行的扩展
  • 扩展管理
• Message Passing: 各个扩展之间、扩展与 content-script 之间的通信
• Storage：提供本地存储与账号同步存储功能
• Tabs：在浏览器中创建、修改和重新排列标签
  • oneTab
• Windows：在浏览器中创建、修改和重新排列窗口
• Cookies：浏览和修改浏览器的 cookie 系统
  • cookies
• Cross-Origin：扩展中的 XMLHttpRequest 和 fetchAPI 是不受同源策略影响的。
• webRequest：拦截，阻止或修改请求网络请求
• Bookmarks：书签创建、组织和操作书签行为
• Downloads：以编程方式启动、监视、操作和搜索下载
• History：历史记录 与浏览器访问页面的记录交互
• Devtools: 向开发者工具中添加功能
• Accessibility(a11y)：可访问性
• Internationalization(i18n)：国际化
• identity: OAuth2 访问令牌
• Proxy：管理 Chrome 的代理设置
  • VPN

组件的使用方式

在开始之前，我们需要再了解一个东西：mainfest.json。

Mainfest

上一小节，我们讲了关于扩展的很多功能。再回顾开头，官方介绍中提到了这些组件都是由 Web 技术构建出来的，也就是说我们只需要给 Chrome 提供 HTML、CSS、JS，Chrome 就可以将它们作为扩展进而运行。

那这里就有了一个问题，Chrome 怎么知道这些文件就是扩展要运行的文件呢？它又如何知道哪些文件对应哪个功能呢？

所以这里就需要一个配置文件，来 告诉 Chrome 这个扩展应该如何构建，如何运行。这就是 mainfest.json 的作用。

详细的 mainfest.json 配置后面再说，这里了解完其概念之后我们接着往下讲。

Background-script

先说后台脚本，因为有些扩展的运行依赖于它。

配置方式：

// manifest.json  
{  
  "background": {  
    // 两种方式选其一  
    "page": "background.html",  
    "scripts": ["background.js"],  
    // 关闭持久连接  
    "persistent": false  
  }  
}  

在 manifest.json 中的 background 属性中，可以指定一个 JS 数组，或者一个 HTML。

HTML 作用就是加载执行其中的 JS，HTML 本身的内容是不会被展示出来的。

persistent 属性代表后台脚本的运行方式，默认为 true，表示会一直运行。如果指定为 false，则只会在一些重要的事件中运行。

• 该扩展程序首先安装或更新为新版本。
• 后台页面正在监听事件，并且已调度该事件。
• 内容脚本或其他扩展发送消息。
• 扩展中的另一个视图（例如弹出窗口）调用 runtime.getBackgroundPage。

官方推荐将其设置为 false，并且在 v3 中，persistent 属性被取消，取而代之的是使用 service script 指定后台脚本，其中的脚本将以 service worker 的方式运行。

persistent 怎么设置，还是要取决于扩展的功能。如果你还不知道怎么配置，那就指定为 false，因为多数情况下后台脚本都应该是由事件进而驱动运行的。

后台脚本可以访问 Chrome 提供的除 devtools 外的所有 API。

Content-script

配置方式:

{  
	"content_scripts": [  
		{  
			"matches": ["<all_urls>"],  
			"js": ["js/content-script.js"],  
			"css": ["css/custom.css"],  
			"run_at": "document_start",  
      // "exclude_matches": "",  
      // "include_globs": ""  
      // "exclude_globs": ""  
      // "match_about_blank": false  
		},  
    {  
			"matches": ["*://*.baidu.com/*"],  
			"js": ["bd-content.js"],  
			"run_at": "document_start"  
		}  
	]  
}  

content_scripts 属性是个数组，其中可以配置多个匹配规则，当匹配成功，就会将配置的文件进行注入执行。

• matches：指定 匹配模式，"<all_urls>" 表示所有网址。
• js/css: 要注入的文件。
• match_about_blank: 脚本是否应注入到 about:blank 页面，默认 false。
• exclude_matches/include_globs/exclude_globs: 配置额外的匹配模式。
• run_at：代码注入的时机
  • document_start：在 CSS 注入之后，在构建 DOM 和运行脚本文件之前被注入。
  • document_end：在 DOM 加载完成之后，可以理解为 DOMContentLoaded 事件。
  • document_idle：默认值，在 window.onload 事件调用的前后执行。具体时机取决于文档的复杂程度和加载所需的时间，并针对页面加载速度进行了优化。这个注入方式中不需要监听 onload 事件，因为可以确保 DOM 已经加载完成。如果必须要知道 onload 有没有触发，可以使用 document.readyState 进行判断。

出于安全性的考虑，content-script 的 JS 是在沙箱环境中执行的，它访问不到网页本身加载的 JS 定义的属性、方法，比如说网页本身加载了 jquery，那在 content-script 中是访问不到的，如果想要使用，只能在配置项中配置，在 content-script 的执行环境中注入一个 jquery。

content-script 可以对页面中的 DOM 进行随意的修改、删除、新增，可以给已有的 DOM 元素绑定事件，也可以创建一个新的 DOM 并给其添加事件后插入页面中。正常来说呢，已经可以满足大多数的需求了。

在参考文章 【干货】Chrome 插件(扩展)开发全攻略 中，提到 content-script 无法给 DOM 绑定事件，经测试是可以的，不知是不是扩展的功能更新了。

如果真的有需求，需要 JS 在当前网页的执行环境中进行执行，那也是可以实现的，既然我们可以操作 DOM，就可以很轻松的写出如下代码：

const script = document.createElement("script")  
script.innerHTML = "console.log(window.$)"  
document.body.append(script)  

这样通过操作 DOM 注入的 JS 就是在网页自身的执行环境运行的了。

当然，正常情况下我们不会通过 innerHTML 来实现，而是使用 script 的 src 属性直接加载一个 JS 文件。

代码如下：

	const script = document.createElement('script')  
	script.src = chrome.extension.getURL('js/inject.js')  
	document.head.appendChild(script)  

需要注意的是加载的路径是扩展目录的文件（当然也可以加载网络资源），这个目录地址我们需要通过 chrome.extension.getURLAPI 来获得。

还需要注意，如果你加载的是扩展目录的文件，那就需要在 web_accessible_resources 明确的配置文件名才行（网络资源不需要）。

{  
  "web_accessible_resources": [  
    "inject.js"  
  ]  
}  

内容脚本中只能访问如下的 Chrome API

• i18n
• storage
• extension
• runtime
  • connect
  • onConnect
  • onMessage
  • sendMessage
  • getManifest
  • getURL
  • id

其中的 runtime 中的前四个 API 提供了与扩展的其他部分进行通信的能力。

browserAction、pageAction

上节说到 action 点击后会弹出一个窗口，这个窗口其实就是一个小型的 tab 页面，里面加载了一个我们指定的 HTML 文件。

配置方式：

// manifest.json  
{  
  // "page_action"  
  "browser_action": {  
    // 图标  
    "default_icon": "img/icon.png",  
    // tooltip  
    "default_title": "标题",  
    // 弹窗页面  
    "default_popup": "popup.html"  
  }  
}  

可以看到我们在 default_popup 字段中指定了一个 HTML，这个 HTML 会在弹窗打开时加载，弹窗关闭后销毁。

也就是说，弹窗的每次的出现和消失，都是一个完整的生命周期。就像你在浏览器中打开一个 tab 页加载页面，随后又把这个 tab 页关闭了一样。

browserAction 与 pageAction 的区别

• browserAction 的图标是常亮的，它的功能在任何网页中都可以使用。
• pageAction 只会在指定的网站中亮起，它的功能也只限于这些指定网站使用。
  • octotree 扩展只会在 github 的项目页面亮起。
    

在 background.js 中使用 declarativeContent 对页面的变化进行匹配，然后来决定 pageAction 的点亮和置灰。

// manifest.json  
{  
  "permissions": ["declarativeContent"]  
}  
  
// background.js  
chrome.runtime.onInstalled.addListener(function(details) {  
  chrome.declarativeContent.onPageChanged.removeRules(undefined, function() {  
    chrome.declarativeContent.onPageChanged.addRules([{  
      conditions: [  
        new chrome.declarativeContent.PageStateMatcher({  
          pageUrl: { hostEquals: 'www.google.com', schemes: ['https'] },  
          css: ["input[type='password']"]  
        })  
      ],  
      actions: [ new chrome.declarativeContent.ShowPageAction() ]  
    }]);  
  });  
});  

在 Chrome ext v3 版本中，browserAction 与 pageAction 这两个区别并不大的功能被统一合并成了 action 功能。

action 和 background 一样，可以访问 Chrome 提供的除 devtools 外的所有 API。

在 action 中可以通过 chrome.extension.getBackgroundPage 或者 chrome.runtime.getBackgroundPage 直接获取到 background 脚本的 window 对象，进而访问其中的方法和属性。

这两个 API 的区别在于 background 的 persistent 属性，如果值为 false，空闲时后台脚本就是关闭的，需要使用 runtime.getBackgroundPage 通过事件机制将其唤醒，然后才能交互。

const bgs = chrome.extension.getBackgroundPage()  
// or  
chrome.runtime.getBackgroundPage((bgs) => {  
  bgs.backgroundFunction()  
})  

contextMenu(右键菜单)

在权限配置中声明我们需要 contextMenus 权限，然后为其制定一个图标。

{  
 "permissions": [  
    "contextMenus"  
  ],  
  "icons": {  
    "16": "icon-bitty.png",  
    "48": "icon-small.png",  
    "128": "icon-large.png"  
  }  
}  

在 background.js 中可以使用 chrome.contextMenus API 对菜单项进行增删改查。

chrome.contextMenus.create({  
	type: 'normal'， // 类型，可选：["normal", "checkbox", "radio", "separator"]，默认 normal  
	title: '菜单的名字', // 显示的文字，除非为“separator”类型否则此参数必需，如果类型为“selection”，可以使用%s显示选定的文本  
	contexts: ['page'], // 上下文环境，可选：["all", "page", "frame", "selection", "link", "editable", "image", "video", "audio"]，默认page  
	onclick: function(){}, // 单击时触发的方法  
	parentId: 1, // 右键菜单项的父菜单项ID。指定父菜单项将会使此菜单项成为父菜单项的子菜单  
	documentUrlPatterns: 'https://*.baidu.com/*' // 只在某些页面显示此右键菜单  
});  
// 删除某一个菜单项  
chrome.contextMenus.remove(menuItemId)；  
// 删除所有自定义右键菜单  
chrome.contextMenus.removeAll();  
// 更新某一个菜单项  
chrome.contextMenus.update(menuItemId, updateProperties);  

Override

"chrome_url_overrides":  
{  
  // 选其一覆盖  
	"newtab": "newtab.html",  
	"history": "history.html",  
	"bookmarks": "bookmarks.html"  
}  

通过上节罗列的扩展 API，我们可以拿到自己需要的数据并加以渲染。

devtools(开发者工具)

这个功能没有去深究，这里把官网的介绍复制一下。

每次打开 Devtools 窗口时，都会创建扩展的 Devtools 页面的实例。DevTools 页面在 DevTools 窗口的生命周期内一直存在。DevTools 页面可以访问 DevTools API 和一组有限的扩展 API。具体来说，DevTools 页面可以：

• 使用 devtools.panels API 创建面板并与面板进行交互。
• 获取有关检查窗口的信息，并使用 devtools.inspectedWindow API 在检查窗口中评估代码。
• 使用 devtools.network API 获取有关网络请求的信息。

DevTools 页面和 content-script 类似，只能使用有限的 Chrome API。DevTools 页面与后台页面通信同样是使用 runtime 的相关 API。

{  
  // 只能指向一个 HTML 文件，不能是 JS 文件  
  "devtools_page": "devtools.html"  
}  

Devtools 的开发场景并不多，如果想了解可以看文末的参考资料进行学习。

Omnibox

先在 manifest.json 中指定一个关键字以提供搜索建议（只能设置一个关键字）

{  
	"omnibox": { "keyword" : "go" },  
}  

在 background.js 中监听相关事件

// 输入框内容变化时触发，suggest用以提示做输入建议  
chrome.omnibox.onInputChanged.addListener((text, suggest) => {  
	if(!text) return;  
	if(text == '美女') {  
		suggest([  
			{content: '**' + text, description: '你要找“**美女”吗？'}  
		])  
	}  
})  
  
// 当用户接收关键字建议时触发  
chrome.omnibox.onInputEntered.addListener((text) => { });  

option(选项页)

在 manifest.json 中指定渲染 HTML 即可

{  
  "options_ui": {  
    "page": "options.html",  
    "chrome_style": true  
  }  
}  

manifest.json

官网 manifest 格式

{  
  // 清单文件的版本，值固定为2，现在已经有3了  
  "manifest_version": 2,  
  // 插件的名称  
  "name": "demo",  
  // 插件的版本  
  "version": "1.0.0",  
  
  // 插件描述  
  "description": "简单的Chrome扩展demo",  
  // 图标，一般偷懒全部用一个尺寸的也没问题  
  "icons": {  
    "16": "img/icon.png",  
    "48": "img/icon.png",  
    "128": "img/icon.png"  
  },  
  
  // 会一直常驻的后台JS或后台页面  
  "background": {  
    // 2种指定方式，如果指定JS，那么会自动生成一个背景页  
    "page": "background.html"  
    //"scripts": ["js/background.js"]  
  },  
  
  // 浏览器右上角图标设置，browser_action、page_action、app必须三选一  
  "browser_action": {  
    "default_icon": "img/icon.png",  
    // 图标悬停时的标题，可选  
    "default_title": "这是一个示例Chrome插件",  
    "default_popup": "popup.html"  
  },  
  // 当某些特定页面打开才显示的图标  
  "page_action": {  
    "default_icon": "img/icon.png",  
    "default_title": "我是pageAction",  
    "default_popup": "popup.html"  
  },  
  
  // 需要直接注入页面的JS  
  "content_scripts": [  
    {  
      //"matches": ["http://*/*", "https://*/*"],  
      // "<all_urls>" 表示匹配所有地址  
      "matches": ["<all_urls>"],  
      // 多个JS按顺序注入  
      "js": ["js/jquery-1.8.3.js", "js/content-script.js"],  
      // JS的注入可以随便一点，但是CSS的注意就要千万小心了，因为一不小心就可能影响全局样式  
      "css": ["css/custom.css"],  
      // 代码注入的时间，可选值： "document_start", "document_end", or "document_idle"，最后一个表示页面空闲时，默认document_idle  
      "run_at": "document_start"  
    },  
    // 这里仅仅是为了演示content-script可以配置多个规则  
    {  
      "matches": ["*://*/*.png", "*://*/*.jpg", "*://*/*.gif", "*://*/*.bmp"],  
      "js": ["js/show-image-content-size.js"]  
    }  
  ],  
  // 权限申请  
  "permissions": [  
    "contextMenus", // 右键菜单  
    "tabs", // 标签  
    "notifications", // 通知  
    "webRequest", // web请求  
    "webRequestBlocking",  
    "storage", // 插件本地存储  
    "http://*/*", // 可以通过executeScript或者insertCSS访问的网站  
    "https://*/*" // 可以通过executeScript或者insertCSS访问的网站  
  ],  
  // 普通页面能够直接访问的插件资源列表，如果不设置是无法直接访问的  
  "web_accessible_resources": ["js/inject.js"],  
  // 插件主页，这个很重要，不要浪费了这个免费广告位  
  "homepage_url": "https://www.baidu.com",  
  // 覆盖浏览器默认页面  
  "chrome_url_overrides": {  
    // 覆盖浏览器默认的新标签页  
    "newtab": "newtab.html"  
  },  
  // Chrome40以前的插件配置页写法  
  "options_page": "options.html",  
  // Chrome40以后的插件配置页写法，如果2个都写，新版Chrome只认后面这一个  
  "options_ui": {  
    "page": "options.html",  
    // 添加一些默认的样式，推荐使用  
    "chrome_style": true  
  },  
  // 向地址栏注册一个关键字以提供搜索建议，只能设置一个关键字  
  "omnibox": { "keyword": "go" },  
  // 默认语言  
  "default_locale": "zh_CN",  
  // devtools页面入口，注意只能指向一个HTML文件，不能是JS文件  
  "devtools_page": "devtools.html"  
}  

消息通信

开发时主要会用到 content-script 与 popup 和 background 之间的通信，通信分为短链接和长链接。

两者的通信其实就是进程间的通信，通信内容必须可以被序列化，可以理解消息体会被 JSON.stringify 后进行传递。所以消息体中不能发送 function、symbol、Map 等数据。

Popup <---> Background

background 中可以通过 chrome.extension.getViews({type:'popup'}) 来获取已打开的 popup，进而访问其中的属性、方法。

popup 可以通过 chrome.extension.getBackgroundPage 或者 chrome.runtime.getBackgroundPage 获取到 background 的 window，进而访问其属性和方法。

Popup | Background ==> Content-script

popup 和 background 给 content-script 发送消息

短链接

接收方 content-script 需要先完成消息事件的监听

const handleMessage = (message, sender, sendResponse) => {  }  
chrome.runtime.onMessage.addListener(handleMessage)  

• message: 消息内容
• sender: 发送者信息
• sendResponse: 回复消息的方法

发送方 popup | background 调用 API 发送消息

// 封装获取当前选中的tab标签方法  
const getCurrentTab = () => new Promise((resolve, reject) => {  
  chrome.tabs.query({active: true, currentWindow: true}, ([tab]) => {  
    tab?.id ? resolve(tab) : reject('not found active tab')  
  })  
})  
  
const tab = await getCurrentTab()  
// 发送消息  
chrome.tabs.sendMessage(tab.id, {greeting: "hello"}, (response) => { })  

tabs.sendMessage 的三个参数分别是

• 要与之通信的 tab 标签页的 id
• 消息体
• 响应的回调函数：这个就是上面的 sendResponse 函数

短链接注意事项：

• sendResponse 只能使用一次，不能多次使用。
• 默认情况下，handleMessage 函数执行结束，消息通道就会关闭，此时的 sendResponse 已经无效。也就是说 sendResponse 不能异步使用。
• 如果需要异步使用 sendResponse，需要在 handleMessage 中明确的写下 return true，这样消息通道会一直保持，直到 sendResponse 被调用。

长链接

接收方 content-script 需要先完成消息事件的监听

// 监听长链接 链接事件  
chrome.runtime.onConnect.addListener(port => {  
  // 可以根据 name 来区分不同的长链接逻辑  
  if (port.name === 'knockknock') {  
    // 给另一端发送消息  
    port.postMessage()  
  
    // 监听另一端的消息  
    port.onMessage.addListener(message => {})  
  }  
})  

发送方 popup | background 调用 API 发送消息

const tab = await getCurrentTab()  
  
// 建立链接  
const port = chrome.tabs.connect(tab.id, {name: "knockknock"})  
  
// 给另一端发送消息  
port.postMessage()  
  
// 监听另一端的消息  
port.onMessage.addListener(message => {})  

• port 端口对象
  • name: 端口名称
  • disconnect: 关闭端口
  • postMessage: 发送消息
  • onDisconnect: 监听端口关闭事件
  • onMessage: 监听端口消息事件
  • sender: 发送者的信息

Content-script ---> Popup | Background

content-script 给 popup 和 background 发送消息

两者的逻辑其实是一样的，只不过 popup | background 给 content-script 发送消息时，使用的是 chrome.tabs API，需要指定一个 tab 的 id。

而 content-script 给 popup | background 发送消息时，使用的时 chrome.runtime API，不需要 id。

短链接

接收方 popup | background 需要先完成消息事件的监听

const handleMessage = (message, sender, sendResponse) => {  }  
chrome.runtime.onMessage.addListener(handleMessage)  

发送方 content-script 调用 API 发送消息

// tabs 改为了 runtime  
chrome.runtime.sendMessage({greeting: "hello"}, (response) => { })  

如果 popup 和 background 都使用了 runtime.onMessage 监听了事件，那么当 content-script 发送了消息，两者都会接到。

但是 sendResponse 只有一个，一个先用了后者就无法使用了。

这里还存在一个坑，我们下节再说。

长链接

接收方 popup | background 需要先完成消息事件的监听

// 和上面一模一样  
chrome.runtime.onConnect.addListener(port => {  
  if (port.name === 'knockknock') {  
    port.postMessage()  
  
    port.onMessage.addListener(message => {})  
  }  
})  

发送方 content-script 调用 API 发送消息

// tabs 改为了 runtime  
const port = chrome.runtime.connect({name: "knockknock"})  
  
port.postMessage()  
port.onMessage.addListener(message => {})  

可以看到两者出了 API 的调用之外几乎没有区别，具体由谁主动发送消息，由谁来监听，需要根据实际需求来决定。

回复 CS 短链接消息踩坑

说一下在短链接中，popup | background 回复 content-script 时的坑。

问题的前置条件：

• sendResponse 需要异步发送。
• popup 和 background 都使用 runtime.onMessage 监听了 content-script 发来的消息。

当遇到上述场景时，会发现调用 sendResponse 后无法回复消息。

原因也很简单，我们在上面已经说过了，当 sendResponse 需要异步发送时，需要明确的在 runtime.onMessage 监听事件中返回 true，但是由于有两者都监听了，那么其中一个可能就会事先返回 undefined，这就导致了消息通道的提前关闭。

解决办法呢也很简单，我们需要将发送给 popup 和 background 的消息区分并封装，并将是否是异步消息发送给接收方。

代码如下

// 消息格式  
interface RuntimeMessage<T = string> {  
  type: T  
  payload: any  
  receiver?: 'bgs' | 'popup'  
  isAsync?: boolean  
}  
// 封装发送消息  
const sendMessageToRuntime = (  
  msg: RuntimeMessage,  
  cb?: LooseFunction,  
) => {  
  // 当传入callback时，默认这是一个异步消息  
  if (msg.isAsync === void 0 && isFunction(cb)) {  
    msg.isAsync = true  
  }  
  chrome.runtime.sendMessage(msg, cb)  
}  
// 使用  
sendMessageToRuntime({  
  type: 'crossFetch',  
  payload: {...},  
  receiver: 'bgs',  
}, (response) => {})  
  
// background.js  
chrome.runtime.onMessage.addListener(  
  (  
    {  
      type,  
      payload,  
      receiver,  
      isAsync,  
    },  
    sender,  
    sendResponse,  
  ) => {  
    if (receiver === 'bgs') {...}  
    return isAsync  
  },  
)  
  
// popup.js  
chrome.runtime.onMessage.addListener(  
  (  
    {  
      type,  
      payload,  
      receiver,  
      isAsync,  
    },  
    sender,  
    sendResponse,  
  ) => {  
    if (receiver === 'popup') {...}  
    return isAsync  
  },  
)  

两个 Tab 签之间的通信

由于本次开发过程中有这样的需求，而常规的 JS 手段无法与另一个 tab 页面建立通信（新 tab 页面地址是多次重定向的结果）。

这里主要演示一下由 background 作为消息通道，为两个 tab 签建立通信。

// tab页面1 content-script  
const port = chrome.runtime.connect({  
  name: 'createTabAndConnect',  
})  
// 创建目标tab  
port.postMessage({  
  type: 'createTab',  
  // tab 信息  
  payload: {...},  
})  
// 监听消息  
port.onMessage.addListener(handleMessage)  
// 发送消息  
port.postMessage({  
  type: 'message',  
  payload: {...}  
})  

// tab页面2 content-script  
chrome.runtime.onConnect.addListener(port => {  
  if (port.name === 'createTabAndConnect') {  
    // 监听消息  
    port.onMessage.addListener(handleMessage)  
    // 发送消息  
    port.postMessage({  
      type: 'message',  
      payload: {...}  
    })  
  }  
})  

// background.js  
port.onMessage.addListener(async ({ type, payload }) => {  
  switch (type) {  
    case 'createTab':  
      {  
        // 创建tab  
        const tab = await new Promise(resolve => {  
          chrome.tabs.create(payload, resolve)  
        })  
        // 监听tab 页面的状态  
        chrome.tabs.onUpdated.addListener((id, info) => {  
          if (id === tab.id) {  
            // 加载完成  
            if (info.status === 'complete') {  
              // 建立链接  
              tabPort = chrome.tabs.connect(id, {  
                name: port.name,  
              })  
              // 监听消息  
              tabPort.onMessage.addListener(msg => {  
                // 中转tabPort的消息给port  
                port.postMessage({  
                  type: 'message',  
                  payload: msg,  
                })  
              })  
            }  
          }  
        })  
      }  
      return  
    case 'message':  
      // 中转port的消息给tabPort  
      tabPort?.postMessage(payload)  
      return  
  }  
})  

使用 Umi 初始化项目

最后简单说一下 Umi 开发扩展的配置。

思路是将脚本文件加入入口文件单独打包，HTML 页面使用路由的方式，通过 hash 访问。

所以像 popup、options 这些需要视图的页面，直接在 pages 文件夹中写就行了。Umi 默认会将其作为路由进行打包。

// manifest.json  
{  
	"browser_action": {  
		"default_popup": "index.html#/popup"  
	},  
  "options_ui": {  
    "page": "index.html#/options",  
  }  
}  

在 scripts 文件夹中编写 content-script 和 background 文件，在 Umi 的配置文件中添加入口文件。

最终的 .umirc.ts 如下:

// .umirc.ts  
import { defineConfig } from "Umi"  
  
export default defineConfig({  
  nodeModulesTransform: {  
    type: "none",  
  },  
  cssLoader: {  
    localsConvention: "camelCase",  
  },  
  dynamicImport: {},  
  history: {  
    type: "hash",  
  },  
  targets: {  
    Chrome: 73,  
    firefox: false,  
    safari: false,  
    edge: false,  
    ios: false,  
  },  
  ignoreMomentLocale: true,  
  devServer: {  
    writeToDisk: true,  
  },  
  copy: ["manifest.json", "index.html", "hot-reload.js"] as any,  
  chainWebpack(memo, { env }) {  
    memo.devServer.hot = false as any  
    memo.plugins.delete("hmr")  
    memo  
      .entry("background")  
      .add("./src/scripts/background.ts")  
      .end()  
      .entry("content-script")  
      .add("./src/scripts/content-script.ts")  
      .end()  
  },  
})  

• targets 配置决定了代码如何被 polyfill，很明显作为 Chrome 的插件，我们不需要其他浏览器的 polyfill。
• devServer 将开发模式存在内存中的文件写到磁盘中，webpack 关闭热更新。
  • 扩展开发不像是平时的页面开发，所以热更新在这里没有作用。
  • 内存中的文件写到磁盘中，浏览器才能加载这些文件。
• 通过 copy 将 manifest.json 拷贝到根目录。
• copy index.html 是因为 Umi 默认会向 index.html 中注入两段 script 脚本，而扩展的 html 中是不允许存在内联脚本的。如果有的话就会有两个报错，当然这两个报错除了不好看之外也没有别的影响。所以这里不做处理也一样。
• 正常情况下，编辑完文件，就需要重新刷新扩展和当前 tab 页面，才能看到效果。而 hot-reload.js 可以帮我们去自动刷新，详细的用法可以点进去查看。

推荐阅读

• 官方提供的各组件 demo

参考资料

• 官方文档（自备梯子）
• 【干货】Chrome 插件(扩展)开发全攻略
• Umi 官方文档

2020-12-08

官方文档

child_process.spawn() 方法使用给定的 command 衍生新的进程，并传入 args 中的命令行参数。

函数签名

interface SpawnOptions {  
  cwd: string  
  env: Object  
  argv0: string[]  
  stdio: string[] | string  
  detached: boolean  
  uid: number  
  gid: number  
  serialization: string  
  shell: boolean  
  windowsVerbatimArguments: boolean  
  windowsHide: boolean  
}  
function spawn(command: string, options: SpawnOptions): ChildProcess  
function spawn(  
  command: string,  
  args: ReadonlyArray<string>,  
  options: SpawnOptions  
): ChildProcess  

参数详解

Command

spawn 模块会创建一个子进程，并在这个进程中调用传入的系统命令。

这里的系统命令 command 就是指你可以在终端中输入的命令，比如 npm、node、bash、ls、pwd、mongod 等等等等，你可以在终端中输入，就可以在这里传入

比如我们可以这样调用 ls 命令

const { spawn } = require("child_process")  
spawn("ls")  

Args

如果需要给命令传递参数，可以传入 args 属性，此属性默认为空数组

spawn("ls", ["-a"])  

Options

常用这两个：shell stdio

• shell: boolean | string = false

  • 如果为 true，则在 shell 中运行 command。
  • 在 Unix 上使用 '/bin/sh'，在 Windows 上使用 process.env.ComSpec。
  • 可以将不同的 shell 指定为字符串。参见 shell 的要求和默认的 Windows shell

• stdio: string[] | string = 'pipe'

  • 默认情况下，子进程的输入输出流都会在子进程中处理，我们可以将其设置为 inherit，来把子进程的输入输出放到副进程中处理。详见 options_stdio

  • 举个例子

      // index.js 文件  
        require('child_process').spawn('ls')  
    
      node index.js  
      // 如果我们直接这样执行代码，那么在终端中我们是看不到任何输出的  
      // 这是因为输出信息都传递给了子进程，而子进程并没有打印处理  
      // 我们加上下面的代码进行打印  
      require('child_process').spawn('ls').stdout.on('data', console.log)  
      // 此时再执行就可以在终端中看到输出的信息了  
    
      // 而如果我们将 stdio 设置为 inherit，则会将输入输出交由父进程处理，子进程不需要监听事件也可以在终端中看到输出的信息了  

• cwd: string

  • 设置子进程的工作目录，默认值：当前目录

• env: object

  • 环境变量的键值对。默认值: process.env

• argv0: string

  • 可以通过设置这个参数重写 command 参数的值，如果没有传入，则会被设置为传入的 command 值

• detached: boolean

  • 使子进程独立于其父进程运行, 具体行为取决于平台。详见 options_detached
    = uid: number
  • 设置进程的用户标识
    = gid: number
  • 设置进程的群组标识

• serialization: string = json

  • 指定用于在进程之间发送消息的序列化类型。可能的值为 'json' 和 'advanced'。

• windowsVerbatimArguments: boolean

  • 在 Windows 上不为参数加上引号或转义。
  • 在 Unix 上会被忽略。
  • 如果指定了 shell 并且是 CMD，则自动设为 true。默认值: false。

• windowsHide: boolean

  • 隐藏子进程的控制台窗口（在 Windows 系统上通常会创建）。默认值: false。

跨平台

在 unix 系统中，我们可以这样使用 spawn('npm')，这场可以正常运行的。但在 windows 系统中则会报错，这是因为在 windows 中我们实际执行的是 npm.cmd 批处理，而在 windows 上，.cmd .bat 批处理需要使用 cmd.exe 来运行。

所以我们需要显示的调用 cmd：spawn('cmd', ['/c', 'npm'])，或者我们可以设置 shell 参数来隐式调用 cmd spawn('npm', {shell: true})

虽然在 unix 中，我们设置 shell 为 true 也不妨碍命令的执行，但是这样就会额外产生一个不必要的 shell 进程。

所以我们可以这么来写，如果系统是 windows 则打开 shell

spawn("npm", {  
  shell: process.platform === "win32",  
})  

执行 Shell 命令

从上面的文章我们可以了解到, 默认情况下，spawn 并不会创建一个 shell 来执行我们传入的命令。

这个行为使得它比 exec 函数效率更高，但是有时我们又确实需要执行 shell 命令，那这个时候我们怎么使用 spawn 来执行呢？要知道 exec 函数会缓存输出结果一次性返回给我们，而 spawn 则是使用流的形式。如果我们的命令数据数据规模较小，那使用 exec 的确是个不错的选择，但在大多数情况下，使用 spawn 将会是更合理、更安全的方式

那么如果使用 spawn 来执行 shell 命令呢？

1. 最简单的，就是设置 shell 参数

// 设置为true  
spawn("npm run dev", { shell: true })  
// 指定终端  
spawn("npm run dev", { shell: "bash" })  

1. 也可以运行指定终端来执行命令

// 直接传入shell命令  
spawn("bash", ["npm", "run", "dev"])  
// 通过stdin.write写入命令  
const bash = spawn("bash")  
bash.stdin.write("npm run dev")  
bash.stdin.end()  

2020-01-31

IntersectionObserver 介绍

• mdn：Intersection Observer

Intersection Observer 可以异步的监听元素是否进入了可视区域内，当元素进入可视区域后，会触发相应的回调函数。

基本用法

const callback = () => {}  
// 实例化一个交叉观察者，并传入回调函数  
const intersectionObserver = new IntersectionObserver(callback)  
// 调用observe方法，监听需要观察的dom元素  
intersectionObserver.observe(document.querySelector(".scrollerFooter"))  

图片懒加载

图片懒加载的实现原理都是一样的，通过 data-src 属性保存真正的 src 地址，等到了触发条件时（即将进入视口），将 data-src 的值赋予 src 属性，开始加载图片。

有了 IntersectionObserver 我们可以很轻松的知道图片进入视口的时机，只需要再 callback 回调函数中替换 src 属性就可以了。

这里值得注意的一点是，一般情况下，我们并不希望图片在完全进入视口后才开始加载图片，我们需要让用户尽可能的感知不到图片的加载替换。所以我们将加载时机提前一点，比如说一屏的高度，那如果来设置这个高度呢。IntersectionObserver 在初始化时允许传入一个配置项，其中的 rootMargin 选项是用来标注额外的 margin 带来的位置信息判断错误问题，我们可以利用这一点，比如我们将 margin-bottom 设为 200px，IntersectionObserver 就会在视口距离监听元素 200px 时去触发回调函数，这就给了我们可以控制距离底部的距离的方法。

<img src="loading.jpg" data-src="realSrc.jpg">  
  
const intersectionObserver = new IntersectionObserver(function(entries) {  
  // entries是一个数组，我们会观察多个元素，所以会有多个元素同时进入视口这种情况  
  // intersectionRatio代表了元素进入视口的比例，当元素完全进入视口时值为1，当元素没有进入视口时值为0  
  // intersectionObserver在监听dom元素后就会执行一次callback，所以这里需要判断一下  
  if (entries[0].intersectionRatio <= 0) return;  
  // 开始替换src  
  entries.forEach(e => {  
    e.target.src = e.target.dataset.src  
  })  
}, {rootMargin: '0px 0px 200px 0px'})  
// 监听所有data-src属性的元素  
document.querySelectorAll('[data-src]').forEach(element => intersectionObserver.observe(element))  

2024-05-13

TL;DR

借助 lua_processor，自行实现 vim_mode 的中英文切换逻辑，使其支持：

• Linux 系统
• 重新进入 insert mode 时自动切换回中文模式（如果离开时是处于中文模式的话）

这并不是一个完美的解决方案，可能达不到 100% 的使用效果，但是在普通的情况下已经足以使用

使用方法

可以参考此 feat: vim_modeI

引入 vim_mode.lua 文件

首先将 vim_mode.lua 文件放入自己的 lua 文件夹中，并在 rime.lua 中进行导出

vim_mode = require("vim_mode")  

加入 lua_processor

在自己的中文输入方案中，加入 lua_processor

比如我使用的是小鹤双拼，所以我修改 double_pinyin_flypy.custom.yaml，加入如下逻辑

patch:  
  # 加入 lua_processor  
  engine/processors/@before 0: lua_processor@vim_mode  
  # 默认关闭 vmode，只在对应的 app 中打开  
  switches/+:  
    - name: vmode  
      reset: 0  

配置 app_options

在对应平台的 .custom.yaml 中配置在什么应用下启用 vmode

比如 macOS 的 squirrel.custom.yaml

patch:  
  app_options:  
    org.alacritty:  
      ascii_mode: true  
      vmode: true  
    net.kovidgoyal.kitty:  
      ascii_mode: true  
      vmode: true  

实现思路与原因

起因

我觉得 vim_mode 的确是一个非常好的功能，尤其是我这种既要用 Obsidian，又要用 Terminal，偶尔还要用 VSCode 的人

虽然这些软件中都有类似 im-select 之类的切换插件，但是每个软件中都需要单独安装，且不同的操作系统，配置还可能不一样（比如我自己就在 macOS 和 Linux 下频繁切换）

所以如果能有一个 IM 级别的 vim_mode 切换解决方案，那真是再好不过了

可是目前的 vim_mode 有两个问题：

1. 由前端实现，Linux 中不支持此功能
2. 在中文模式下，切换到 normal mode，再进入 insert mode，会保持 ascii mode，而不会自动切换会中文模式
   • 像 im-select 就会自动切换回中文模式

思路

搜索之后发现并没有一个现成的解决方案，但是却有大佬写过类似的逻辑，比如

• 如何在Windows/Linux下的Rime使用Vim模式 - 知乎
• 能否获取当前在什么应用下嘛 · Issue #294 · hchunhui/librime-lua · GitHub

稍微组合一下，就有了本文的解决方案

通过 switches 配置 vmode，再通过 app_options 配置在相应应用下打开 vmode ，即可实现原生的 vim_mode 在指定应用下开启的效果

利用 lua_processor 对按键输入进行处理，如果当前应用处于 vmode 下，就进行相关的逻辑处理

如 有考虑加入win端和macos端的vim mode · Issue #84 · fcitx/fcitx5-rime · GitHub 中所说，rime 是无法感知应用处于什么模式的（vim）
同样我们也无法知道应用处于什么模式，只能是根据 vim 的常规操作逻辑去大致的处理一下

思路如下：

在开启了 vmode 的应用中

• 如果按下了 esc 键，就认为要切换到 normal mode
  • 如果此时处于中文模式，就自动切换到英文模式，并记录中文状态
• 如果处于 normal mode，并且按下了 i/a/o/c 等会进入插入模式的按键
  • 如果之前是中文状态，就自动切换回中文状态

Ref

• 请问linux 下支持“针对特定程序使用英文模式”功能吗？ · Issue #40 · fcitx/fcitx5-rime · GitHub
• 请问 fcitx5-rime 有没有切换中英文的命令 · Issue #30 · fcitx/fcitx5-rime · GitHub

2021-10-21

三个角度

1. 工程化角度：Hooks 存在的意义
2. 设计者角度：实现 Hooks 要解决的问题、核心 API 分类
3. 开发者角度：基于 Hooks 对服务端状态进一步封装

工程化角度：Hooks 存在的意义

Hooks 解决了什么问题？

❌ 使函数式组件拥有状态，从而实现 Class 组件的功能

function App() {  
  // this.state this.setState  
  const [state, setState] = useState()  
  
  // componentDidMount()  
  useEffect(() => {  
    // componentWillUnmount()  
    return () => {}  
  }, [])  
  
  // componentDidUpdate()  
  useEffect(() => {})  
  
  // render()  
  return <div></div>  
}  

✅ 👇

React 没有将「逻辑」「抽离出」组件的能力

Class：逻辑属于某个组件

class XXX extends Component {  
  state = { bool: false }  
  handleTrue() {}  
  handleFalse() {}  
  
  render() {}  
}  

hooks：独立逻辑，不属于任何组件

function useBoolean() {  
  const [bool, setBool] = useState(false)  
  const handleTrue = () => {}  
  const handleFalse = () => {}  
}  

##「视图」「逻辑」分离

React

• mixins、render-props、Hoc

Vue

• mixins、scope-component、Hoc

Angular

• DI

状态管理方案

• Redux、Mobx ...

为什么要执着于「视图」「逻辑」分离？

软件开发的难点

如何更好的适应无休止的需求变化

巨人的肩膀

分层架构、设计模式、领域驱动、SOLID、KISS、YAGNI、DRY、迪米特法则 ...

小步「重构」

「每次」需求变化时，都将代码「重构」成最适合当前的

##「分离」让下一个程序员更易「重构」

###「分离」为主，「复用」是顺其自然的

如若下次需求需要复用，分离的代码可以让下个人很容易的「重构」，反之则不行。

好的代码不是告诉计算机怎么做，
而是告诉另一个程序员你想要计算机怎么做。
--《趣学设计模式》

视图也可以是逻辑的一部分

设计者角度：实现 Hooks 要解决的问题

以下均为概念性的思考和理解，不等于最佳实践 & 不等于源码实现

useRef：状态保存

React 的运行机制是每次更新时，函数都会重新运行，这意味着作用域重建，函数内的状态丢失

所以需要将状态存在函数作用域之外，且要与组件的生命周期挂钩（申请和释放）

useRef 就提供了这样的能力，这很重要，因为一旦有了状态，我们自己就可以做很多事情

需要框架层提供能力

const root = document.getElementById("root")  
  
function App() {  
  // let i = 0  ❌  
  const i = useRef(0)  
  return <h1>{i.current++}</h1>  
}  
  
setInterval(() => {  
  ReactDOM.render(<App />, root)  
}, 1000)  

useState：触发更新

useState 的核心在于 setter 函数，它会触发视图更新

实际上，我们完全可以使用 useRef + setter 来完成状态更新

只是说明有了持久化状态后我们可以这样做，实际工作中不要这么做（会被打

const root = document.getElementById("root")  
const { useState } = React  
  
function App() {  
  const i = useRef(0)  
  let [, reRender] = useState(0)  
  
  setInterval(() => {  
    i.current++  
    reRender()  
  }, 1000)  
  
  return <h1>{i.current}</h1>  
}  
  
ReactDOM.render(<App />, root)  

useCtlCall：控制函数调用

如果你尝试了上面的代码，很快就会页面更新出现了问题

这是因为每次 reRender，组件函数都会重新运行，导致 setInterval 被重复多次的注册

所以我们需要某种方式，来控制函数的调用逻辑，同样的有了状态之后，这并不是一个困难的事情

const root = document.getElementById("root")  
const { useState, useRef } = React  
  
const isEq = (value, other) => {  
  if (Object.is(value, other)) return true  
  
  if (Array.isArray(value) && Array.isArray(other)) {  
    if (value.length === 0 && other.length === 0) return true  
  
    return value.every((item, i) => Object.is(item, other[i]))  
  }  
  
  return false  
}  
  
function useCtlCall(fn, deps) {  
  const prevDeps = useRef(undefined)  
  
  if (isEq(prevDeps.current, deps)) return  
  
  fn()  
  prevDeps.current = deps  
}  
  
function App() {  
  let [i, setState] = useState(0)  
  
  useCtlCall(() => {  
    setInterval(() => {  
      setState(i++)  
    }, 1000)  
  }, [])  
  
  return <h1>{i++}</h1>  
}  
  
ReactDOM.render(<App />, root)  

useMemo & useCallback

是的，轻松就可以实现 useMemo 和 useCallback

不等于实际源码

function useMemo(fn, deps) {  
  const cacheValue = useRef()  
  
  useCtlCall(() => {  
    cacheValue.current = fn()  
  }, deps)  
  
  return cacheValue.current  
}  
  
function useCallback(fn, deps) {  
  return useMemo(() => fn, deps)  
}  

useLayoutEffect & useEffect

同上是用来控制函数调用时机，但是需要集成进框架中，以在适当的时机触发函数调用

useContext

不等于实际源码

export const createContext = (defaultValue) => {  
  const context = {  
    value: defaultValue,  
    subs: new Set(),  
    Provider: ({ value, children = "" }) => {  
      useEffect(() => {  
        context.subs.forEach((fn: any) => fn(value))  
        context.value = value  
      })  
      return children  
    },  
  }  
  return context  
}  
  
export const useContext = (context, selector?) => {  
  const subs = context.subs  
  const [, forceUpdate] = useReducer((c) => c + 1, 0)  
  const selected = selector ? selector(context.value) : context.value  
  const ref = useRef(null)  
  
  useEffect(() => {  
    ref.current = selected  
  })  
  
  useEffect(() => {  
    const fn = (nextValue: unknown) => {  
      if (selector && ref.current === selector(nextValue)) return  
      forceUpdate(nextValue)  
    }  
    subs.add(fn)  
    return () => subs.delete(fn)  
  }, [subs])  
  
  return selected  
}  

开发者角度：基于 Hooks 对服务端状态进一步封装

Dva 服务端状态管理

如 redux 或其他框架也是一样的

重复代码

观察下面的代码中有多少是重复的，可封装的

const m: IReuseTaskDetailModel = {  
  namespace: "reuseTaskDetail",  
  state: {  
    detail: {},  
    auditRecord: {},  
    list: {},  
  },  
  effects: {  
    *getTaskDetail({ payload: id }, { call, put }) {  
      const { data } = yield call(() => axios.get("xxx"), id)  
      return yield put({  
        type: "mergeModel",  
        payload: {  
          detail: data,  
        },  
      })  
    },  
    *getAuditRecord({ payload: params }, { call, put }) {  
      const { data, paging } = yield call(() => axios.get("xxx"), params)  
      return yield put({  
        type: "mergeModel",  
        payload: {  
          auditRecord: {  
            data,  
            paging,  
          },  
        },  
      })  
    },  
    *getList({ payload: params }, { call, put }) {  
      const { data, paging } = yield call(() => axios.get("xxx"), params)  
      return yield put({  
        type: "mergeModel",  
        payload: {  
          list: {  
            data,  
            paging,  
          },  
        },  
      })  
    },  
  },  
}  

封装重复

事实上我们可以把所有请求全放入一个 namespace，使用 api 地址做 state[key] 即可

const mergeState = ({ put, key, data, isLoading, isError }) =>  
  put({  
    type: "mergeModel",  
    payload: {  
      [key]: {  
        data,  
        isLoading,  
        isError,  
      },  
    },  
  })  
  
interface State {  
  // 接⼝地址  
  [key: string]: {  
    data: any  
    isLoading: boolean  
    isError: boolean  
  }  
}  
  
const serverModel = {  
  namespace: "serverModel",  
  state: {},  
  effects: {  
    *fetch({ payload: { key, fn } }, { call, put }) {  
      try {  
        yield mergeState({  
          put,  
          key,  
          data: undefined,  
          isLoading: true,  
          isError: false,  
        })  
        const data = yield call(fn)  
        yield mergeState({ put, key, data, isLoading: false, isError: false })  
        return data  
      } catch (e) {  
        yield mergeState({  
          put,  
          key,  
          data: undefined,  
          isLoading: false,  
          isError: true,  
        })  
        return Promise.reject(e)  
      }  
    },  
  },  
}  

使用

function useTaskList() {  
  const key = "/api/tasklist"  
  const dispatch = useDispatch()  
  
  useEffect(() => {  
    dispatch({  
      type: "serverModel/fetch",  
      payload: {  
        key,  
        fn: fetchTaskList,  
      },  
    })  
  }, [])  
  
  return useSelector(({ serveState }) => serveState[key])  
}  
  
function TaskList() {  
  const { data, isLoading } = useTaskList()  
  return <div>{data}</div>  
}  

接着封装

细看会发现取值逻辑也是重复的，依然可以简化

function useQuery(key, fn) {  
  const dispatch = useDispatch()  
  
  useEffect(() => {  
    dispatch({  
      type: "serverModel/fetch",  
      payload: {  
        key,  
        fn,  
      },  
    })  
  }, [])  
  
  return useSelector(({ serveState }) => serveState[key])  
}  
  
function useTaskList() {  
  return useQuery("/api/tasklist", fetchTaskList)  
}  

Mutation

查询逻辑是挂载时自动请求的，写入逻辑则需要手动触发，所以可以再简单封装下

function useMutation(key, fn) {  
  const dispatch = useDispatch()  
  return {  
    ...useSelector(({ serveState }) => serveState[key]),  
    mutate() {  
      dispatch({  
        type: "serverModel/fetch",  
        payload: {  
          key,  
          fn,  
        },  
      })  
    },  
  }  
}  
  
function useDelTask() {  
  return useMutation("/api/del/tasklist", fetchTaskList)  
}  

封装后的状态管理代码

是不是干净整洁无异味，

const useTaskList = () => useQuery("/api/xxx", fetchXXX)  
const useTaskDetail = () => useQuery("/api/xxx", fetchXXX)  
const useAuditTask = () => useQuery("/api/xxx", fetchXXX)  
const useAuditInfo = () => useQuery("/api/xxx", fetchXXX)  
  
const useDelTask = () => useMutation("/api/xxx", fetchXXX)  
const usePostTask = () => useMutation("/api/xxx", fetchXXX)  

最后

上述代码只是想说明 hooks 的封装、简化能力，真实的场景中还会有更多的挑战：

• 问题
  • 如何重新请求 & 手动控制请求（e.g. 搜索）
  • 相同接⼝相同参数的重复请求处理？
  • 相同接⼝不同参数的请求处理？
• 优化
  • 依赖查询
  • 更⽅便的取消请求
  • 缓存
  • 窗⼝聚焦重新获取
  • 数据预取
  • 分⻚
  • 轮询
  • loading 闪烁

实际上工作中我们可以直接使用 react-query 来帮助我们管理服务端状态

而对于服务端状态管理的话题，终端的异步状态管理 中有更深入的探讨，感兴趣可以继续阅读

2023-02-03

现如今 TS 已经完全走进了前端社区，纵观流行的前端框架/库，都有 TS 类型支持，不少框架/库更是对于源码是使用 TypeScript 开发，完美支持 TypeScript 类型提示当作一大亮点去宣传。

在业务中用 TS 写写页面、表格等上层逻辑，基本就是把后端数据定义/转换成 interface，往后一把梭就完了，不需要对 TS 的类型系统有深入的了解。

但当封装公用组件/函数时，如果想封装的代码能够支持 TS 类型，就需要了解类型编程的一些技巧，本文就分享一些常用的类型编程技巧。

好的 TS 类型支持

良好的类型推断，避免重复的类型定义

// string[]  
const result = [1, 2, 3]  
  .map((item) => () => item)  
  .map((fn) => ({ value: fn() }))  
  .map((item) => ({ label: `${item.value}` }))  
  .map((item) => item.label)  
  
// ---  
interface ResponseData {  
  is_success: boolean  
  data: {  
    id: number  
    pu_info: Record<string, string>  
    service_price: number  
    order_price: number  
  }[]  
}  
  
const fetchListData = async () => {  
  let data = await request<ResponseData>("/api/list") // ResponseData  
  
  data = transformKeys(data) // ResponseData1: isSuccess puInfo orderPrice  
  
  return transformMoney(data, ["orderPrice"]) // ResponseData2: orderPrice: string  
}  
  
const { data, isLoading, isError } = useSWR(fetchListData) // data: ResponseData2  
  
const id = get(data, "data.id") // number  

常见套路：提取 → 转换 → 重组 → 递归（循环）

前置知识

基础知识

// 类型  
type T = string | number | boolean | class | interface // ...  
  
// 类型推断  
{  
  let A = 1 // number  
  let B = "hello" // string  
  let C = [1, 2, 3] // number[]  
}  
  
// 常量类型推断  
{  
  const A = 1 // 1  
  const B = "hello" // 'hello'  
  const C = [1, 2, 3] as const // readonly [1, 2, 3]  
}  
  
// 联合类型：｜  
type Union = { hello: string } | { world: number }  
  
// 交叉类型： &  
type Intersect = { hello: string } & { world: number }  
  
// .....  

对象操作：keyof、in

// 返回对象 key 的常量联合类型  
keyof T // hello | world  
  
// 返回对象值的联合类型  
T[keyof T] // string | number  
T['hello'] // string  
T['world'] // number  
  
// in 操作符遍历联合类型  
interface A {  
    [K in string | number]: never  
    [K in 'hello' | 'world']: never  
    [K in keyof T]: T[K]  
}  
  
// ------ 源码 ------  
  
/**  
 * Make all properties in T required  
 */  
type Required<T> = {  
    [P in keyof T]-?: T[P];  
};  
  
/**  
 * From T, pick a set of properties whose keys are in the union K  
 */  
type Pick<T, K extends keyof T> = {  
    [P in K]: T[P];  
};  
  
/**  
 * Construct a type with a set of properties K of type T  
 */  
type Record<K extends keyof any, T> = {  
    [P in K]: T;  
}  

类型约束、条件类型：extends

// 泛型参数约束  
type T<P extends string> = {}  
  
// 条件类型  
type IsString<T> = T extends string ? true : false  
type A = IsString<"1"> // true  
type B = IsString<2> // false  

条件类型推断：infer

1. 声明一个类型
2. 如果类型约束成功
3. 将模式匹配后的类型分配给 1

// 条件类型推断  
type Example<T> = T extends infer R ? R : never  
type A = Example<"1"> // '1'  
type B = Example<2> // 2  

模式匹配

type A = [1, 2, 3]  
type ExampleA = A extends [infer First, ...infer Rest] ? First : never // 1  
  
type B = "123"  
type ExampleB = B extends `${infer FirstChar}${infer Rest}` ? FirstChar : never // '1'  
  
type C = (p: number) => string  
type ExampleB = C extends (p: infer R) => any ? R : never // number  
  
// ------ 源码（删减了类型约束） ------  
  
/**  
 * Obtain the parameters of a function type in a tuple  
 */  
type Parameters<T> = T extends (...args: infer P) => any ? P : never  
  
/**  
 * Obtain the return type of a function type  
 */  
type ReturnType<T> = T extends (...args: any) => infer R ? R : any  
  
/**  
 * Obtain the parameters of a constructor function type in a tuple  
 */  
type ConstructorParameters<T> = T extends abstract new (...args: infer P) => any  
  ? P  
  : never  
  
/**  
 * Obtain the return type of a constructor function type  
 */  
type InstanceType<T> = T extends abstract new (...args: any) => infer R  
  ? R  
  : any  

函数参数泛型推导

function f<A, B, C extends string>(a: A, b: B, c: C) {}  
  
f("a", "b" as const, "c") // function f<string, "b", "c">(): void  
  
interface Api {  
  "/api/phone": { phone: string }  
  "/api/email": { email: string }  
}  
  
function request<T extends keyof Api>(url: T): Api[T] {  
  return "" as any  
}  
  
request("/api/phone") // { phone: string }  
request("/api/email") // { email: string }  

示例

Get

Infer 在字符串模板中的小细节

1. 如果模版中只有一个 infer，它会尽可能多的匹配（贪婪模式）。比如用 ${infer T}x 去匹配 'abcxxx'，T 为 'abcxx'。
2. 如果有多个 infer，最后一个 infer 是贪婪模式，前面的是非贪婪模式。比如 ${infer A}${infer B}${infer C} 去匹配 'abcdefg'，结果为：A: 'a'，B: 'b'，C: 'cdefg'

type Get<T, Paths extends string> = Paths extends keyof T // 递归出口  
  ? T[Paths]  
  : Paths extends `${infer K}.${infer R}` // 匹配 . 语法  
  ? K extends keyof T  
    ? Get<T[K], R> // 递归  
    : unknown  
  : unknown  
  
// _.get(obj, 'a.b.c')  
type R = Get<{ a: { b: { c: { d: number } } } }, "a.b.c">  

RTK Query

Api 设计

// @ts-nocheck  
// Define a service using a base URL and expected endpoints  
export const pokemonApi = createApi({  
  endpoints: (builder) => ({  
    getPokemonByName: builder.query<Pokemon[], string>({  
      query: (name) => `pokemon/${name}`,  
    }),  
    getPokemonById: builder.query<Pokemon, string>({  
      query: (id) => `pokemon/${id}`,  
    }),  
  }),  
})  
  
// Export hooks for usage in functional components, which are  
// auto-generated based on the defined endpoints  
export const { useGetPokemonByNameQuery, useGetPokemonByIdQuery } = pokemonApi  
  
const { data, isLoading, isError } = useGetPokemonByNameQuery()  

实现

interface Endpoints {  
  getPokemonByName: string  
  getPokemonById: number  
}  
  
// 转化 key 字符串  
// 问题：无法取出准确的值类型  
type _B = {  
  [K in `use${Capitalize<keyof Endpoints>}Query`]: Endpoints[keyof Endpoints]  
}  
  
// 准确的值类型：双重遍历  
// 问题：结构不是我们想要的  
type B = {  
  [P in keyof Endpoints]: {  
    [K in `use${Capitalize<P>}Query`]: Endpoints[P]  
  }  
}  
  
// 取出值类型  
// 问题：联合类型，无法使用  
type C = B[keyof B]  
  
// 联合类型转交叉类型  
type UnionToIntersect<T> = (T extends any ? (k: T) => any : never) extends (  
  k: infer P  
) => any  
  ? P  
  : never  
  
type E = UnionToIntersect<C>  
  
const e = {} as E  
  
e.useGetPokemonByNameQuery // ✅