$$wm = \max\left(; peak_busy,;; busy + slack ;\right)$$

test

DJI简历

嵌入式常用的只读文件系统，我们先从squashfs说起，如何设计一个专为嵌入式系统和 Live CD 设计的高压缩只读文件系统，它的文件系统快结构，压缩办法，访问办法以及随机访问速度

## 什么是 SquashFS

SquashFS 本质上是一个**压缩的、只读的 Linux 文件系统**，但它的用途远不止于此。它还可以作为一个灵活、通用的压缩存档格式使用。

它的核心设计目标有三个：

1. **快速随机访问**：压缩文件被分割成固定大小的块，每个块独立压缩存储
2. **完整的 Unix 权限支持**：支持文件权限、稀疏文件和扩展属性
3. **多压缩算法支持**：可选用 zlib、lz4、lzo、lzma、xz 或 zstd 进行压缩

因为squashfs-tools和 squashfs-tools-ng 的默认制作参数是 128K，所以我们可以看到大部分squashfs的默认块大小为 128KB（可通过 mksquashfs 设置 4KB 到 1MB 之间的任意 2 的幂次值）。
为什么squashfs-tools-ng要选 128KB？因为这是压缩率和随机访问性能的平衡点——块太小压缩率低，块太大则随机读取时要解压很多无关数据。

## 整体架构：九个部件的精密协作

SquashFS总是以小端序格式存储整数。 构成 SquashFS 归档的数据块是字节对齐的(没有以4K这种效果对齐)

SquashFS 归档文件由最多九个部分有序组成：

```
_______________
|  Superblock  |  归档的核心，包含其他所有部件的位置信息
|_______________|
|  Compression |  可选，存储非默认压缩选项
|    options   |
|_______________|
|  Data blocks |  文件内容，分割为独立压缩的块
|  & fragments |
|_______________|
|  Inode table |  文件的元数据（所有权、权限等）
|_______________|
|  Directory   |  目录列表，包含文件名和 inode 引用
|    table     |
|_______________|
|  Fragment    |  描述片段块在数据区中的位置
|    table     |
|_______________|
|  Export      |  inode 号到磁盘位置的映射，支持 NFS 导出
|    table     |
|_______________|
|  UID/GID     |  唯一的 UID/GID 列表，inode 用索引节省空间
|  lookup table|
|_______________|
|  Xattr       |  扩展属性表
|    table    |
|_______________|
```


## 文件数据的打包策略

### 数据块：分而治之

文件被分割成固定大小的块(128K)，每个块独立压缩并按顺序存储。如果一个文件不是块大小的整数倍，剩余的"尾部"可以单独处理，也可以与其他文件的尾部打包成一个**片段块（fragment block）**。

所以片段块的含义是
1. 如果一个文件超过块大小的取余部分
2. 其他小文件的组合(小于128K文件)

关键设计点：如果某个块压缩后的尺寸反而比原始数据还大，SquashFS 会直接存储原始未压缩数据。这确保了块在磁盘上的大小永远不会超过输入块大小——一个务实且必要的选择。

### 元数据块：8KB 的固定帧

与数据块不同，元数据（inode、目录列表等）被当作一个连续的流来处理，每 8KB 切割成一个元数据块并独立压缩。输入大小固定为 8KB，与数据块大小无关。

元数据块有一个特殊前缀：一个 16 位无符号整数，存储该块的磁盘大小，最高位表示是否未压缩。读取时需要先读这个 16 位头，解压后的大小永远不会超过 8KB。

更值得注意的是，元数据条目**可以跨越块边界**。一个 inode 可能位于元数据块的末尾，部分内容延伸到下一个块的开头。读取时必须将两个块都读入并一起解压——这解释了为什么 SquashFS 实现中元数据引用使用 64 位整数：低 16 位是块内偏移，高 48 位是块的磁盘位置。

## 查找表：常数时间的代价

SquashFS 的查找表（如 fragment table、export table、ID table）存储方式是一个经典的空间换时间设计：

1. 把表分成 8KB 的元数据块，分别压缩存储
2. 额外存储一个 64 位位置列表，记录每个元数据块在磁盘上的位置（不压缩）
3. 通过二分查找定位到正确的元数据块，再在块内计算偏移

计算公式如下：

```
block_count = ceil(table_count * entry_size / 8192)
meta_index = floor(index * entry_size / 8192)
offset = index * entry_size % 8192
```

访问一个表项最多需要一次元数据块读取（最多 8194 字节）。对于 NFS 导出这类需要频繁 inode 查找的场景，这个设计是值得的。

## 超级块：96 字节的枢纽

超级块是 SquashFS 归档的第一个部分，大小固定为 96 字节，包含整个归档的关键信息：

| 字段 | 类型 | 说明 |
|------|------|------|
| magic | u32 | 魔数 `0x73717368`（"hsqs"） |
| inode count | u32 | 归档中的 inode 数量 |
| mod time | u32 | 最后修改时间（UTC 秒数，不计闰秒） |
| block size | u32 | 数据块大小（4096~1048576，2 的幂次） |
| frag count | u32 | fragment 表的条目数 |
| compressor | u16 | 压缩算法 ID（1=GZIP, 2=LZMA, 3=LZO, 4=XZ, 5=LZ4, 6=ZSTD） |
| block log | u16 | block size 的 log₂ 值，用于校验 |
| flags | u16 | 标志位（位 OR） |
| id count | u16 | ID 查找表的条目数 |
| version major | u16 | 主版本号（固定为 4） |
| version minor | u16 | 次版本号（固定为 0） |
| root inode | u64 | 根目录 inode 的引用 |
| bytes used | u64 | 归档使用的字节数 |
| ID table | u64 | ID 表的字节偏移 |
| Xattr table | u64 | 扩展属性表的字节偏移 |
| Inode table | u64 | inode 表的字节偏移 |
| Dir. table | u64 | 目录表的字节偏移 |
| Frag table | u64 | fragment 表的字节偏移 |
| Export table | u64 | export 表的字节偏移 |

这里有一个值得玩味的细节：mod time 字段是**无符号的**，这意味着它会在 2106 年过期（而不是 2038 年的有符号 32 位时间）。这是一个有意的设计选择。

### 标志位：看似很多，实则只用一处

flags 字段有十几个标志位，从 inode 未压缩、数据块未压缩、fragment 使用策略，到 NFS 导出支持、扩展属性等。但**唯一被 Linux 内核实际检查的标志是"压缩选项存在"位（0x0400）**。其余标志基本只用于告知编辑工具原始打包设置。

为什么这样设计？因为 Linux 内核的首要任务是正确读取归档，而不是关心它是怎么被创建出来的。

### 压缩选项：格式各异

当 flags 中的 0x0400 位置被设置时，超级块后紧跟一个未压缩的元数据块，内容为压缩选项：

- **GZIP**：压缩级别（1-9）、窗口大小、启用策略
- **XZ**：字典大小、CPU 特定过滤器
- **LZ4**：版本号和 HC 模式标志
- **ZSTD**：压缩级别
- **LZO**：算法变体和压缩级别
- **LZMA v1**：不支持压缩选项，此部分必须不存在

这里有个特殊规则：LZ4 压缩选项**必须**存在，即使使用默认值也不例外。这与其他压缩器的可选选项形成鲜明对比。

## 支持的压缩算法

SquashFS 是一个有意思的设计例子：它只允许使用**单一压缩器**，同时应用于数据块和元数据块。不支持数据用 zstd、元数据用 gzip 这样的混合策略。

各算法的现状：

- **gzip (zlib)**：最通用，raw zlib 流（不是 gzip 格式）
- **lzo**：速度优先
- **lzma 1 (LZMA)**：已废弃
- **xz (LZMA v2)**：高压缩率，但只能使用 CRC32 校验
- **lz4**：平衡方案，选项必须有
- **zstd**：最先进但需要权衡

有一点值得注意：XZ 压缩器在设置高压缩级别时，会大幅增加解码器的内存消耗。如果 writer 端调高了级别，decoder 端无感知——这在资源受限的嵌入式场景中是一个潜在问题。

## 示例程序
现在通过命令来初步了解什么是squashfs文件系统，unsquashfs自带一个解析命令如下
```
# unsquashfs -s filesystem.squashfs
Found a valid SQUASHFS 4:0 superblock on filesystem.squashfs.
Creation or last append time Fri Jun  5 08:36:30 2026
Filesystem size 532054402 bytes (519584.38 Kbytes / 507.41 Mbytes)
Compression gzip
Block size 131072
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Uids/Gids (Id table) are compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are compressed
Duplicates are removed
Number of fragments 2
Number of inodes 199
Number of ids 1
Number of xattr ids 0
```
可以看到这里提取了文件系统的关键信息，我们再进一步细拆
```
# hexdump -C -n 96 filesystem.squashfs
00000000  68 73 71 73 c7 00 00 00  0e 1a 22 6a 00 00 02 00  |hsqs......"j....|
00000010  02 00 00 00 01 00 11 00  c0 00 01 00 04 00 00 00  |................|
00000020  48 1f 7d 23 00 00 00 00  82 81 b6 1f 00 00 00 00  |H.}#............|
00000030  7a 81 b6 1f 00 00 00 00  ff ff ff ff ff ff ff ff  |z...............|
00000040  1e 3d b6 1f 00 00 00 00  63 72 b6 1f 00 00 00 00  |.=......cr......|
00000050  81 7f b6 1f 00 00 00 00  6c 81 b6 1f 00 00 00 00  |........l.......|
00000060
```
我们逐步看看这些信息的拆解
1. Magic： 68 73 71 73： hsqs  
2. Inode： c7： 199  
3. 时间戳： 0e 1a 22 6a： 2026-06-05 08:36:30
4. BlockSize： 00 00 02 00： 128KB 
5. Fragment: 02 00 00 00： 2 个
6. 压缩算法： 01 00： 0x0001：GZIP just zlib streams (no gzip headers!)
7. Block log： 11 00： 17
8. Flags： c0 00： 去重 + 支持 NFS 导出
9. ID count： 01 00： 1
10. Version： 04 00 00 00： V4
11. 根目录 inode 引用： 48 1f 7d 23 00 00 00 00： 高 48 位：元数据块的起始位置，低 16 位：该块内的偏移量
12. 总大小：82 81 b6 1f 00 00 00 00： 532054402 字节
13. ID table： 7a 81 b6 1f 00 00 00 00： UID/GID 查找表
14. Xattr table： ff ff ff ff ff ff ff ff： mkfs的时候没设置
15. Inode table： 1e 3d b6 1f 00 00 00 00： Inode 元数据表
16. Directory table： 63 72 b6 1f 00 00 00 00： 目录表
17. Fragment table： 81 7f b6 1f 00 00 00 00： 段表
18. Export table： 6c 81 b6 1f 00 00 00 00： NFS Export 表

我们知道这些表都是8K的大小，所以拿到上面的table的offset，直接查找8K的内容即可
```
hexdump -C -s $INODE_START -n 8192 filesystem.squashfs 
```
这里INODE_START就是表的offset值


## 总结

1. SquashFS 是一个面向快速随机访问优化的高压缩只读文件系统，同时支持作为通用压缩存档格式使用
2. 归档由最多九个部分有序组成，超级块（96 字节）是整个系统的枢纽
3. 文件数据按固定块大小分割压缩，尾部可打包成 fragment block 以提高压缩率
4. 元数据使用固定的 8KB 元数据块，条目允许跨块边界是 SquashFS 的独特设计
5. 查找表通过位置列表加元数据块的方式实现常数时间访问
6. 支持六种压缩算法（gzip、lzo、xz、lz4、zstd、废弃的 lzma v1），但同一归档只能使用一种
7. 超级块的 flags 字段看似复杂，但 Linux 内核只检查"压缩选项存在"标志
8. 魔数 `0x73717368`（"hsqs"）、主版本号 4、次版本号 0 是 SquashFS 格式的硬编码常量
9. 时间戳使用无符号 32 位整数，过期时间为 2106 年而非 2038 年


只读文件系统：squashfs(1)：简介

## 前言

一个软件系统从交付第一天起，就开始走向老化。

起初，新功能像泉水一样涌出，迭代速度飞快。但不知从哪个节点开始，每加一个功能都像在伤口上撒盐——解决一个问题，却由此生出好几个新问题。代码散发着臭味，团队士气低沉，仿佛没有人愿意再碰这个系统。

这就是架构老化的开始。但它并非不可逆转。

所以我们最终的一个文章就是从思维上要意识到，架构也会老化。

## 架构为什么会老化

架构老化的根源，在于功能代码逸出框架的范围之外。

当我们不断给系统添加新功能时，需求的实现方式往往不在当初框架设定的范围之内。于是，代码像藤蔓一样攀附在核心系统的各个角落，把原本清晰的结构绞得支离破碎。

这是理想与现实之间的鸿沟。如果从第一天起就能坚持"最小化的核心系统 + 多个相互正交的周边系统"这个指导思想，代码老化确实很难发生。但现实有太多干扰因素：

- **工程师技术能力不足**：以功能完成为先，不考虑长期维护成本
- **缺乏架构评审环节**：代码质量缺乏持续有效的关注
- **需求理解不深刻**：最初的设计无法满足迭代发展的需要
- **架构迭代不及时**：大量因赶时间而诞生的补丁式代码

代码老化的标志是什么？添加功能越来越难，迭代效率越来越低。这是每个架构师都不愿面对却迟早要面对的局面。

## 老系统添加新功能的正确姿势

先说添加新功能。重构毕竟是系统性工程，而日常工作中更多的还是持续迭代。

当你加入一个已有大量历史代码沉淀的项目时，通常应该把自己要添加的功能定位为周边功能。第一个想法是"少给核心系统添加麻烦，能少改就少改"——这还不够。

实际上，当你把视角放在周边系统时，它本身也应该被视为一个独立的业务系统。这样一想，要求就变了：新功能的代码要与既有系统解耦，能够不依赖就尽量不依赖。

这个"不依赖"是有讲究的。不依赖核心的含义是**业务不依赖**。新功能的绝大部分代码独立于既有业务系统，只有少量桥接代码是耦合的。

对于任何被正交分解的周边系统 B 与核心系统 A，理想情况最终得到的是三个模块：A、B（与 A 无关部分）、A 与 B 的桥接代码（与 A 相关的部分）。虽然归属上 A 与 B 桥接代码通常放到 B 模块，但它应该尽可能小，且尽可能独立于与核心系统无关的代码。

理解这一点至关重要。只有这样，今天开发新功能的投入产出才能最大程度保留。未来万一需要做重构，重构成本也能够最小化。

举一个做办公软件时的例子。既有代码有几百万行，我第一个做的读盘存盘之外的新功能是电子表格的智能填充。用户选择一个区域，移动鼠标到右下角，鼠标变成十字时按住左键不放并移动鼠标来自动填充单元格内容。填充方向上下左右都可以。

做法是：首先实现一个纯算法的模块，输入一个值矩阵和要预测的序列个数，输出预测的值矩阵。填充方向在这里消失了，因为按填充方向构建值矩阵，而不是用户屏幕上直观的矩阵。

然后抽象核心系统的两个接口：取一个区域的单元格数据（包括值和格式）、设置一个单元格的值和格式。基于这个抽象接口，实现完整的自动填充逻辑。最后用最少量的对接代码把它与既有业务系统串起来。

这就是做新功能的正确思路：尽可能与既有系统剥离，从独立业务视角实现，抽象对环境的依赖。

## 局部调整：日拱一卒的智慧

聊完添加新功能，我们谈谈局部调整。它的目标是优化某个功能与核心系统的耦合关系。

局部调整看似收效甚微，但它的好处是可以快速推动。日拱一卒，坚持下来最后的效果远比想象的好。

局部调整有两种常见做法。

**第一种是重写，或者叫局部重构。** 从系统中彻底移除与该功能相关的代码，重新写一份新的。这和开发一个新功能没什么两样，最多看看被移除的代码里有哪些函数设计比较合理可以直接拿过来用。

但不能太热衷于做局部重构。它一定要发生在你对这块代码的业务比较了解的情形——比如你已经维护过它一阵子了。更重要的是，一定要把老代码清理干净，不要残留不必要的代码在系统里。

**第二种是依赖优化。** 它关注的重心不是某项功能本身的实现，而是它与系统之间的关系。

依赖优化整体上做的是代码的搬运工。怎么搬？和删除代码类似，要找到和该功能相关的所有代码。但我们做的不是删除，而是将散落在系统中的代码集中起来。把对系统的每处修改变成一个函数，比如叫 `doXXX_yyyy`。这里 XXX 是功能代号，yyyy 依据这段代码的语义命名。

这个名字看起来很丑，但某种程度上是故意的。它代表团队的约定俗成：此处待重新考虑边界。

它不是说需要重新思考正在做代码优化的功能边界，而是说要重新考虑核心系统的边界。如果某个地方有好几个功能都加了 `doXXX_yyyy` 这样的调用，就意味着这里需要提供一个事件机制，以便这些功能能够监听。而一旦做了这件事，核心系统就变得更稳定了，不再需要因为添加功能而修改代码。这不正是开闭原则（OCP）所追求的么？

依赖优化之后，有多少个 `doXXX_yyyy`，就有多少对系统的伤害值。如果伤害值不大，代表耦合在合理范围，暂时不再往下走是可接受的。如果耦合过多，那就需要考虑推动局部重构了。

所以，**局部重构不应该很盲目，而应依赖于基于"伤害值"的客观判断**。

依赖优化的好处很明显：工作量小，做的是代码搬运不改变任何业务逻辑；可以不必深入功能细节，只需要找到该功能的所有相关代码然后集中起来。把非核心功能都基于依赖优化的方式独立出去，核心系统与周边系统的耦合就理清楚了。

## 核心系统重构：最难的攻坚战

完成这些局部改善，下一步就是核心系统重构。

对于一个积弊已久的系统，要成功完成整体重构是非常艰难的。一上来就重构核心系统，风险太高：牵一发而动全身，无法保证交付周期；没有谁对全局有足够了解，重构会过于盲目。

确定要对核心系统进行重构，最高优先级是确定它的边界，也就是使用界面（接口）。

周边系统对核心系统的依赖有两类：一是核心系统提供的功能，表现为系统调用接口；二是核心系统提供的事件，让周边系统能够介入它的业务流程。对所有周边模块进行依赖优化的整理，细加分析后可以初步确定核心系统需要暴露的事件集合。

进一步要做的是把核心系统的系统调用接口也抽象出来。这一步比较复杂，包含两件事：

* 让周边系统对它的依赖，变成依赖接口而非依赖实现
* 审视核心系统系统调用接口的合理性，明确出期望的接口设计

可以分步骤做。可以先做实现依赖到接口依赖的转变——把周边模块独立出去，将它与核心系统的依赖关系全部调整为接口。这样，不管抽离出来的系统调用接口是否合理，至少它代表了当前系统的模块边界。这一步做完，理论上模拟一个核心系统出来与周边系统对接也可行。

接下来，就是最重要的时刻：对核心系统的接口进行重新设计。

这一步的难点在于两点。第一，我们对业务的理解有了长足进步，抽象的业务接口有了更精炼符合业务本质的表达方式——而不是换汤不换药，否则就要质疑这次重构的必要性。第二，对周边系统切换到新接口的成本要有充足预计。虽然理论上让核心系统维护两套系统调用接口同时存在是可行的，但过渡期不能太长，否则容易让人困惑。

完成了接口改造，剩下来就简单了。核心系统与每一个周边系统彼此完全独立，可以单独调整和优化。嫌当前的核心系统太糟糕？那就重新搞。

为什么可以这么轻松决策？因为就算要重新写核心系统，要做的事情也很收敛，不会影响大局。

这与那些边界不清的业务系统截然不同——边界不清的系统要改核心系统的代码，不要命了么？

## 示例程序

架构老化的过程，可以用量化的方式理解。以下 Python 代码模拟一个简化系统，展示代码耦合如何逐步积累，以及依赖优化如何识别出需要重构的区域。

## 总结

- 架构老化的根源是功能代码逸出框架范围，散落在核心系统各处，导致结构被绞碎。
- 架构老化的标志：添加功能越来越难，迭代效率越来越低。
- 添加新功能时，把自己定位为周边功能，从独立业务视角实现，抽象对环境的依赖，最少量对接代码串起系统。
- 局部调整有两种做法：局部重构（适合对业务了解较深的情形）和依赖优化（做代码搬运，不改变业务逻辑）。
- 依赖优化中发现多个 `doXXX_yyyy` 聚集之处，意味着需要事件机制，这是核心系统走向稳定的关键一步。
- 局部重构不应盲目，应基于"伤害值"的客观判断来决策。
- 核心系统重构的最高优先级是确定边界（接口），周边系统对核心的依赖无非是 DOM 接口和事件两类。
- 核心系统重构分步走：先做实现依赖到接口依赖的转变，再重新设计核心系统接口，最后每个周边系统彼此完全独立。
- 重构比全新业务的架构过程更难，它包含了架构设计、资源规划与调度、阶段规划以及持久战韧性的全方位挑战。

## 参考资料

- 软件架构基础


架构34-终篇：架构思维：认识老化

## 前言

开闭原则最早由勃兰特·梅耶在 1988 年提出时，很多人都以为这只是面向对象编程（OOP）领域的设计原则。但当你真正看清 CPU 的设计哲学，就会发现它与面向对象毫无关系——它是一切信息技术架构的根基。

## 开闭原则的本源

开闭原则的核心定义只有一句话：**软件实体应该对功能扩展开放，但对修改封闭**。

这句话听起来简单，但它的含义远比字面深远。一个软件产品在其生命周期内会不断发生变化。我们不能让代码随着需求变更是非曲直，而是要让软件具备适应变化的能力。变化的应对之道是扩展，而非修改。

为什么这条原则重要？因为它背后藏着一套完整的架构哲学。

开闭原则认为，模块的业务范畴变更需要极其谨慎。一个模块可以修复缺陷（Bug），但不应该被随意调整功能边界。增加功能或减少功能都是需要经过充分推敲的决策。这意味着，模块的业务是"只读"的——如果业务变了，不如将旧模块归档，重新实现一个新模块。

这就是开闭原则鼓励的"只读"业务模块思想。一旦设计完成，业务模块就不应再被修改。如果要改变业务范畴，就废弃它，转而实现新的业务模块。

这种思想我们其实不陌生。Git 的版本管理、容器的服务治理，都是通过"只读"设计来降低系统治理的复杂度。架构设计同样如此：每一次正交的架构分解都在沉淀可复用的业务模块。随着时间推移，组装复杂业务系统将变得越来越简单。

所以，开闭原则是架构治理的根本哲学，而不仅仅是编码规范。

## CPU 背后的架构思维

有一种广泛的误解认为开闭原则是面向对象的专属产物。这个误解把一条无比普世的原则窄化了。

早在面向对象概念出现之前，开闭原则的思想就已经在信息科技中无处不在。让我们看看 CPU 的设计。

在"大厦基石：无生有，有生万物"一讲中，我们讨论过冯·诺依曼体系的核心洞察：**需求的稳定点往往是系统的核心价值点，而需求的变化点则需要做开放性设计**。CPU 的设计完美印证了这一点。

**指令是稳定的，但指令序列是变化的。** 正是这种设计，让计算机得以实现"解决一切可以用'计算'来解决问题"的目标。无论软件多么复杂，CPU 永远只需要支持那一套稳定的指令集。

**计算是稳定的，但数据交换是多变的。** 正是因为这一点，计算机不必修改基础架构，却能适应不断发展变化的交互技术革命——从磁带，到硬盘，到 SSD，到网络存储，CPU 从不需要改变。

体会一下：我们怎么做到支持多变的指令序列的？由此发明了软件。我们怎么做到支持多变的输入输出设备的？我们定义了输入输出规范。

换句话说，我们不必修改 CPU，却因此支持了如此多姿多彩的信息世界。这种优雅的设计与面向对象无关，完全是开闭原则带来的威力。

CPU 的优雅远不止于此。在"软件运行机制及内存管理"一讲中，我们介绍了虚拟内存和缺页中断机制。CPU 通过引入缺页中断，将自身与多变的外部存储设备、多变的文件系统格式完全解耦。中断机制本质上是 CPU 引入的回调函数，通过它，CPU 把对计算机外设的演进能力交给了操作系统。这同样是开闭原则的鲜活案例。

## 插件机制：让软件拥抱变化

开闭原则关注的是模块，而不是最终的软件产品。那么，如果软件本身需要适应需求变化，该怎么办？

答案是插件机制。

常规的插件以动态库（dll/so）形式存在，这是操作系统层面引入的机制，可以跨语言使用。部分语言有自己的插件机制，它提供了完整的二次开发能力，这些接口构成了软件的插件机制，最终让软件成为一个生态型软件。

提供插件机制的二次开发接口通常包含三个部分。

**第一，软件自身能力的暴露。** 也就是 DOM API，插件借此调用软件已实现的功能。这是基础，不再展开。

**第二，插件加载机制。** 通常基于文件系统——规定所有插件放到某个目录下。Windows 平台额外支持将插件信息写入注册表。

**第三，事件监听。** 这是关键，也是难点所在。没有事件，插件就没有机会介入业务。那么应该提供什么样的事件？这非常依赖架构能力。在提供能力相同的情况下，事件越少越好。但怎么做到少而精？

事件通常分三类：

- **界面操作类**：最原始的是鼠标和键盘操作，但它们太过底层，提供出去是双刃剑。更常见的是暴露更高级的界面事件，如菜单项或按钮的点击。
- **数据变更类**：在数据发生变化时允许捕获并响应。最典型的是 onSelectionChanged，基本上所有软件二次开发接口都会提供。
- **业务流程类**：发生在业务流的中间环节或完成之后。比如 Office 软件，打开文件前后都可能发出事件，以便插件介入。

但完整的插件机制并非总是必要的。以 Python 的 Pillow 库（PIL 的现代分支）为例，它提供的 Image.open() 函数天然支持插件式的格式扩展，我们可以增加新的格式支持，无需修改 Pillow 的核心代码。实现方式极为简单：

```
from PIL import Image

# 只需要导入对应的插件模块，注册机制通常在模块内部自动完成
# 假设我们要支持某种特殊的 WebP 或 自定义格式
import pillow_avif  # 第三方插件，自动注册 AVIF 格式支持

# 核心代码无需任何改动，即可识别并打开新格式
img = Image.open("example.avif")
```
这段代码利用了 Python 动态导入的特性，为 Image 类加载了新的格式解码器。这里最大的简化是放弃了复杂的插件加载器——由 Python 的 import 机制和模块的 __init__.py 自动完成注册。

插件机制让核心系统与周边系统的耦合度大大降低。但它并非没有成本。插件机制本身也是核心系统的功能，也需要考虑与其他功能的耦合度。如果一个插件机制没有多少客户——没有几个功能依赖它开发，而它本身的代码散落在核心系统的各个角落——投入产出比就不划算。

所以，**维持足够的通用性，是提供插件机制的重大前提。**

## 单一职责原则与开闭原则的互补

总结开闭原则，其实就两点：

**第一，模块的业务要稳定。** 业务范畴遵循"只读"设计，如果需要变化就归档旧模块，转而实现新模块。这是架构治理的基础哲学。

**第二，模块的业务变化点，简单一点的通过回调函数或接口开放出去，交给其他业务模块；复杂一点的通过引入插件机制，把系统分解为"最小化的核心系统 + 多个彼此正交的周边系统"。** 回调函数或接口本质上就是一种事件监听机制，所以它们是插件机制的特例。

这让我们联想到另一个常见原则——单一职责原则（Single Responsibility Principle，SRP）。它强调每个模块只负责一个业务，而不是同时干多个业务。开闭原则强调的是把模块业务的变化点抽离出来，包给其他模块。

它们谈的是同一个问题的两个面：**SRP 保障模块的业务边界清晰，OCP 保障模块的业务变化点被优雅地对外暴露**。两者相辅相成，缺一不可。

## 示例程序

开闭原则在日常开发中最常见的应用，就是插件机制的实现。下面用 Python 模拟一个简化版的图片解码插件系统，演示如何通过插件机制在不修改核心代码的情况下扩展功能。

```python
#!/usr/bin/env python3
"""
plugin_system.py - 开闭原则的插件机制演示

核心系统（ImageCodec）只定义接口，具体的 codec 实现以插件形式加载。
新增格式支持只需添加新插件，无需修改核心代码。
"""

from typing import Protocol, Iterator
import sys


class ImagePlugin(Protocol):
    """插件协议：所有图片解码插件必须实现 decode 方法"""
    def decode(self, data: bytes) -> str:
        """解码图片数据，返回描述信息"""
        ...

    def format_name(self) -> str:
        """返回支持的格式名称"""
        ...


class ImageCodec:
    """
    核心系统：图片编解码器
    遵循开闭原则，自身代码不变，通过插件扩展功能
    """
    def __init__(self):
        self._plugins: dict[str, ImagePlugin] = {}

    def register(self, plugin: ImagePlugin) -> None:
        """注册插件——扩展行为而非修改核心代码"""
        name = plugin.format_name()
        self._plugins[name] = plugin
        print(f"[核心系统] 注册插件: {name}")

    def decode(self, data: bytes, format_hint: str = "") -> str:
        """解码图片，支持自动探测格式或使用格式提示"""
        if not format_hint:
            format_hint = self._detect_format(data)

        plugin = self._plugins.get(format_hint)
        if not plugin:
            available = ", ".join(self._plugins.keys()) or "无"
            raise ValueError(f"不支持的格式: {format_hint}，可用格式: {available}")

        return plugin.decode(data)

    def _detect_format(self, data: bytes) -> str:
        """模拟格式探测：从数据头识别格式"""
        if data.startswith(b'\xff\xd8'):
            return "jpeg"
        elif data.startswith(b'\x89PNG'):
            return "png"
        elif data.startswith(b'GIF'):
            return "gif"
        return "unknown"

    def supported_formats(self) -> Iterator[str]:
        """返回当前已注册的格式列表"""
        return iter(self._plugins.keys())


# ═══════════════════════════════════════════════════════════════
# 插件实现（可独立扩展，无需修改核心系统）
# ═══════════════════════════════════════════════════════════════

class JpegPlugin:
    """JPEG 格式插件"""
    def format_name(self) -> str:
        return "jpeg"

    def decode(self, data: bytes) -> str:
        size = len(data)
        return f"JPEG 图片，解码后约 {size} 字节"


class PngPlugin:
    """PNG 格式插件"""
    def format_name(self) -> str:
        return "png"

    def decode(self, data: bytes) -> str:
        size = len(data)
        return f"PNG 图片，解码后约 {size} 字节"


class GifPlugin:
    """GIF 格式插件"""
    def format_name(self) -> str:
        return "gif"

    def decode(self, data: bytes) -> str:
        size = len(data)
        return f"GIF 图片，解码后约 {size} 字节"


# ═══════════════════════════════════════════════════════════════
# 新增插件（未来扩展，无需修改 ImageCodec）
# ═══════════════════════════════════════════════════════════════

class WebpPlugin:
    """未来扩展：WebP 格式插件（如果未来需要支持）"""
    def format_name(self) -> str:
        return "webp"

    def decode(self, data: bytes) -> str:
        size = len(data)
        return f"WebP 图片，解码后约 {size} 字节"


def main():
    # 模拟图片数据（带格式签名）
    jpeg_data = b'\xff\xd8\xff\xe0Jpeg解码器模拟数据'
    png_data = b'\x89PNG\r\n\x1a\nPNG解码器模拟数据'
    gif_data = b'GIF89aGIF解码器模拟数据'
    webp_data = b'RIFFxxxxWEBP解码器模拟数据'

    # 初始化核心系统
    codec = ImageCodec()

    # 初始只注册 JPEG 和 PNG 插件
    print("阶段1：核心系统仅加载 JPEG、PNG 插件")
    codec.register(JpegPlugin())
    codec.register(PngPlugin())

    print(f"可用格式: {', '.join(codec.supported_formats())}")
    print()

    # 使用已注册插件解码
    print("阶段2：解码已注册格式")
    print(f"  JPEG: {codec.decode(jpeg_data)}")
    print(f"  PNG:  {codec.decode(png_data)}")
    print()

    # 解码未注册格式（GIF 尚未注册）
    print("阶段3：尝试解码未注册格式（GIF）")
    try:
        result = codec.decode(gif_data)
        print(f"  结果: {result}")
    except ValueError as e:
        print(f"  预期行为: {e}")
    print()

    # 未来扩展：注册 WebP 插件（无需修改 ImageCodec）
    print("阶段4：未来扩展——注册 WebP 插件")
    codec.register(WebpPlugin())
    print(f"  可用格式: {', '.join(codec.supported_formats())}")
    print()

    print("开闭原则体现：")
    print("  1. 核心系统 ImageCodec 业务只读，代码从不修改")
    print("  2. 新增格式支持只需注册新插件，插件之间正交无耦合")
    print("  3. 插件注册行为（事件监听）是插件机制的特例")


if __name__ == "__main__":
    main()
```

运行效果：

```bash
$ python3 plugin_system.py
阶段1：核心系统仅加载 JPEG、PNG 插件
[核心系统] 注册插件: jpeg
[核心系统] 注册插件: png
可用格式: jpeg, png

阶段2：解码已注册格式
  JPEG: JPEG 图片，解码后约 25 字节
  PNG:  PNG 图片，解码后约 21 字节

阶段3：尝试解码未注册格式（GIF）
  预期行为: 不支持的格式: gif，可用格式: jpeg, png

阶段4：未来扩展——注册 WebP 插件
[核心系统] 注册插件: webp
  可用格式: jpeg, png, webp

开闭原则体现：
  1. 核心系统 ImageCodec 业务只读，代码从不修改
  2. 新增格式支持只需注册新插件，插件之间正交无耦合
  3. 插件注册行为（事件监听）是插件机制的特例
```

代码解读：核心系统 `ImageCodec` 遵循开闭原则——业务只读，代码从不修改。通过 `register()` 方法注册插件来扩展功能，而不是修改核心代码。GIF 格式从未注册，所以解码时抛出异常；未来只需新增 `GifPlugin` 并注册，无需触动 `ImageCodec` 一行代码。这就是插件机制对开闭原则的实践。

## 总结

- 开闭原则（OCP）的核心是：软件实体对扩展开放，对修改封闭，通过扩展而非修改来适应需求变化。
- OCP 背后的架构哲学是模块业务的"只读"设计——业务范畴一经确定就不应随意调整，要变就建新模块。
- "只读"思想贯穿整个信息技术领域：Git 版本管理、容器服务治理、以及 CPU 的指令集设计，都体现了这一哲学。
- CPU 的设计完美诠释了 OCP：指令稳定但序列变化，计算稳定但数据交换多变，无需修改基础架构即可适应变化。
- 插件机制是应对复杂变化的手段，包含三个部分：能力暴露（DOM API）、插件加载机制、事件监听。
- 事件监听分三类：界面操作类、数据变更类、业务流程类。回调函数和接口本质上是事件监听的特例。
- 插件机制需要维持足够的通用性才有价值——如果投入产出不成比例，就不值得做。
- 单一职责原则（SRP）与开闭原则（OCP）互补：SRP 保障模块业务边界清晰，OCP 保障变化点被优雅暴露。
- 基础架构 + 业务架构，才是软件设计的全部。作为架构师，不能只关注业务架构而忽视基础架构的选择。

## 参考资料

- 软件架构基础
