很多人第一次接触 pnpm workspace、yarn workspace 或 monorepo，都会有点懵：

为什么一个仓库里会有这么多包？它们又是怎么互相引用的？

这时候你大概率会看到一个词：Workspace。

如果只用一句人话解释它，可以这么理解：

Workspace 就是把一个仓库里的多个包组织起来，让它们既能一起管理，又能直接互相依赖。

它最常见的使用场景，就是 Monorepo。

比如一个前端仓库里，可能同时有：

• 一个主应用
• 一个组件库
• 一个工具包
• 一个命令行脚手架

这些包都放在同一个仓库里，但又不是一坨代码混在一起。
这时候，Workspace 就是把它们串起来的那套机制。

当项目开始走向 Monorepo，一个仓库里同时维护多个包时，很快就会遇到一个现实问题：

代码能一起写了，那版本号、CHANGELOG、发版流程怎么一起管？

这时候很多团队会用到一个工具：Changesets。

如果用一句最通俗的话解释它，可以这么理解：

Changesets 就像 Monorepo 里的“发版记录单”系统。

你每做完一次改动，就先记一张“这次改了什么、该升哪个版本”的单子；等准备发版时，再统一计算版本号、生成 CHANGELOG、执行发布。

它最适合的场景，就是：

• 一个仓库里有多个 npm 包
• 包和包之间有依赖关系
• 团队希望版本管理更清晰、发布流程更自动化

很多人第一次接触 Docker，都会先记一堆命令：

• docker pull
• docker run
• docker ps
• docker exec

但如果你不知道 Docker 为什么会出现，这些命令很容易记了又忘。

所以这篇文章不只是整理命令，而是想先把最核心的问题讲清楚：

• Docker 是为了解决什么问题出现的？
• 它和虚拟机有什么区别？
• image、container、Dockerfile 分别是什么？
• 日常开发里最常用的命令有哪些？

如果你把这几个问题理解了，后面的命令就不再是死记硬背。

如果你刚接触前端工程化，第一次看到 npm install、yarn install、pnpm install，大概率会有一个疑问：

它们不都是“装包”的吗？为什么会有三个？

答案是：它们做的是同一件事，但解决问题的方式不一样。

• npm 是 Node.js 官方自带的包管理器，历史最久，生态最稳。
• Yarn 是在 npm 早期体验不够好的时候出现的，重点解决“慢”和“不稳定”。
• pnpm 是在 Yarn 和 npm 继续发展之后，进一步解决“磁盘浪费”和“依赖不严谨”的问题。

这篇文章不讲太多绕人的术语，只用一条主线讲清楚：

为什么会从 npm 发展到 Yarn，再发展到 pnpm？

很多人第一次接触前端工程化时，看到 Monorepo、pnpm workspace、Changesets 这几个词，经常会有点混：

• 它们是不是一回事？
• 为什么总是一起出现？
• 到底谁负责开发，谁负责发布？

其实它们不是同一种东西，而是处在不同层级。

如果只用一句话总结三者关系，可以这么理解：

Monorepo 负责“组织方式”，pnpm workspace 负责“本地开发和依赖管理”，Changesets 负责“版本管理和发布”。

也就是说：

• Monorepo 是一种架构思路
• pnpm workspace 是落地这套架构的开发工具
• Changesets 是给这套架构补上发版流程的工具

这篇文章就专门把这三者的分工讲清楚。

很多人第一次用 pnpm，都会先感受到两个特点：

• 安装速度挺快
• node_modules 看起来和 npm、Yarn 不太一样

然后就会冒出一个问题：

pnpm 到底做了什么，为什么它既能省空间，又能保持依赖可用？

如果你去搜它的原理，常常会看到一堆词：

• 内容寻址存储
• 硬链接
• 软链接
• 严格依赖隔离

这些词本身没错，但一上来全堆出来，反而很容易越看越晕。

这篇文章我想用更通俗的方式，把 pnpm 的底层逻辑讲清楚。你不需要先懂文件系统，只要抓住一条主线：

pnpm 的核心目标，就是“同样的包尽量只存一份，同时又要让 Node.js 还能正常找到它”。

RFQ（Request For Quote）是一种面向机构和大额交易用户的询价交易模式。它通过聚合多做市商报价，为用户提供更确定的成交价格和更优的流动性。

如果从业务链路去看，一个完整的 RFQ 系统通常会串起这些能力：

• 用户准入与 KYC 校验
• 询价请求与报价返回
• 做市商报价聚合
• 用户确认与订单执行
• 基于 OTC 的清算结算
• 与 FX、用户风控、定投等业务联动

所以 RFQ 从来都不只是“一个交易页面”，而是一套高度业务化的交易系统能力。

这篇文章不是写“某个组件怎么写”，而是更偏项目复盘、面试表达、晋升答辩的文章。

我想讲清楚的是：

• RFQ 为什么值得单独做成公司级能力
• 它早期为什么难做、卡在哪里
• 我做了哪些关键改造
• 这套能力给业务和团队带来了什么价值
• 它未来还能往哪个方向继续演进

从「多入口」到「统一入口 + 流量调度中心」

要理解网关，先看它解决什么问题：微服务拆多了，客户端要面对一堆服务地址、一堆认证和限流逻辑，维护和安全都难。网关就是放在最前面的统一入口和调度层——所有请求先到网关，再由网关转发到具体服务。下面按「架构位置 → 核心能力 → 为什么需要 → 常见实现 → 总结」用总分总的方式讲清。

从中心化问题到去中心化解决方案

要真正理解区块链的本质，我们首先必须了解它旨在解决的根本问题。区块链技术的核心在于应对中心化系统固有的漏洞和局限性，这些漏洞和局限性体现在我们管理资金的方式以及达成集体协议的方式上。

从数字现金到比特币，再到以太坊

要理解区块链的威力和用途，得先看它的起源：人类对真正数字货币的长期探索。这段历史不是从「区块链」三个字开始，而是从数字世界里创造和转移价值所面临的根本挑战开始——一个困扰计算机科学家几十年的问题，最终由比特币第一次在工程上解决。

本系列介绍 NestJS 入门必备：CLI 常用命令、IoC/DI 思想，以及 TypeScript 装饰器在 Nest 中的用法。

从「要许可」到「无需许可」，权力和自主权回到你手上

说人话就是：区块链为啥被说得那么神？先想一件事——钱到底算不算你的。传统世界里，你想用钱，得看银行、平台给不给你许可；他们说不算就不算。区块链把这事儿反过来了：不用谁批准，链上的资产就是你自己的，你说了算。那**区块链是怎么做到这一点的？**下面从四个方向说清楚。