简单几行介绍你自己：在做什么、擅长什么、这个站会写什么。
]]>品牌名、导航、logo 都是占位，随时在
src/.vuepress/下改。
简单几行介绍你自己：在做什么、擅长什么、这个站会写什么。
]]>品牌名、导航、logo 都是占位，随时在
src/.vuepress/下改。
内容整理中。
待补充。
待补充。
待补充。
待补充。
]]>内容整理中。
待补充。
待补充。
待补充。
待补充。
]]>内容整理中。后续把 workflows / agents / templates / standards 搬进来。
待补充。
]]>内容整理中。后续把 workflows / agents / templates / standards 搬进来。
待补充。
待补充。
]]>完整归档见 文章索引。
]]>完整归档见 文章索引。
]]>共 25 篇。
共 25 篇。
共 17 篇。
共 18 篇。
共 29 篇。
共 22 篇。
共 22 篇。
共 11 篇。
共 25 篇。
共 22 篇。
内容整理中，按 计算机基础 / 产品 / UI / 架构 / 前端 / 后端 / 测试 / 运维 / AI 分类填充。
待补充。
待补充。
待补充。
待补充。
待补充。
待补充。
待补充。
]]>内容整理中，按 计算机基础 / 产品 / UI / 架构 / 前端 / 后端 / 测试 / 运维 / AI 分类填充。
待补充。
待补充。
待补充。
待补充。
待补充。
待补充。
待补充。
待补充。
待补充。
]]>记录比记忆靠谱。脑子会忘，仓库不会。
全栈、系统设计、云原生运维、AI 工程。不搬运那 191 篇旧笔记，这里是新的内容线。
本地写 Markdown → git push → Cloudflare 自动构建。不需要登录任何后台。
记录比记忆靠谱。脑子会忘，仓库不会。
全栈、系统设计、云原生运维、AI 工程。不搬运那 191 篇旧笔记，这里是新的内容线。
本地写 Markdown → git push → Cloudflare 自动构建。不需要登录任何后台。
一次请求链路的梳理。从客户端到数据库，每一步都值得记一笔。
网关做鉴权与限流，服务无状态，缓存挡读。细节以后慢慢补。
]]>一次请求链路的梳理。从客户端到数据库，每一步都值得记一笔。
网关做鉴权与限流，服务无状态，缓存挡读。细节以后慢慢补。
]]>数据结构（Data Structure）是 存储、组织和管理数据的方式，它不仅决定了数据的存储形式，也影响数据访问和操作的效率。
考试中涉及的数据结构可以分为以下几种：
线性结构
（元素之间有顺序关系）
树形结构
（元素之间有层级关系）
图结构
（元素之间有网络关系）
散列表（Hash Table）
数据结构（Data Structure）是 存储、组织和管理数据的方式，它不仅决定了数据的存储形式，也影响数据访问和操作的效率。
考试中涉及的数据结构可以分为以下几种：
线性结构
（元素之间有顺序关系）
树形结构
（元素之间有层级关系）
图结构
（元素之间有网络关系）
散列表（Hash Table）
算法（Algorithm）是 解决问题的一系列步骤或方法，用来操作数据结构，实现具体功能。
数据结构和算法的关系
]]>💡 举例：
- 用数组实现栈 → 可以快速访问栈顶
- 用链表实现队列 → 插入删除都很快
- 用堆实现优先队列 → 可以快速找最大/最小值
- 用图 + BFS → 可以找最短路径
线性表（Linear List）是 L 数据结构 中的一种基本结构。它是 零个或多个数据元素的有限序列。通常，线性表 中的 数据元素 之间是 有序的，它们之间存在着 前驱和后继的关系。
特点：
线性表（Linear List）是 L 数据结构 中的一种基本结构。它是 零个或多个数据元素的有限序列。通常，线性表 中的 数据元素 之间是 有序的，它们之间存在着 前驱和后继的关系。
特点：
线性表分为顺序存储结构（又称 顺序表）和链式存储结构（又称为 链表）。
顺序表中的元素存储地址是 连续的（存储在栈中），而链表的元素存储地址是 非连续的（存储在堆中），元素节点中除了存储数据元素之外还存储相邻元素的地址信息。顺序表中数据之间的 逻辑关系 和 物理关系 是一致的，链表中数据元素的逻辑关系和物理关系并不一定一致。
上图中左边为顺序表，右边为链表。顺序表在内存中的地址是连续的，各个元素的下标之间是有规律可循的，通过一个已知下标的元素可以找到顺序表中任意一个其它元素。但是链式表中的元素在内存中的地址是不连续的，所以链式表中的每个元素除了要保存数据信息外，还要保存下一个元素的内存地址，以便形成线性关系。
线性表中的操作包含以下类型，顺序表 和 链表 会各自使用不同的方案实现这些操作：
InitList): 创建一个 空的线性表。Insert): 在线性表的 指定位置 插入一个 新的元素。Delete): 删除线性表中的 指定位置的元素。LocateElem): 根据 给定的条件 查找线性表中的 元素。GetElem): 获取线性表中 指定位置的元素。SetElem): 修改线性表中 指定位置的元素 的 值。Length): 返回线性表中的 元素数量。IsEmpty): 判断线性表是否 为空。ClearList): 清除线性表中的 所有元素。Traverse): 对线性表中的 每个元素 执行 某种操作。栈 是一个元素的集合，加入元素的操作叫做 “压栈”（push），而移除元素的操作叫做 “出栈”（pop）。它遵循 后进先出（LIFO, Last In First Out） 的原则。这意味着最后被压入栈的元素是第一个被弹出的元素。
push(element): 将元素添加到 栈 的顶部。pop(): 移除并返回 栈顶 的元素。如果 栈 为空，这个操作可能会抛出一个错误或返回特定的值（例如 null 或 undefined），具体取决于实现。peek() 或 top(): 返回 栈顶 的元素但不移除它。这只是一个查看操作，栈 的内容不会改变。如果 栈 为空，这个操作可能会抛出一个错误或返回特定的值。isEmpty(): 判断 栈 是否为空。如果 栈 为空，返回 true；否则返回 false。size() 或 length(): 返回 栈 中元素的数量。栈 是一个元素的集合，加入元素的操作叫做 “压栈”（push），而移除元素的操作叫做 “出栈”（pop）。它遵循 后进先出（LIFO, Last In First Out） 的原则。这意味着最后被压入栈的元素是第一个被弹出的元素。
push(element): 将元素添加到 栈 的顶部。pop(): 移除并返回 栈顶 的元素。如果 栈 为空，这个操作可能会抛出一个错误或返回特定的值（例如 null 或 undefined），具体取决于实现。peek() 或 top(): 返回 栈顶 的元素但不移除它。这只是一个查看操作，栈 的内容不会改变。如果 栈 为空，这个操作可能会抛出一个错误或返回特定的值。isEmpty(): 判断 栈 是否为空。如果 栈 为空，返回 true；否则返回 false。size() 或 length(): 返回 栈 中元素的数量。栈 的实现方式有两种，顺序栈 和 链式栈。 顺序栈 是在 顺序表 的基础上实现 栈结构， 链式栈 是在 链表 的基础上实现 栈结构。
顺序栈是使用 数组 来实现的 栈，利用数组的索引来模拟 栈 的操作。 与普通的线性表不同，栈 的操作被限制在表的一端进行，这一端被称为 栈顶 (Top)，另一端被称为 栈底 (Bottom)。
顺序栈的关键在于 栈顶指针，栈顶指针是一个整数变量，用于指示 栈顶 元素在 数组 中的位置。其值的变化直接反映了栈中元素的变化。
当 栈空 时，一般将 栈顶指针设置为 1，当 栈满 时，栈顶指针指向 数组 中的最后一个元素。
当元素 入栈 时，将栈顶指针 向后 移动一个位置、然后放置新元素即可。当元素 出栈 时，需要将栈顶指针 向前 移动一个位置。
当然，入栈需要保证栈不满，出栈需要保证栈不空。
// 1.栈的定义
#define MAX_SIZE 100 // 定义栈的最大容量
// 定义顺序栈的结构
typedef struct {
int data[MAX_SIZE]; // 使用数组存储数据
int top; // 栈顶指针
} SeqStack;
// 2.初始化
// 初始化栈
SeqStack* initStack() {
SeqStack* stack = (SeqStack*)malloc(sizeof(SeqStack));
if(!stack) {
printf("Failed to allocate memory for stack\n");
exit(1);
}
// 栈顶指针初始化为 -1，表示栈为空
stack->top = -1;
return stack;
}
// 3.入栈
// 入栈操作
bool push(SeqStack* stack, int value) {
if (isFull(stack)) {
printf("Stack is full!\n");
return false;
}
// 先移动栈顶指针，再存放元素
stack->data[++stack->top] = value;
return true;
}
// 4.出栈
// 出栈操作
bool pop(SeqStack* stack, int* value) {
if (isEmpty(stack)) {
printf("Stack is empty!\n");
return false;
}
// 先取出元素，再移动栈顶指针
*value = stack->data[stack->top--];
return true;
}
// 5.获取栈顶元素
// 获取栈顶元素
bool peek(SeqStack* stack, int* value) {
if (isEmpty(stack)) {
printf("Stack is empty!\n");
return false;
}
*value = stack->data[stack->top];
return true;
}
// 6.判断栈空
// 判断栈是否为空
// 当栈中没有元素时，栈顶指针通常指向一个特殊的位置，例如 -1。
bool isEmpty(SeqStack* stack) {
return stack->top == -1;
}
// 判断栈是否已满
// 当栈顶指针指向数组中的最后一个元素时，说明栈已经满了
bool isFull(SeqStack* stack) {
return stack->top == MAX_SIZE - 1;
}栈的 链式存储结构 利用 单链表 来实现栈的功能。
在 链式栈 实现中，一般 头结点不存放数据，仅作为链表的固定起点。栈顶元素始终为 head->next。这样依然可以保证 入栈 和 出栈 的时间复杂度为 O(1) 。
链式栈具备以下 重要特性：
head 始终存在，不存储实际数据，只作为哨兵节点。head->next。head->next == NULL。head->next 前插入新节点；出栈时删除 head->next。// 1.栈的定义
// 定义链式栈的节点结构
typedef struct Node {
int data;
struct Node* next;
} Node;
// 定义链式栈（带头结点）
typedef struct {
Node* head; // 指向头结点
} LinkedStack;
// 2.初始化
// 初始化栈（带头结点）
LinkedStack* initStack() {
LinkedStack* stack = (LinkedStack*)malloc(sizeof(LinkedStack));
if (!stack) {
printf("Failed to allocate memory for stack\n");
exit(1);
}
stack->head = (Node*)malloc(sizeof(Node)); // 创建头结点
if (!stack->head) {
printf("Failed to allocate memory for head node\n");
exit(1);
}
stack->head->next = NULL; // 初始为空栈
return stack;
}
// 3.入栈
// 入栈操作（头插法）
void push(LinkedStack* stack, int value) {
Node* newNode = (Node*)malloc(sizeof(Node));
if (!newNode) {
printf("Failed to allocate memory for new node\n");
exit(1);
}
newNode->data = value;
newNode->next = stack->head->next;
stack->head->next = newNode;
}
// 4.出栈
// 出栈操作
bool pop(LinkedStack* stack, int* value) {
if (isEmpty(stack)) {
printf("Stack is empty!\n");
return false;
}
Node* topNode = stack->head->next;
*value = topNode->data;
stack->head->next = topNode->next;
free(topNode);
return true;
}
// 5.获取栈顶元素
// 获取栈顶元素
bool peek(LinkedStack* stack, int* value) {
if (isEmpty(stack)) {
printf("Stack is empty!\n");
return false;
}
*value = stack->head->next->data;
return true;
}
// 6.判断栈空
// 判断栈是否为空
bool isEmpty(LinkedStack* stack) {
return stack->head->next == NULL;
}字符串是计算机科学中的一个基本概念，通常被定义为 有限序列 中 字符 的有序集合。
形式定义：
在 定长顺序存储表示 中，每个字符串都有固定的长度，通常用一个预定义的最大大小来表示。这种表示方法使用一个一维数组，数组的大小等于预定的最大长度。
在某些语境中（例如 C 语言），使用特殊字符（如 '\0'）来标识字符串结束。
字符串是计算机科学中的一个基本概念，通常被定义为 有限序列 中 字符 的有序集合。
形式定义：
在 定长顺序存储表示 中，每个字符串都有固定的长度，通常用一个预定义的最大大小来表示。这种表示方法使用一个一维数组，数组的大小等于预定的最大长度。
在某些语境中（例如 C 语言），使用特殊字符（如 '\0'）来标识字符串结束。
#define MAX_SIZE 100 // 预定义的最大大小
typedef struct {
char data[MAX_SIZE]; // 字符数组
int length; // 当前字符串的长度
} FixedString;在 堆分配存储表示 中，每个字符串具有其自己的 长度，因此可以动态地分配存储空间。字符串在堆中分配空间，只需要那么多的空间来存储实际的字符以及结束字符或 长度 信息。
typedef struct {
char *data; // 指向动态分配空间的指针
int length; // 字符串的长度
} HeapString;
// 创建一个新的字符串
void initHeapString(HeapString *s, const char *str) {
s->length = strlen(str);
s->data = (char *)malloc((s->length + 1) * sizeof(char));
if (s->data == NULL) {
exit(1); // 分配失败
}
strcpy(s->data, str);
}
// 释放字符串
void freeHeapString(HeapString *s) {
free(s->data);
s->length = 0;
}块链存储表示 是结合了 链表 与 块 存储的思想。串分为较小的 块，每个块存储一部分 字符。块之间使用 指针 链接。这样，整个字符串就变成了一个字符块的链表。
#define BLOCK_SIZE 4 // 为了简单起见，设块大小为 4
typedef struct StringBlock {
char data[BLOCK_SIZE]; // 块中的字符数据
struct StringBlock *next; // 指向下一个块的指针
} StringBlock;
typedef struct {
StringBlock *head; // 指向第一个块的指针
int length; // 字符串的总长度
} BlockString;
// 初始化块链字符串
void initBlockString(BlockString *s) {
s->head = NULL;
s->length = 0;
}
// 为了简化，这里只展示了数据结构定义和初始化函数。实际应用中还需要考虑其他函数，如插入、删除、销毁等。树的 存储结构 是指在计算机中如何表示和存储树这种数据结构，这里主要了解 双亲表示法、孩子表示法 和 孩子兄弟表示法 即可。
双亲表示法 主要是使用一个数组，其中每个结点都有一个指示其双亲结点在数组中位置的索引。
#define MAXSIZE 100
typedef struct {
int data; // 结点数据
int parent; // 双亲的位置
} PTNode;
typedef struct {
PTNode nodes[MAXSIZE]; // 结点数组
int n; // 结点数
} PTree;孩子表示法 将每个结点的孩子结点排列起来，以单链表作为存储结构。然后再用一个数组与之相配合。
#define MAXSIZE 100
// 孩子结点
typedef struct ChildNode {
int child; // 孩子结点在数组中的位置
struct ChildNode* next; // 下一个孩子
} *ChildPtr;
// 表头结构
typedef struct {
int data; // 结点数据
ChildPtr firstchild; // 第一个孩子的指针
} CTBox;
typedef struct {
CTBox nodes[MAXSIZE]; // 结点数组
int n; // 结点数
} CTree;孩子兄弟表示法 是将树转化为 二叉树 的形式来存储。每个结点有两个指针，一个指向它的第一个孩子，另一个指向它的右兄弟。
typedef struct CSNode {
int data; // 结点数据
struct CSNode* firstchild; // 第一个孩子
struct CSNode* rightsib; // 右兄弟
} CSNode, *CSTree;森林（Forest）是一组互不相交的树的集合。换句话说，森林由若干棵树组成，每棵树都是一个独立的层次结构，且这些树之间没有连接关系。
对于一个给定的树，通常有以下两种遍历方式：
先根遍历
（类似于二叉树的前序遍历）：
后根遍历
（类似于二叉树的后序遍历）：
注意树是没有 中根遍历 的，除非这棵树是二叉树。
// 1.树结点的定义
#define MAXCHILD 20
typedef struct TreeNode {
int value;
int numChildren; // 子结点的数量
struct TreeNode *children[MAXCHILD]; // 子结点指针数组
} TreeNode;
// 2.先根遍历
void preOrderTraversal(TreeNode* root) {
if (root == NULL) {
return;
}
printf("%d ", root->value); // 先访问根结点
// 然后遍历子结点
for (int i = 0; i < root->numChildren; ++i) {
preOrderTraversal(root->children[i]);
}
}
// 3.后根遍历
void postOrderTraversal(TreeNode* root) {
if (root == NULL) {
return;
}
// 先遍历子结点
for (int i = 0; i < root->numChildren; ++i) {
postOrderTraversal(root->children[i]);
}
printf("%d ", root->value); // 再访问根结点
}对于 上图 所示的树：其 先根遍历 为 A, B, E, F, C, D, G，后根遍历 为E, F, B, C, G, D, A。
观察可以得到如下结论：
对于一个给定的森林，遍历方式如下：
对于上图 所示的森林：其先根遍历 为 A, B, C, D, E, F, G, H, I，后根遍历 为 B, C, D, A, F, E, H, I, G，中根遍历 为 B, C, D, A, F, E, H, I, G
观察可以得到如下结论：
图 是由 顶点 和 边 组成的非线性数据结构。顶点 有时也被称为节点，而 边 是连接图中任意两个节点的线或弧。更正式地说，图 是由一组 顶点 (V) 和一组 边 (E) 组成的。图用 G(E,V) 表示。
]]>图 是由 顶点 和 边 组成的非线性数据结构。顶点 有时也被称为节点，而 边 是连接图中任意两个节点的线或弧。更正式地说，图 是由一组 顶点 (V) 和一组 边 (E) 组成的。图用 G(E,V) 表示。
在 图论 中，根据边的方向性、连接方式、顶点间的关系等，可以进一步划分出多种类型的图，并引入如 连通性、完全性、度数 等一系列关键概念。这些分类和术语有助于我们更好地理解 图的结构特点和应用场景，下面我们将逐一进行介绍。
在我们使用数据结构存储 图 时，主要关注两点：1. 如何存储 顶点？2. 如何存储 边？ 采用的数据结构需要能够准备表示这些信息。
图的 邻接矩阵（Adjacency Matrix）是一种常用的图表示方法，特别适用于 稠密图，它以矩阵的形式表示图的连接关系。
在邻接矩阵中，行和列分别代表 图的顶点，矩阵的元素表示顶点之间是否相邻或者 边的权重。
在邻接矩阵的实现中，我们使用一个 二维数组 来表示图的连接关系，邻接矩阵matrix 的行数和列数与图中的顶点数量相同。
其中 matrix[i][j] 表示顶点i 到顶点j 是否有边（或边的权值）。
// 1.领接矩阵定义
#define MAX_VERTICES 100
int adjMatrix[MAX_VERTICES][MAX_VERTICES]; // 邻接矩阵
// 初始化邻接矩阵
void initializeMatrix(int vertices) {
for (int i = 0; i < vertices; i++) {
for (int j = 0; j < vertices; j++) {
adjMatrix[i][j] = 0; // 初始化所有元素为 0
}
}
}
// 2.添加边
// 在邻接矩阵中添加一条边
void addEdge(int start, int end) {
adjMatrix[start][end] = 1; // 添加边，将对应位置的元素设为 1
adjMatrix[end][start] = 1; // 无向图需要将对称位置的元素也设为 1
}如果需要计算 邻接矩阵 中某个 顶点 的 出度 的话，假设 顶点 编号为 i，我们统计 邻接矩阵 中的 第 i 行 有多少元素不为 0 即可（该顶点指向哪些顶点）。
如果需要计算 邻接矩阵 中某个 顶点 的 入度 的话，假设 顶点 编号为 i，我们统计 邻接矩阵 中的 第 i 列 有多少元素不为 0 即可（哪些顶点指向该顶点）。
图的 邻接表（Adjacency List）是一种常见的图表示方法，特别适用于 稀疏图，它使用链表或数组的形式来表示图的连接关系。每个顶点都对应一个链表，链表中存储与该顶点相邻的其他顶点。
邻接表的主要思想是为 每个顶点创建一个链表，链表中的每个节点表示与该顶点相邻的另一个顶点。对于无向图，通常需要为每一条边创建两个链表节点，分别表示两个相邻的顶点。
在邻接表的实现中，我们为每个顶点维护一个链表，用于存储与该顶点相邻的所有顶点；所有顶点对应的 链表头节点 组成一个数组或列表（在以下实现为 struct AdjList *array），形成整个图的邻接表结构。
// 1.数据结构
// 链表节点结构：表示邻接的一个顶点
struct Node {
int dest; // 邻接顶点的编号
struct Node* next; // 指向下一个邻接点
};
// 邻接表：每个顶点有一个链表
struct AdjList {
struct Node* head; // 链表头
};
// 图结构
struct Graph {
int V; // 顶点数
struct AdjList* array; // 邻接表数组
};
// 2.创建新节点
struct Node* newNode(int dest) {
struct Node* node = (struct Node*)malloc(sizeof(struct Node));
node->dest = dest;
node->next = NULL;
return node;
}
// 3.创建图
struct Graph* createGraph(int V) {
struct Graph* graph = (struct Graph*)malloc(sizeof(struct Graph));
graph->V = V;
// 创建邻接表数组
graph->array = (struct AdjList*)malloc(V * sizeof(struct AdjList));
for (int i = 0; i < V; ++i)
graph->array[i].head = NULL;
return graph;
}
// 4.添加边
void addEdge(struct Graph* graph, int src, int dest) {
// src -> dest
struct Node* n1 = newNode(dest);
n1->next = graph->array[src].head;
graph->array[src].head = n1;
// dest -> src（因为是无向图）
struct Node* n2 = newNode(src);
n2->next = graph->array[dest].head;
graph->array[dest].head = n2;
}邻接多重表（Adjacency Multi-list）是一种用于表示 无向图 的数据结构，主要用于避免在 邻接表 存储方式中重复存储 无向边，提高存储效率，同时便于图的操作（如 边 的删除）。
邻接多重表中顶点种类 分为两种：
还是举个实际例子说明，在上述的邻接多重表中，总共需要存储 5 条边，每条边只需要存储一次，所以总共有 5 个边结点，每个边结点中存储的数据如下表所示：
| 边 | ivex | jvex | ilink 指向 | jlink 指向 |
|
顺序查找的 核心思想 是从数组（线性表）的第一个元素开始，逐个检查每个元素是否等于目标值，直到找到目标或检查完整个数组。
其代码实现如下，非常简单，遍历一次数组即可：
int SequentialSearch(int A[], int n, int value) {
for (int i = 0; i < n; i++) {
if (A[i] == value) {
return i; // 找到，返回索引
}
}
return -1; // 未找到
}顺序查找的 核心思想 是从数组（线性表）的第一个元素开始，逐个检查每个元素是否等于目标值，直到找到目标或检查完整个数组。
其代码实现如下，非常简单，遍历一次数组即可：
int SequentialSearch(int A[], int n, int value) {
for (int i = 0; i < n; i++) {
if (A[i] == value) {
return i; // 找到，返回索引
}
}
return -1; // 未找到
}顺序查找的 时间复杂度 如下：
折半查找 要求数组是有序的。
其 核心思想 在于每次将查找范围折半，只保留目标可能存在的一半，直到范围为空或找到目标为止。
例如，在有序数组中查找一个元素时，可以先比较中间元素：
下图给出了一个实例，从数组中折半查找元素 23：
折半查找可以基于 迭代实现，也可以作为一个 递归函数实现：
// 1.迭代版本
int BinarySearch(int A[], int n, int value) {
int low = 0;
int high = n - 1;
while (low <= high) {
int mid = low + (high - low) / 2; // 防止溢出
if (A[mid] == value) {
return mid; // 找到
} else if (A[mid] < value) {
low = mid + 1;
} else {
high = mid - 1;
}
}
return -1; // 未找到
}
// 2.递归版本
int BinarySearchRecursive(int A[], int low, int high, int value) {
if (low > high) {
return -1; // 区间无效，查找失败
}
int mid = low + (high - low) / 2;
if (A[mid] == value) {
return mid; // 找到目标
} else if (A[mid] < value) {
return BinarySearchRecursive(A, mid + 1, high, value); // 查右半部分
} else {
return BinarySearchRecursive(A, low, mid - 1, value); // 查左半部分
}
}折半查找的 时间复杂度 如下：
折半查找判定树（Binary Search Decision Tree）是折半查找（Binary Search）过程的树形表示，用于清晰地 描述在查找过程中所做的每一次比较决策。
所以简单地来说，如何根据一个有序序列得到一个折半查找判定树呢，就是将折半查找的过程走一遍，举两个实际的例子来说明一下：
假设数组为 [10, 20, 30, 40, 50, 60]，元素个数为 6。
🌳 折半查找判定树构造原则
折半查找需要选一个“中点”作为根节点。偶数长度数组有两个中点，一般可以：
mid = (low + high) // 2假设按 常规左中点 来构造，则 构造过程如下：
[10, 20, 30, 40, 50, 60]，mid = 2 → 30 为根；[10, 20]，mid = 0 → 10 为左子树；
[20] → 作为 10 的右子节点；[40, 50, 60]，mid = 4 → 50 为右子树；
[40] → 左子节点；[60] → 右子节点。最后可以得到如下折半查找判定树：
线性表的 分块查找 通常应用于一种特定的情境：线性表（例如数组）被分为多个大小相等（或者最后一个块可能较小）的块，并且块内的元素是无序的，但是块与块之间是有序的。也就是说，每个块内的最大（或最小）元素小于下一个块的任意元素。
常用的 分块查找策略 如下：
排序算法的 稳定性 是指：在排序过程中，如果两个元素的键值相等，排序后它们的 相对顺序保持不变，那么这个排序算法就是 稳定的排序算法。
比如排序前的数组是这样：[... A ... B ...]，并且 A 和 B 的值相同。
如果排序后的数组是这样：[... B A ...]，那么排序算法就是不稳定的，反之排序算法就是 稳定的。
排序算法的 稳定性 是指：在排序过程中，如果两个元素的键值相等，排序后它们的 相对顺序保持不变，那么这个排序算法就是 稳定的排序算法。
比如排序前的数组是这样：[... A ... B ...]，并且 A 和 B 的值相同。
如果排序后的数组是这样：[... B A ...]，那么排序算法就是不稳定的，反之排序算法就是 稳定的。
排序算法中的 元素移动次数，指的是在排序过程中对 数组元素进行位置变换的次数。
下表列出了各排序算法的 元素移动次数：
| 排序算法 | 元素移动次数 | 说明 | |
]]>硬件 系统和 软件 系统共同构成了一个完整的计算机系统。硬件指的是有形的物理设备，是计算机系统中实际物理装置的总称。软件指的是在硬件上运行的程序和相关的数据及文档。
硬件 和 软件 关系：硬件是计算机的物理部分，它提供了运行软件所需的基础设施，而软件则是 指令集，指导 硬件如何工作以执行特定的任务。
]]>硬件 系统和 软件 系统共同构成了一个完整的计算机系统。硬件指的是有形的物理设备，是计算机系统中实际物理装置的总称。软件指的是在硬件上运行的程序和相关的数据及文档。
硬件 和 软件 关系：硬件是计算机的物理部分，它提供了运行软件所需的基础设施，而软件则是 指令集，指导 硬件如何工作以执行特定的任务。
冯·诺依曼提出的 “存储程序” 的思想奠定了当代计算机的基本结构，以此概念为基础的各类计算机通称为 冯·诺依曼机，其特点如下：
其中 五大部件 的具体功能如下：
三种语言的关系可以参照下图理解：
C 和 C++。# 预处理
gcc -E hello.c -o hello.i
# 编译
gcc -c hello.c -o hello.o
# 汇编
gcc -S hello.c
# 链接
gcc hello.o -o hello
# 加载和执行
./helloBCD（Binary-Coded Decimal）码是一种 二进制编码方法，用于表示 十进制数字。每个十进制数字（0-9）都使用 四位二进制数字 表示。
BCD 码的基本思路是 单独表示每个十进制数字的二进制值，而不是像传统的二进制数系统那样对整个数字进行编码。例如，在传统的二进制编码中，数字"19"会表示为 10011，但在 BCD 中，它被表示为两个独立的数字：“0001”（对应于 1）和“1001”（对应于 9），因此整个表示为“0001 1001”。
]]>BCD（Binary-Coded Decimal）码是一种 二进制编码方法，用于表示 十进制数字。每个十进制数字（0-9）都使用 四位二进制数字 表示。
BCD 码的基本思路是 单独表示每个十进制数字的二进制值，而不是像传统的二进制数系统那样对整个数字进行编码。例如，在传统的二进制编码中，数字"19"会表示为 10011，但在 BCD 中，它被表示为两个独立的数字：“0001”（对应于 1）和“1001”（对应于 9），因此整个表示为“0001 1001”。
0 - 0000 1 - 0001 2 - 0010
3 - 0011 4 - 0100 5 - 0101
6 - 0110 7 - 0111 8 - 1000
9 - 1001BCD 编码在某些应用中是很有用的，特别是在需要与 十进制界面 进行交互的地方，如 数字显示 或某些早期的计算机系统。尽管它不如 纯二进制编码 效率高，但它简化了与十进制数据的转换过程。
在介绍整数的不同表示之前，我们首先要定义清楚不同的名词，否则会造成极大的概念混淆。
在日常生活中，我们使用十进制表示数字，并通过符号（如 + 和 -）表示正负。这种用十进制表达的数字也叫做 字面值。
而计算机以二进制形式存储数据，补码、原码、无符号数 等只是 对二进制位的一种解释方式，它们决定了同一组二进制位所代表的实际数值。
在实际的计算机中，没有采用 原码 存储数据的，具体原因后面会谈到到。对于计算机中存储的数字来说，它的二进制只可能是 有符号数（signed） 或者 无符号数（unsigned） 这两种情况。
总结两种转换方式如下图：
例子：
10000001 对应的值为 −128+1=−12710001001 对应的值为 −128+8+1=−11901000001 对应的值为 64+1=65以 8 位二进制数为例：
使用 补码 可以使得 加法、减法和负数的表示 变得简单和统一。比如给定两个数字 A 和 B，我们想要计算 C = A + B。A + B 由硬件加法器得到的二进制结果可以直接作为 C 的二进制表示。
补码 的设计使得负数的加法变得简单。当使用 补码 表示时，可以直接将两个数相加，即使其中一个数是负数，而不需要进行任何特殊处理。这简化了计算机硬件的设计。
原码（Sign-Magnitude） 是一种简单的方式来表示二进制中的 有符号整数。在这种表示法中，数字的 最高位（最左边的位）用于表示符号，其余的位表示数字的大小。通常，符号位为 0 表示正数，而 1 表示负数。
原码的表示方法：
举例（以 8 位二进制数为例）：
0 00110011 0011001由于上述的缺点，原码 并不是计算机中最常用的表示法。在现代计算机中，补码 是更常用的方式来表示 有符号整数，因为它简化了算术运算的处理，并且没有 +0 和 -0 的冗余表示。
]]>存储系统是计算机体系结构的核心组成部分之一，用于存储程序指令和数据，以支持处理器的运算需求。为了平衡速度、容量和成本，现代计算机采用了分层存储体系结构，从最快速但容量有限的 寄存器 到容量大但速度较慢的辅助存储设备，形成了存储层次结构。
如上图所示，越靠近金字塔上层的容量越小但速度越快，越靠近金字塔下层的容量越大但速度越慢。计算机的存储系统包含以下层次：
存储系统是计算机体系结构的核心组成部分之一，用于存储程序指令和数据，以支持处理器的运算需求。为了平衡速度、容量和成本，现代计算机采用了分层存储体系结构，从最快速但容量有限的 寄存器 到容量大但速度较慢的辅助存储设备，形成了存储层次结构。
如上图所示，越靠近金字塔上层的容量越小但速度越快，越靠近金字塔下层的容量越大但速度越慢。计算机的存储系统包含以下层次：
存储器层次结构的主要思想是上一层的存储器作为低一层存储器的高速缓存。当 CPU 要从存储器中存取数据时，先访问 Cache，若不在 Cache 中，则访问 主存，若不在 主存 中，则访问磁盘，此时，操作数从磁盘读出送到 主存，然后从 主存 送到 Cache。
Cache——主存层 主要解决 CPU 和主存速度不匹配的问题，主存和 Cache 之间的数据调动是由硬件自动完成的。
主存一辅存层 主要解决存储系统的容量问题，主存和 辅存 之间的数据调动是由硬件和操作系统共同完成的，两者对于应用程序员都是透明的。
半导体随机存储器的英文为 Semiconductor Random-Access Memory （ RAM ）。
首先说一下这个名词中的几个部分：
随机存储器主要分为 SRAM 和 DRAM 两种。
SRAM（Static RAM，静态随机存取存储器）使用触发器（通常由 4-6 个晶体管组成）构成存储器的基本存储单元，存储每个比特的数据，如下图所示：
只要电源持续供应，数据无需刷新即可保持稳定。
SRAM 通过将触发器组织成二维阵列构成存储器，每行连接一个字线（Word Line），控制该行所有单元的访问。 每列连接一对位线（Bit Line），用于传输数据。
SRAM 主要用于 CPU 缓存（L1/L2/L3 Cache）、寄存器、嵌入式系统中的小型高速存储。
DRAM（Dynamic RAM，动态随机存储器）使用 1 个晶体管和 1 个电容器（1T1C 结构）构成存储器的基本存储单元，存储每个比特的数据。
与触发器不同，电容器具有 动态特性，会随时间漏电，导致数据丢失，因此需要 定期刷新（通常每几毫秒）以恢复电荷。
DRAM 和 SRAM 的存储阵列在宏观上类似，都采用二维矩阵结构，通过字线和位线实现随机访问，主要区别在于基本存储单元的不同：
它以低成本和高容量著称，主要用于 计算机主内存（如系统 RAM）、显卡内存等。
需要注意一点，绝大多数 DRAM 芯片的引脚都采用了 采用了 “行列地址复用” 的方式。
于是，引入了 行列地址复用（Address Multiplexing）：
但是 SRAM 一般不使用行列复用：外部地址线一次性给出完整的地址，直接解码到存储单元。因为 SRAM 容量较小且速度有限，所以引脚数量不会太多。
| 特性 | DRAM | SRAM | |
]]>指令的功能就是 对某些数据 进行 某种操作。
所以指令中主要包含两个部分：操作码（opcode）以及 地址（address）。
<addr>）<reg>）<imm>）指令的功能就是 对某些数据 进行 某种操作。
所以指令中主要包含两个部分：操作码（opcode）以及 地址（address）。
<addr>）<reg>）<imm>）指令根据其 操作码（opcode）的不同可以分为以下类别：
MOV：将数据从一个位置传输到另一个位置，可以是寄存器到寄存器、内存到寄存器、寄存器到内存等。PUSH：将数据（通常是寄存器中的值）推入堆栈。POP：从堆栈中弹出数据并存储到寄存器中。ADD、SUB、MUL、DIV：执行算术运算，如加法、减法、乘法和除法。AND、OR、XOR、NOT：执行逻辑运算，如按位与、按位或、按位异或和按位取反。INC、DEC：递增和递减操作数的值。CMP：用于比较两个值，并根据结果设置标志寄存器的状态。JMP：用于无条件跳转到指定的目标地址。Jxx：条件跳转指令，根据特定的条件（如零标志、进位标志等）来决定是否跳转。CALL：调用子程序或函数。RET：从子程序返回。IN：从外部设备或端口读取数据。OUT：向外部设备或端口发送数据。MOVS、LODS、STOS、CMPS：用于在内存中执行字符串操作，如移动、加载、存储、比较。INT：用于引发中断，通常用于与操作系统进行通信。CLI、STI：用于清除和设置 CPU 的中断标志，通常只能在内核模式下执行。根据指令中的 地址 个数，可以将指令划分为以下类型。 这些地址可以是 寄存器、内存地址，也可以是 立即数。
| 指令格式 | 指令格式 | 含义 | |
]]>作为计算机的“大脑”，CPU（中央处理器）是执行程序指令、处理数据的关键部件。从宏观的计算机体系结构来看，CPU 是冯·诺依曼架构中“运算器”与“控制器”两大核心部件的具体实现与集成。因此，剖析 CPU 的内部组成，本质上就是探究现代计算机如何通过精密的硬件设计，将“运算”与“控制”这两大基本功能高效、协调地融为一体，并最终执行复杂的任务。
在介绍 CPU 的组成结构之前，首先回顾一下计算机的 冯诺依曼结构，其中 运算器、控制器、存储器、输入、输出 为计算机组成的五大部件，其中 CPU 涵盖的功能就包含 运算器 和 控制器 这两个。
]]>作为计算机的“大脑”，CPU（中央处理器）是执行程序指令、处理数据的关键部件。从宏观的计算机体系结构来看，CPU 是冯·诺依曼架构中“运算器”与“控制器”两大核心部件的具体实现与集成。因此，剖析 CPU 的内部组成，本质上就是探究现代计算机如何通过精密的硬件设计，将“运算”与“控制”这两大基本功能高效、协调地融为一体，并最终执行复杂的任务。
在介绍 CPU 的组成结构之前，首先回顾一下计算机的 冯诺依曼结构，其中 运算器、控制器、存储器、输入、输出 为计算机组成的五大部件，其中 CPU 涵盖的功能就包含 运算器 和 控制器 这两个。
CPU 的核心功能包含 运算和控制 这两大模块，这对应了计算机五大部件中的 运算器 和 控制器。具体而言：运算功能（执行功能）是指 CPU 根据指令对数据进行算术或逻辑运算；控制功能则是指 CPU 通过指令协调计算机中各个部件的工作。
CPU 的结构简图如上图所示，CPU 由 运算部件 和 控制部件 组成。但是其实这两者并不能完全涵盖 CPU 的所有结构，因为这种分类方式忽略了 CPU 了内总线，所以一种更完善的 CPU 组件分类方法是将其分为 数据通路 和 控制器 这两部分：
CPU 的 数据通路 是指 CPU 在执行指令的过程中内部数据流动的路径，ALU、寄存器组、多路选择器 都属于数据通路的一部分。数据通路 描述了 信息从哪里开始，中间经过哪些部件，最后被传送到哪里。数据通路由 控制部件 控制，控制部件根据每条指令功能的不同，生成对数据通路的控制信号。
数据通路的元件主要分为 组合逻辑元件 和 时序逻辑元件 两类：
组合逻辑元件
组合逻辑元件（操作元件）指那些仅由 组合逻辑电路 组成的元件，其输出仅取决于当前的输入，而不受存储器或时钟信号的影响。输入和输出之间无反馈通路，信号是单向传输的。
数据通路中常用的组合逻辑元件有 算数逻辑单元（ALU）、译码器、多路选择器、三态门 等，如下图所示：
时序逻辑元件
对于 时序逻辑元件（状态元件），其任何时刻的输出不仅与该时刻的输入有关，还与该时刻以前的输入有关，并且 具备状态存储 功能。此外，时序电路必须在 时钟节拍 下工作。
各类 寄存器 和 存储器，如 通用寄存器组、程序计数器、状态/移位/暂存/锁存寄存器等，都属于时序逻辑元件。
控制器是计算机的指挥中心，它负责协调和控制计算机的所有操作。其核心功能是根据当前正在执行的指令，生成一系列控制信号，精确地指挥数据通路中的各个部件（如 ALU、寄存器、多路选择器）协同工作，从而完成指令所规定的任务。
控制器可以被视为整个 CPU 的“大脑”或“指挥家”。它不直接处理数据，而是决定数据在何时、何地、以何种方式流动和运算。
控制器的 基本工作原理 如下：
控制器的功能和组成详见 该节。
上文已经对 CPU 中的组件进行了分类，但是仅有抽象概念是不足够的，该节会提供一个非常简单的 CPU 实现来说明情况，这个 CPU 就是 8086。
8086 是 Intel 首款真正的 16 位处理器，也是现代 x86 处理器的开端，只要掌握了这个 CPU 的架构，就能搞定绝大多数考试过程中会遇到的问题。
上文已经提到了 CPU 的组成结构 可以分为 数据通路 和 控制器 这两部分，8086 中的 数据通路 由指令队列、寄存器 和内总线组成。控制器中包含指令译码器、时序控制单元、标志控制逻辑和微指令控制逻辑。
下文会按照这个脉络对 8086 中的组件进行详细说明。
从功能的角度进行区分，8086 CPU 的 寄存器 可以为分为 通用寄存器、段寄存器、指针寄存器、附加寄存器 和 标志寄存器 这五类：
AX 寄存器：累加器（Accumulator），用于执行算术和逻辑运算。BX 寄存器：基址寄存器（Base Register），通常用于存储内存地址。CX 寄存器：计数寄存器（Counter Register），用于循环计数和移位操作。DX 寄存器：数据寄存器（Data Register），用于输入/输出操作和大整数运算。CS (Code Segment) 寄存器：代码段寄存器，存储指向代码段的地址。DS (Data Segment) 寄存器：数据段寄存器，存储指向数据段的地址。ES (Extra Segment) 寄存器：附加数据段寄存器，通常用于数据访问。SS (Stack Segment) 寄存器：堆栈段寄存器，存储指向堆栈段的地址。SI 寄存器：源变址寄存器，通常用于数据传送操作。DI 寄存器：目的变址寄存器，也通常用于数据传送操作。SP (Stack Pointer) 寄存器：堆栈指针寄存器，指向函数栈的顶部。BP (Base Pointer) 寄存器：堆栈基址寄存器，指向函数栈的底部。IP 寄存器：指令指针寄存器，存储当前执行指令的偏移地址。FLAGS 寄存器：标志寄存器，存储有关条件和状态的信息，例如进位、零标志、溢出等。IR (Instruction Register) 寄存器：暂存读取的指令。T 暂存器：暂存 ALU 一端的输入。段寄存器指向程序调用时的 内存结构中不同段的起始位置：
对于运行在 8086 上的程序而言，其内存结构相比 现代进程内存空间 更加简单，但其中的逻辑结构是类似的：
从逻辑上来说，程序的执行需要四个段：
不同的段寄存器与不同的段相关联，指向相关段的起始地址。
对于有些段来说，仅仅知道其起始地址是不足够的，在程序执行过程中，需要一些额外的寄存器来实现我们需要的操作，指针寄存器主要操作 栈段 和 代码段。
栈指针寄存器
栈指针寄存器 包含 BP、SP 这两个，在进一步了解这两个寄存器之前，请复习一下 函数调用时的内存结构。
函数在执行过程中需要保存的数据与栈类似，具有先进后出的特点。
函数栈从高地址向低地址增长，嵌套调用的函数所对应的函数栈 在栈段上不断堆叠。如果我们在 main() 主函数中嵌套调用 f(g(h(1)))，那么该程序对应的栈段对应的逻辑结构如下所示：
其中 BP 指向最后一个调用的函数栈的底部，SP 指向最后一个调用的函数栈的顶部，通过 BP 和 SP 我们保存了最后一个函数栈帧的栈底（开始位置）和栈顶（结束位置）。
指令指针寄存器
在 8086 中，指令指针寄存器指的就是 IP（Instruction Pointer）寄存器。
指令在 代码段（.text 段）中是从低地址向高地址增长的，这种增长方式也符合 程序计数器（PC 或 IP）的增长逻辑：在 指令执行的取指阶段，控制单元在完成取指后会控制 IP = IP + 指令长度，这样 IP 就指向了 下一条待执行指令的地址。
变址寄存器 主要用于实现变址寻址模式，方便对数组、字符串等数据结构中的 第 i 个元素 进行操作。8086 中的主要变址寄存器是 SI（源变址寄存器）和 DI（目的变址寄存器），下文分别从 数组 和 字符串操作 两个例子说明一下：
数组操作
以下汇编代码段通过一个循环操作实现了对于数组中的前五个元素进行操作。注意在 8086 中，我们是在 CX 中保存 loop 的轮数，每次 LOOP 被调用后 CX 的值自动被减一。
; 假设 DS 指向数据段并且数组从数据段开始
MOV DS, addr ; 将数组的起始地址保存到 DS 中
MOV CX, 5 ; CX 用作循环计数器，假设数组有 5 个元素
MOV SI, 0 ; SI 作为索引寄存器，初始化为 0
NEXT_ELEMENT:
MOV AX, [SI] ; 从数组当前元素读取到 AX
; 对 AX 中的数据进行处理
ADD SI, 2 ; 移动到下一个元素（假设每个元素 2 字节）
LOOP NEXT_ELEMENT ; 循环直到 CX 为 0字符串操作
以下汇编代码将一个字符串的前 length 个字符复制到另一个字符串中。
; 假设 DS 和 ES 已经分别指向源和目的数据段
MOV SI, OFFSET source ; SI 指向源字符串的起始位置
MOV DI, OFFSET dest ; DI 指向目的字符串的起始位置
CLD ; 清除方向标志位，确保字符串操作从低地址到高地址
MOV CX, length ; CX 初始化为字符串的长度
REP MOVSB ; 复制 CX 个字节从 DS:SI 到 ES:DI标志寄存器（Flags）用于存储处理器在 执行指令过程中产生的各种状态和条件，这些状态可以进一步被 控制器 所用，控制后续指令执行的行为。
标志寄存器中的不同位用于标记某个特殊的状态，8086 中的 标志寄存器 是一个 16 位 的寄存器，其中 9 个标志位 被使用，其他 7 个标志位 没有含义。
这些标志位在逻辑上可以被分为 条件标志（conditional flags）和 控制标志（control flags）两种：
条件标志
条件标志用于标记指令执行后的结果状态，用于影响程序的控制流，条件标志 包含以下几种：
条件标志不需要 序员手动通过指令设置，当算数和逻辑指令（Add 和 AND 等）和 比较指令（CMP）被执行时，相关的标志位会被 自动设置。
条件标志通常用于控制 条件跳转指令 的执行。条件跳转指令会检查条件寄存器中的标志位，根据标志位的状态决定是否将 程序计数器（PC）修改为目标地址，从而实现程序流程的跳转。
以下我们需要说明几个需要注意的点，这些知识点很容易被混淆：
控制标志
控制标志 并不会被通常的运算指令自动修改，而是通过专门的指令来进行设置或清除。对于以下字段，了解即可：
暂存器
每次 ALU 操作都需要两个操作数，但是 数据总线 是 共享的，同一时刻只能传输一个操作数。所以在 ALU 会按照以下方式进行计算：
所以在 只有一个内部数据总线 的设计里，为了配合 ALU 的两个输入，暂存器被设置用于存储前一个时钟周期的数据。
指令寄存器
当 CPU 从内存或指令队列中取出一条指令时，这条指令会被送入 IR（指令寄存器），暂存在这里，供后续的译码和执行阶段使用。
控制单元（CU）可以对 IR 中的指令进行译码，生成一系列控制信号。
CPU 的 引脚（Pin）是处理器与主板之间进行电气连接的接口，是 CPU 与外部组件（如内存、I/O 设备、电源等）之间通信的桥梁。引脚 的功能包括 数据传输、地址定位、中断控制、时序控制 等，是实现 CPU 与外部世界交互的关键通道。
为便于理解，本节以 Intel 8086 处理器为例进行说明。需要注意的是，本节内容以了解为主，试题通常不会直接考察，但对于理解计算机体系结构十分重要。
以 8086 为例，8086 为 16 位计算机，其 数据总线 为 16 位，可寻址地址空间为 1 MB，所以其 地址总线 为 20 位。数据总线和地址总线 复用，地址总线的高位与状态线复用：
| 引脚名 | 方向 | 说明 | |
]]>总线 是一组电子导线或信号线，它们允许不同的硬件设备（如 CPU、内存、输入/输出 设备等）之间进行数据传输和通信。总线是计算机内部和外部设备之间的信息传递通道。
总线 是一组电子导线或信号线，它们允许不同的硬件设备（如 CPU、内存、输入/输出 设备等）之间进行数据传输和通信。总线是计算机内部和外部设备之间的信息传递通道。
总线 的数据传输方式包含 串行 和 并行 两种：
试题中常常考查 哪些总线是串行总线，哪些总线是并行总线 。
这里核心把握一点：现代高速通信几乎都使用串行总线（PCIe、USB、SATA、DisplayPort），而并行总线主要用于内存、老式设备或非常短距离的高速通信。
常见的串行总线 如下表所示：
| 总线类型 | 简介 | |
]]>操作系统 是计算机系统中的一个核心软件组件，负责管理和控制计算机硬件，为用户和应用程序提供服务。
操作系统 是计算机系统中的一个核心软件组件，负责管理和控制计算机硬件，为用户和应用程序提供服务。
操作系统 的发展历程经历了 手工操作、批处理操作、分时操作、实时操作 这四个阶段：
手工操作阶段：
批处理操作系统：
分时操作系统：
操作系统 引导的具体流程如下：
在多道程序环境下，允许多个程序并发执行，为此操作系统引入了 进程 (Process) 的概念，以便更好地描述和控制程序的并发执行，实现操作系统的并发性。
进程是系统资源分配的基本单位。进程拥有独立的系统资源，包括内存空间、文件描述符、CPU 时间片等，这些资源的分配由操作系统负责。
程序是 静态的，进程是 动态的，进程可以理解成运行的程序，两者的具体区别如下：
]]>在多道程序环境下，允许多个程序并发执行，为此操作系统引入了 进程 (Process) 的概念，以便更好地描述和控制程序的并发执行，实现操作系统的并发性。
进程是系统资源分配的基本单位。进程拥有独立的系统资源，包括内存空间、文件描述符、CPU 时间片等，这些资源的分配由操作系统负责。
程序是 静态的，进程是 动态的，进程可以理解成运行的程序，两者的具体区别如下：
操作系统通过 进程控制块（PCB，Process Control Block）对进程进行管理。 PCB 中保存了 操作系统管理进程所需的关键信息，当发生 进程切换（上下文切换） 时，需要将运行进程的状态保存到 PCB 中。
PCB 主要包含以下几类信息：
| 信息类别 | 典型内容 | |
]]>虚拟地址（VA, Virtual Address）由指令中的 地址字段 给出，进程看到的都是虚拟地址。物理地址是内存单元在 实际内存硬件 中的真实位置。
地址翻译指的是在程序执行的过程中 将虚拟地址翻译为物理地址，地址变换由 内存管理单元（MMU, Memory Management Unit） 在硬件中完成，速度非常快。
共享内存（Shared Memory）是多个 进程 共享的 内存区域。它是最快的 IPC（进程间通信）机制之一，因为进程直接读写内存，无需进入内核态。但是，因为多个进程可以同时访问这些内存，所以可能需要某种 同步机制（如信号量）来防止竞态条件。
内存保护是现代操作系统中的一个 核心功能，用于防止一个进程访问另一个进程的 内存空间。这不仅保障了系统的稳定性，而且提高了安全性，因为它可以防止恶意软件损害其他进程或篡改其数据。
可以通过如下机制实现内存保护机制：
在现代操作系统中，内存管理方式 大体可以归纳为两类：连续分配 和 离散分配。所谓 连续分配，是指操作系统为进程分配一整段连续的内存区域。这种方式实现简单、开销较小，但灵活性不足。典型的连续分配方式包括三种：单一连续分配、固定分区分配 以及 动态分区分配。
相比之下，离散分配 方式允许进程占用的内存空间是 不连续的，这使得内存利用率和管理灵活性显著提高。典型的离散分配方式也包含三种：页式、段式、段页式。
后文会具体介绍这几种内存管理方式的细节。
内存在此方式下分为 系统区 和 用户区，系统区仅供操作系统使用，通常在高地址部分；在用户区内存中，仅有一道用户程序，即整个内存的用户空间都由该程序独占。
这种方式的优点是 简单、无外部碎片，无需进行内存保护，因为内存中永远只有一道程序。缺点是只能用于 单用户、单任务 的操作系统中，存储器的利用率极低。
固定分区分配是最简单的一种 多道程序存储管理 方式，它将用户内存空间划分为若干 固定大小的区域，每个分区只装入一道作业。当有空闲分区时，便可再从外存的后备作业队列中选择适当大小的作业装入该内存，如此循环。
为了方便内存分配，通常将分区按大小排队，并为之建立一张 分区说明表，其中各表项包含每个分区的起始地址、大小和状态。当有用户程序需要装入时，便检索该表，以找到合适的分区基于分配并将其状态设置为“已分配”；未找到合适分区时，则拒绝为给程序分配内存。
在 固定分区分配 中，内存被预先划分为若干大小固定的区域。 这种方式实现简单，但也带来了一个明显问题：分区大小是静态的，而作业大小是动态的。
为了解决固定分区“尺寸僵化、内存利用率低”的问题，操作系统引入了 动态分区分配。
动态分区分配的基本思想是： 不再事先划分固定大小的分区，而是将整个用户内存空间视为一块 连续的可分配区域，在程序装入时才根据其实际需要动态地划分内存。
当进程请求内存时，操作系统从当前的空闲内存中划出一块连续区域分配给该进程； 当进程结束或释放内存时，该区域重新成为空闲内存，可供后续进程再次使用。
通过这种 动态、按需分配 的方式，内存从逻辑上被划分为两类区域：
如下图所示，其中 内核内存（kernel memory） 和 进程内存（process memory） 属于已分配区域，其余部分为系统当前的空闲内存。
为了管理这些不断变化的空闲区域，操作系统通常维护一张 空闲分区表（或空闲链表），用于记录每一块空闲内存的：
示意如下：
当进程申请内存时，操作系统会遍历 空闲分区表，按照预定的 适应算法（如首次适应、最佳适应等），从中选择一块满足需求的空闲区域，并完成内存分配。
不同适应算法的选择，会直接影响系统中 外部碎片 的产生情况，这一点将在后续章节中详细讨论。
动态分区分配相比固定分区分配，提高了内存使用率，但是仍然无法避免内存碎片的问题，下图以一个实例说明了在动态分区分配过程中内存碎片产生的过程：
由于各进程所需的内存大小各不相同，在进行内存分配时经常会在已分配的块之间留下 内存碎片。
所谓内存碎片，指的是那些 尺寸过小、无法满足任何进程实际需求 的空闲内存块。因为进程的内存申请往往大于等于某个最小阈值，这些零散且容量不足的碎片就无法被再次利用，导致可用内存实际被浪费。
内存空间中的空闲区域可能大小不一，且分布在内存中不同的位置，操作系统使用 空闲块表 来记录这些空闲区域的信息。
当进程申请一块新的内存时，必须从已有的空闲空间中选出一块分配给进程。动态分区的分配策略主要包含四种算法：首次适应（First Fit）、临近适应（Next Fit）、最佳适应（Best Fit）、最坏适应（Worst Fit）。
适应算法中的利用率计算
假设进程申请的内存大小为 P，空闲块大小为 F，则利用率为：
举个实例例子，假设空闲块序列 [8, 22, 20, 14, 10, 24]，请求大小 P = 16。则四种分配算法会得到不同的结果：
四种适应算法在该例子的对比如下表所示：
| 算法 | 查找方式 | 本例选择结果 | |
]]>在 UNIX 和类 UNIX 操作系统中，inode（索引节点）用于存储 文件的元数据，它包含了关于该文件的大部分 元数据，但不包括 文件名 和 文件实际内容。
inode 中包含如下信息：
在 UNIX 和类 UNIX 操作系统中，inode（索引节点）用于存储 文件的元数据，它包含了关于该文件的大部分 元数据，但不包括 文件名 和 文件实际内容。
inode 中包含如下信息：
在进程中可能会打开若干文件，操作系统需要以某种方式对进程打开的文件信息进行记录。这就需要用到三个数据结构：文件描述符表、文件表、inode 表。
open 调用成功时，都会创建一个新的 文件打开表条目。inode 表（inode table）是一个固定的、专门的区域，用来存储文件系统中所有文件和目录的 inode 结构。每个 inode 占用一个表项，表中的每个 inode 编号（inode number）对应一个唯一的文件或目录。
注意 inode 表是存储所有 inode 的唯一容器：
下表给出了一个简化的 inode 表示例：
| inode 编号 | 文件类型 | 权限 | 所有者 | 文件大小 (字节) | 数据块指针（简略） | 创建时间 | 修改时间 | |
]]>根据设备类型的不同，我们将 I/O 接口 分为三种类型：
块设备（Block Device）是计算机中一类以 固定大小的数据块 为单位进行数据读写的 I/O 设备，通常用于存储和检索大量数据。它们 支持随机访问，意味着可以直接定位到任意数据块，而无需按顺序读取。
]]>根据设备类型的不同，我们将 I/O 接口 分为三种类型：
块设备（Block Device）是计算机中一类以 固定大小的数据块 为单位进行数据读写的 I/O 设备，通常用于存储和检索大量数据。它们 支持随机访问，意味着可以直接定位到任意数据块，而无需按顺序读取。
典型例子包括机械硬盘（HDD）、固态硬盘（SSD）和 USB 闪存盘。块设备 的 数据传输速率较高，但涉及复杂的控制器和协议（如 SATA 或 NVMe)，因此在操作系统中通常由专门的驱动程序管理。
字符设备是另一类 I/O 设备，以 连续的字符流 形式进行数据传输，不支持随机访问，也不依赖数据块的概念。它们通常用于与硬件设备交互，如 键盘、鼠标、串口终端 或 打印机。字符设备的数据流是顺序的，适合实时或低速数据传输场景。
例如，键盘输入的字符流直接发送到系统，而无需缓存整个数据块。字符设备在操作系统中通常通过简单的驱动程序管理，且不涉及文件系统，适合处理非结构化数据。
网络设备是专门用于计算机网络通信的 I/O 设备，负责在计算机与网络之间传输 数据包。它们包括网络适配器 和调制解调器等设备。网络设备 以数据包为单位 工作，通常通过协议栈（如 TCP/IP) 处理数据，支持点对点或广播通信。
与块设备和字符设备不同，网络设备更注重 数据的高速传输 和 实时性，常涉及中断机制和 DMA（直接内存访问）来提高效率。操作系统通过网络驱动程序管理这些设备，以实现网络连接和数据交换。
在计算机系统中，I/O（输入/输出）控制方式决定了 CPU 与外设之间如何协作完成数据传输。主要有三种方式，每种方式在性能、复杂度与使用场景上各有不同：
I/O 软件层次是计算机系统中用于管理和协调输入输出操作的软件架构，从用户应用程序到硬件设备，分为多个层次，每一层负责特定的功能，确保高效、可靠的 I/O 操作。
用户层 I/O 软件是 I/O 软件体系结构的最上层，直接与用户应用程序交互，提供标准化的接口 以便程序能够访问 I/O 设备。
它主要包括库函数和系统调用接口，例如 C 语言中的 stdio 库（提供 printf、scanf 等函数）或 POSIX 系统调用（如 read、write）。这些软件封装了底层的复杂性，让用户程序无需关心具体设备细节即可进行输入输出操作。
设备独立性软件位于用户层和设备驱动程序之间，负责屏蔽不同 I/O 设备的硬件差异，提供统一的接口供上层软件使用。它 实现了设备无关的功能，例如文件系统管理、设备命名、缓冲管理和错误处理。
例如，操作系统通过设备独立性软件将不同类型的存储设备（如硬盘、USB 驱动器）抽象为统一的文件系统接口，程序只需操作文件路径而无需关心底层设备类型。此外，它还管理设备的分配与释放，避免多个进程同时访问同一设备导致冲突。设备独立性软件的核心作用是提高系统的模块化和可移植性。
设备驱动程序是 I/O 软件层次中直接 与具体硬件设备交互 的部分，每个设备驱动程序针对特定类型的硬件设备设计，负责将设备独立性软件的通用命令转换为设备能够理解的特定指令。
例如，一个硬盘驱动程序会处理扇区读写命令，而一个打印机驱动程序可能发送控制字符序列。驱动程序通常由设备制造商提供，运行在操作系统的内核态，能够直接访问设备寄存器和端口。由于硬件设备的多样性，驱动程序需要处理设备初始化、数据传输和错误恢复等任务，是连接软件与硬件的关键桥梁。
中断处理程序是 I/O 软件层次中 专门处理硬件中断 的部分，当设备完成操作或发生事件（如数据到达、错误发生）时，硬件会触发中断信号，中断处理程序迅速响应以处理这些事件。它运行在极低的层次，通常以极高的优先级执行，负责保存中断现场、处理设备状态、通知上层软件或触发后续操作。
例如，当网卡接收到 数据包 时，中断处理程序会将数据移到内存并通知网络协议栈。由于中断处理需要极快的响应速度，代码通常高度优化且精简，尽量减少处理时间，以避免影响系统性能。
硬件是 I/O 软件层次的最底层，直接负责 执行物理 I/O 操作，包括实际的设备控制器、寄存器、端口和数据传输通道。硬件层由具体的 I/O 设备（如硬盘、键盘、网络适配器）及其控制器组成，控制器通过寄存器和端口接收驱动程序的指令，执行数据读写或状态查询等操作。
例如，硬盘控制器通过 DMA（直接内存访问）将数据直接传输到内存，而网卡通过硬件队列处理 数据包。硬件层的性能和特性直接决定了 I/O 操作的效率，软件层的所有操作最终都依赖硬件的物理实现。
]]>OSI 参考模型 有 7 层，自下而上依次为：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层（记忆：物链网输会示用）
低三层统称为 通信子网，它是为了联网而附加的通信设备，完成数据的传输功能
传输层 承上启下
高三层统称为 资源子网，它相当于计算机系统，完成数据的处理等功能。
OSI 参考模型 有 7 层，自下而上依次为：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层（记忆：物链网输会示用）
低三层统称为 通信子网，它是为了联网而附加的通信设备，完成数据的传输功能
传输层 承上启下
高三层统称为 资源子网，它相当于计算机系统，完成数据的处理等功能。
物理层的传输单位是 比特，功能是在物理媒体上为数据端设备透明地传输原始比特流，不用参与数据封装工作。为了实现该功能，物理层需要定义 硬件设备标准，如电缆类型、接口类型、电压标准等。
数据链路层的传输单位是 帧，两台主机之间的数据传输总是在一段一段的链路上传送的，这就需要使用专门的链路层协议。
数据链路层将网络层交来的 IP 分组封装成帧，并且可靠地传输到相邻结点的网络层。主要作用是加强物理层传输原始比特流的功能，将物理层提供的可能出错的物理连接改造为尽可能可靠的 数据链路。数据链路层的功能可以概括为：物理寻址、组帧、差错控制、点对点流量控制、数据重发和传输管理等。
网络层（Netweork Layer）的传输单位是 数据报，它关心的是通信子网的运行控制，主要任务是把网络层的 协议数据单元（分组）从源端传到目的端，为分组交换网上的不同主机提供通信服务。关键问题是对分组进行 路由选择，并实现整个网络的流量控制。
传输层（Transport Layer）的传输单位是报文段或用户数据报，传输层负责主机中两个进程之间的通信，功能是为 端到端 连接提供可靠的传输服务，为 端到端 连接提供流量控制（端到端）、差错控制、服务质量、数据传输管理等服务。
数据链路层提供的是 点到点 的通信，传输层提供的是 端到端 的通信，两者不同。点到点 可以理解为主机到主机之间的通信；端到端的通信是指运行在 不同主机内的两个进程之间的通信，只有传输层及以上各层的通信才能称为端到端。
会话层（Session Layer）允许不同主机上的各个进程之间进行会话。这 会话 这种服务主要为用户进程建立连接，并在连接上有序地传输数据，这就是 会话。
会话层负责管理主机间的会话进程，包括建立、管理及终止进程间的 检查点 机制来维持可靠会话，使通信会话在通信失效时从检查点继续恢复通信，即断点下载的原理。
表示层 主要处理在两个通信系统中交换信息的表示方式。不同机器采用的 编码 和表示方法不同，使用的数据结构也不同。为了使不同表示方法的数据和信息之间能互相交换，表示层采用抽象的标准方法定义数据结构，并采用标准的 编码 形式。此外，数据压缩、加密和解密 也是表示层的功能。
应用层是 OSI 参考模型的最高层，是用户与网络的接口。应用层为特定类型的网络应用提供访问 OSI 参考模型环境的手段。因为用户的实际应用多种多样，这就要求 应用层 采用不同的应用 协议 来解决不同类型的应用要求，因此 应用层 是最复杂的一层，使用的 协议 也最多
TCP/IP 模型 有4层 ，从低到高依次为：网络接口层、网际层、传输层、应用层
TCP/IP 模型 的层次结构如下图所示：
TCP/IP 模型 与 OSI 模型 的不同点在于 网络接口层 和 应用层，可以理解为 TCP/IP 模型 中这两层涵盖了 OSI 协议 中多层的功能：
学习计算机网络时，我们往往采取折中的办法，即综合 OSI 参考模型 和 TCP/IP 模型 的优点，采用一种如下图所示的只有 5 层协议 的体系结构，即我们所熟知的【物理层、数据链路层、网络层、传输层和应用层】。
在网络中，协议数据单元（PDU，Protocol Data Unit）是指在某一层协议中传输的数据单元。每一层在接收来自上一层的数据时，都会在其头部添加控制信息（称为首部 Header），然后将其当作一个新的 PDU 交给下一层处理。这就是所谓的 封装 过程。
| OSI 层级 | PDU 名称 | |
]]>物理层定义了设备之间如何通过电缆、无线等物理媒介进行通信。物理层具有以下四种 接口特性：
物理层定义了设备之间如何通过电缆、无线等物理媒介进行通信。物理层具有以下四种 接口特性：
与 信道 相关的概念有四个，需要能够辨别这几个名词：
一个 码元（symbol）就是一个脉冲信号，一个脉冲信号有可能携带 1bit 数据，也有可能携带 2bit 数据、4bit 数据。
那么怎么实现一个脉冲信号就能携带多个 bit 数据呢？我们可以通过 调制技术 来实现，比如设置模拟信号中信号的频率、相位、振幅 等。
举个例子：把 振幅 分成四种，低（00）、中（01）、高（10）、很高（11），这样我发一个脉冲信号，它的振幅是低，那就说明发送的是 00（也就是 2bit），它的振幅是中（01），发送的就是 01（也就是 2bit）… 以此类推
波特（Baud）是数据通信中的一个术语，用来表示符号（或码元）传输速率。具体来说，波特率（Baud rate）指的是每秒钟传输的码元（symbol）的数量。
码元和 波特率：一个码元可以携带一个或多个比特的信息。波特率是指每秒钟传输多少个这样的码元。例如，如果 波特率 为 1000 波特，这意味着每秒可以传输 1000 个码元。
波特率 与 比特率：波特率和比特率的关系取决于每个码元携带的比特数。
速率（Rate）是指连接到计算机网络上的节点在数字信道上传送数据的速率，也称数据传输速率、数据率或比特率，单位为 b/s（比特／秒）或 bit/s（有时也写为 bps )。
当数据率较高时，可用 kb/s（k = 103 ）、Mb/s（M = 106 ）或 Gb/s（G = 109 ）表示。通常把最高数据传输速率称为 带宽。
速率可以用两种指标来衡量：
一个码元可以包含多个比特，如果一个码元携带 n 比特的信息量，则 波特率 M 对应的 比特率 为 M**n bit/s
带宽（Bandwidth）在通信领域中，指通信线路能够通过的信号频率范围，单位为赫兹（Hz）。 在计算机网络中，带宽通常被引申为通信线路的数据传输能力，即数字信道所能达到的 最大数据传输速率，其单位为比特每秒（b/s）。
例子：如果家里的宽带带宽是 100Mb/s，表示网络在理想情况下，每秒最多可以传输 100兆比特 的数据，相当于大约 12.5MB/s 的下载速度。
在考题中偶尔涉及到带宽和吞吐量的区别：
举例：虽然网络带宽是 100Mb/s，但在高峰时段可能只能达到 70Mb/s，这 70Mb/s 就是实际的吞吐量。
时延（Delay）指数据（一个报文或分组）从网络（或链路）的一端传送到另一端所需要的总时间，它由 4 个部分构成，分别为：发送时延、传播时延、处理时延和排队时延。
发送时延：也称 传输时延。节点将分组的所有比特推向（传输）链路所需的时间，即从发送分组的第一个比特算起，到该分组的最后一个比特发送完毕所需的时间。
传播时延：电磁波在信道（传输介质）中传播一定的距离需要花费的时间，即一个比特从链路的一端传播到另一端所需的时间。
处理时延：数据在交换结点为存储转发而进行的一些必要的处理所花费的时间。例如，分析分组的首部、从分组中提取数据部分、进行差错检验或查找适当的路由等。
排队时延：分组在进入路由器后要先在输入队列中排队等待处理。路由器确定转发端口后，还要在输出队列中排队等待转发，这就产生了 排队时延。
因此，数据在网络中经历的总时延就是以上 4 部分时延之和：总时延＝发送时延＋传播时延＋处理时延＋排队时延。
注意：需要区分 传输时延 和 传播时延。传输时延是路由器将分组推出所需的时间，是分组长度和链路传输速率的函数。传播时延是一个比特从一台路由器传播至另一台路由器所需的时间，是两台路由器之间距离的函数，而与分组长度或链路传输速率无关。
时延带宽积（Bandwidth-Delay Product，简称 BDP）指发送端发送的第一个比特即将到达终点时，发送端已经发出了多少个比特，因此又称以比特为单位的链路长度，即：时延带宽积=传播时延×信道带宽
如下图所示，考虑一个代表链路的圆柱形管道，其长度表示链路的传播时延，横截面积表示链路带宽，则 时延带宽积 表示该管道可以容纳的比特数量。
奈奎斯特定理 说明了在 无噪声干扰、带宽有限 的理想低通信道中的数据极限传输速率。当实际传输速率小于等于该速率时，可以实现无码间串扰的数据传输。
奈奎斯特定理的 核心思想 是： 即使在没有噪声的理想信道中，信道的带宽仍然限制了其数据传输能力。为了避免相邻码元之间的干扰（即码间串扰），每秒钟最多只能传输有限数量的码元，这个数量与带宽直接相关。
其中：
公式中的含义：
因此，在理想无噪声信道中，极限传输速率取决于带宽和码元的离散电平数。
香农定理 说明了在 有噪音干扰、带宽有限 的信道中的数据极限传输速率，当实际传输速率小于等于改速率时，可以做到不产生误差。
香农定理的 核心思想 是： 即使信道中存在噪声，只要信息传输速率低于某个极限值（即信道容量），就一定可以通过某种编码方式实现几乎无差错的传输。这个极限值取决于信道的带宽和 信噪比。
其中：
公式中的含义：
数据链路层的主要功能之一就是 组帧。
帧（frame）代表数据链路层的数据发送单位，在接收到来自于网络层的报文（packet）时如何为其添加帧头和帧尾，并且以何种方式进行 帧定界（接收方区别连续不同的帧）。
组帧的关键就在于 帧定界，也就是对于接收方来说，它能够以某种方式区分连续收到的不同帧。 从这个角度出发，组帧 方式可以被分为以下几种：
数据链路层的主要功能之一就是 组帧。
帧（frame）代表数据链路层的数据发送单位，在接收到来自于网络层的报文（packet）时如何为其添加帧头和帧尾，并且以何种方式进行 帧定界（接收方区别连续不同的帧）。
组帧的关键就在于 帧定界，也就是对于接收方来说，它能够以某种方式区分连续收到的不同帧。 从这个角度出发，组帧 方式可以被分为以下几种：
字符计数法 是在帧的首部设置一个计数字段，用来指示该帧中包含的字符（或字节）数量。
当接收方开始读取一帧时，首先读取位于 帧首部的计数字段。通过该字段的数值，接收方即可知道该 帧的总长度（即后续应读取的字符数）。随后，接收方按照得到的长度继续读取剩余的数据，直至完整地接收完本帧。
首位定界字符法即 使用特殊控制字符标志帧的开始和结束。
但是使用这种方式可能出现如下问题：就是 首位定界字符 可能会在帧内部出现，这个时候就会造成歧义。
所以当特殊字符出现在帧的数据部分时，需要用 转义字符 ESC 来对特殊字符进行转义，同样，ESC 出现在数据部分同样需要转义。
以上图为例，假设我们使用 FLAG 作为 首位定界字符 的话（注意这里 FLAG 只是字符名称，不是表示字符是 FLAG），那么当 FLAG 出现在数据部分时，我们需要对 FLAG 进行转义，需要注意的是，因为我们使用 ESC 作为转义字符，所以当数据中出现 ESC 时，我们也需要对转义字符自己进行转义。
零比特填充法（Bit Stuffing）与首位定界字符法思路类似。
用 01111110 作为一个新的数据帧的开头，这里的关键在于要对数据帧内容中与 01111110 相同的部分进行转义，转义的方式如下：
'1' 时，'0'，避免形成 6 个连续的 '1'（即避免形成 01111110）。'1' 后跟着一个 '0'，就去掉这个 '0'，还原原始数据。对于 零比特填充法，需要记住 01111110 这种开头的比特填充方式以及具体如何进行转义。
违规编码法（Physcial Layer Coding Violations）使用特殊电平进行定界。比如，曼彻斯特编码 将数据比特“1”编码为“高 - 低”电平，将比特“0”编码为 “低-高” 电平对，而 “高-高” 电平对和 “低-低” 电平对是没有被使用的，所以可以用这两个电平进行帧定界。
]]>在现实生活中，我们通过“国家‑省份‑城市‑街道‑小区‑楼栋‑门号”等层级信息来定位一个具体地点，例如 中国‑北京市‑海淀区‑某街道‑某小区‑某栋‑某户。
在计算机网络里，定位一台主机同样需要使用唯一的地址，这个地址就是 IP 地址。IP（Internet Protocol）直译为“互联网协议”，它既提供了主机的标识，又规定了数据在网络中的传输方式。
仅有地址并不能保证数据能够顺利从源端到达目的端。互联网是一张由无数路由器、交换机等网络设备相互连接而成的全球性网络。从 一个机器 到 另一个机器 的通信，往往要经过多级转发。如何在众多可能的路径中找到一条通向正确目的地的路线，就需要 IP 协议 与路由协议共同配合完成。后续章节我们会逐步剖析这一过程的细节。
]]>在现实生活中，我们通过“国家‑省份‑城市‑街道‑小区‑楼栋‑门号”等层级信息来定位一个具体地点，例如 中国‑北京市‑海淀区‑某街道‑某小区‑某栋‑某户。
在计算机网络里，定位一台主机同样需要使用唯一的地址，这个地址就是 IP 地址。IP（Internet Protocol）直译为“互联网协议”，它既提供了主机的标识，又规定了数据在网络中的传输方式。
仅有地址并不能保证数据能够顺利从源端到达目的端。互联网是一张由无数路由器、交换机等网络设备相互连接而成的全球性网络。从 一个机器 到 另一个机器 的通信，往往要经过多级转发。如何在众多可能的路径中找到一条通向正确目的地的路线，就需要 IP 协议 与路由协议共同配合完成。后续章节我们会逐步剖析这一过程的细节。
目前 IP 协议有两个版本：
本文的重点在于深入理解 IPv4 的工作原理和细节。
IPv4 地址由 4 个字节（即 32 位）构成，例如：11000000.10101000.00000100.00000010 就是一个典型的 IPv4 地址的二进制形式。
由于二进制表示不便于人类阅读，IPv4 通常采用 点分十进制 的方式进行表示。
在点分十进制中，每个字节用十进制数表示，并以点号分隔 4 个字节。例如，上述二进制地址对应的点分十进制形式为 192.168.4.2。
IP 地址的设计本质上是为了在互联网中唯一标识一台设备，因此通常被划分为两个部分：
网络号负责确定目标网络，主机号用于在该网络中定位到具体设备。
在 IP 地址的划分中，有些 主机号 是保留的，不能被用于分配给普通设备：
此外，还有以下两个特殊的全局地址：
0.0.0.0：表示“本机”，通常用于设备尚未获得 IP 地址时的占位。255.255.255.255：称为“本地广播地址”，用于向本地网络中的所有设备广播数据。IP 协议位于 OSI 7 层模型的网络层，其承载上层（传输层）的数据，对其进行 封装，然后传递给下层（数据链路层）进行进一步的处理。
封装的具体过程就是为 传输层的数据 加上 IP 协议的首部的二进制表示，IPv4 的首部的 逻辑格式 如下图所示，其中包含多个字段，长度通常为 20 个字节。
这一小节简单介绍各个字段，帮助大家建立一个粗略的了解，部分字段的细节我会在后面几个小节详解说明。
0101，5 * 4（4 字节为单位） = 20，最终表示的长度为 20）。简而言之，IP 数据报的最大长度为 65535 字节，这是因为其“总长度”字段占 16 位，所能表示的最大无符号整数为 65535。然而，数据链路层（如以太网）的 MTU（最大传输单元）往往远小于该值，例如以太网的 MTU 通常为 1500 字节。
因此，当 IP 数据报长度超过底层链路的 MTU 时，就需要将其拆分成多个更小的部分进行传输，这一过程称为 IP 分片（IP Fragmentation）。关于分片的详细内容可参考：IP 数据报分片。
在进行分片时，会引出两个关键问题：
比如，假设 packet A 被分片为 A1、A2、A3，而 packet B 被分片为 B1、B2，我们如何知道 A1 属于 packet A 而不是 packet B？
为了解决这些问题，IP 协议在首部中设计了以下两个重要字段：
通过这两个字段，接收方可以准确地将来自不同数据报的分片加以区分，并将同一数据报的所有分片按照正确顺序重新组装起来，恢复出原始的 IP 数据报。
IP 首部的 checksum 为 IP 协议的差错校验字段，用于检验 IP 首部在传输的过程中是否发生错误，接下来我会告诉你如何通过该字段进行校验。
当一个 IP 数据报被创建时，发送端设备会计算 IP 头部的校验和，并填充 IP 数据报中的 checksum 字段。
当 路由器 和 目标机器 在收到数据报时会重新计算首部校验和，并将计算得到的校验和和接收到的 IP 数据报中的 checksum 进行比较。如果 不一致 的话，则说明 IP 数据报中的某些数据在传输的过程中出现变动，就需要 丢弃 该 IP 数据报。
需要注意的是，当 IP 数据报 经过某个路由器时，路由器需要 重新计算 并填充 checksum 字段，因为 IP 数据报中的某些字段在经过路由器时会被改变（比如 TTL 会减 1 等）。
一般而言，对于校验和，了解到以上程度即可，如果你好奇校验和究竟是如何计算且学有余力的话，可以查看 checksum 校验和计算方式。
TTL（Time To Live）用于控制 IP 分组的 生命周期，发送方在发送 IP 分组时会设定一个 TTL 值，这个值是不固定的，但是一般是 32、64、128 或 255 这四个值中的一个。
当 IP 分组经过 路由器 时，路由器会自动 IP 分组中的 TTL 值减 1，路由器 发现其 TTL = 0，则路由器会 丢弃 该 IP 分组，并且返回一个 ICMP “Time Exceed” 消息。
在互联网早期，IP 地址采用了 分类寻址（Classful Addressing）。具体而言，就是根据 IP 地址的 网络号的前几位 将地址分为 A、B、C、D、E 五类。
在分类寻址中，如果给定一个 IP 地址，我们可以马上判断出该 IP 地址属于哪一类网络（根据前几位的值），以及该 IP 地址的 网络编号 和 主机编号 是多少。
| 类别 | 起始二进制 | 起始地址 | 结束地址 | 默认子网掩码 | 网络号长度 | 主机号长度 | 用途 | |
]]>源端口号（Source Port）：16 位字段，指示发送端的端口号。
目标端口号（Destination Port）：16 位字段，指示接收端的端口号。
序列号（Sequence Number）：32 位字段，用于标识 TCP 报文段中第一个数据字节的序列号。这个字段用于实现 TCP 的可靠性机制，如数据的按序传递和重传。
确认号（Acknowledgment Number）：32 位字段，如果设置了 ACK 标志位，该字段包含了期望接收的下一个数据字节的序列号。这个字段用于确认已经成功接收的数据。
首部长度（Header Length）：4 位字段，指示 TCP 首部的长度，以 32 位字为单位。这个字段用于指示首部的长度，因为 TCP 首部长度可以变化，根据选项的存在而变化。
保留（Reserved）：6 位字段，保留供未来使用，目前必须设置为 0。
控制标志位
（Flags）：TCP 报文段的控制标志，共有 6 个标志位，它们分别是：
窗口大小（Window Size）：16 位字段，指示发送端的可用接收窗口大小。接收端可以根据这个字段的值来告诉发送端可以发送多少数据而不会导致拥塞。
校验和（Checksum）：16 位字段，用于检测 TCP 首部和数据部分的传输中的错误。
紧急指针（Urgent Pointer）：16 位字段，仅当 URG 标志位设置时才有效。用于指示紧急数据的末尾位置。
选项（Options）：可选字段，用于包含一些额外的控制信息，如最大报文段长度、时间戳等。长度可变，最长可达 40 字节。
填充（Padding）：根据选项字段的长度而变化，用于确保 TCP 首部的总长度是 32 位的倍数。
源端口号（Source Port）：16 位字段，指示发送端的端口号。
目标端口号（Destination Port）：16 位字段，指示接收端的端口号。
序列号（Sequence Number）：32 位字段，用于标识 TCP 报文段中第一个数据字节的序列号。这个字段用于实现 TCP 的可靠性机制，如数据的按序传递和重传。
确认号（Acknowledgment Number）：32 位字段，如果设置了 ACK 标志位，该字段包含了期望接收的下一个数据字节的序列号。这个字段用于确认已经成功接收的数据。
首部长度（Header Length）：4 位字段，指示 TCP 首部的长度，以 32 位字为单位。这个字段用于指示首部的长度，因为 TCP 首部长度可以变化，根据选项的存在而变化。
保留（Reserved）：6 位字段，保留供未来使用，目前必须设置为 0。
控制标志位
（Flags）：TCP 报文段的控制标志，共有 6 个标志位，它们分别是：
窗口大小（Window Size）：16 位字段，指示发送端的可用接收窗口大小。接收端可以根据这个字段的值来告诉发送端可以发送多少数据而不会导致拥塞。
校验和（Checksum）：16 位字段，用于检测 TCP 首部和数据部分的传输中的错误。
紧急指针（Urgent Pointer）：16 位字段，仅当 URG 标志位设置时才有效。用于指示紧急数据的末尾位置。
选项（Options）：可选字段，用于包含一些额外的控制信息，如最大报文段长度、时间戳等。长度可变，最长可达 40 字节。
填充（Padding）：根据选项字段的长度而变化，用于确保 TCP 首部的总长度是 32 位的倍数。
TCP 通过 三次握手 建立连接，其具体过程如上图所示，每次握手的状态变化和字段解释如下：
第一次握手（客户端 → 服务端）
CLOSED → SYN-SENTSYN=1 的包，请求建立连接，并选择一个初始 序列号 seq = xLISTEN，等待连接第二次握手（服务端 → 客户端）
LISTEN → SYN-RECEIVEDSYN = 1：表示服务端也同意建立连接ACK = 1：确认客户端的 SYNseq = y：服务端自己的初始 序列号ack = x+1：确认号是客户端 序列号 + 1第三次握手（客户端 → 服务端）
SYN-SENT → ESTABLISHMENTACK = 1：确认服务端的 SYNack = y+1：确认号是服务端 序列号 + 1这三次握手的 主要目的 是：
第一次挥手：客户端发起关闭请求
ESTABLISHMENT → FIN-WAIT-1close()，客户端发送 FIN=1, seq=u，表示不再发送数据了，但仍可以接收数据第二次挥手：服务端确认关闭请求
ESTABLISHMENT → CLOSE-WAITFIN 后，发送 ACK=1, seq=v, ack=u+1 表示确认FIN-WAIT-1 → FIN-WAIT-2第三次挥手：服务端发起关闭请求
FIN=1, ACK=1, seq=w, ack=u+1CLOSE-WAIT → LAST-ACKFIN 报文后，进入 TIME-WAIT 状态第四次挥手：客户端确认服务端关闭
ACK=1, seq=u+1, ack=w+1TIME-WAIT → 等待 2 个最大报文生存时间（2×MSL）后 → CLOSEDCLOSED上图展示了 滑动窗口 的基本结构。滑动窗口其实是一个“移动的视口”，它同时描述了 发送方 正在等待确认的已发送数据，以及 接收方 已经接收并准备好继续接收的空闲空间。换句话说，窗口中的每一个字节都是当前正在传输的字节，它们在整个数据流中占据一个连续的区段。
可以把 TCP 发送的数据想象成一条无限长的字节流，每个字节在这条流中都有一个唯一的位置，这个位置就是绝对下标（absolute index）。它从连接开始不断递增，本质上是一个“不会回绕的理想编号”。
但 TCP 报文头部的 Sequence Number（seqno） 只有 32 位，因此它不可能直接表示这个无限增长的绝对位置，而是采用了一个取模映射的方式。
可以用一句话总结整个机制：
TCP 用 absolute index 管理真实的数据流顺序，用 seqno（32位） 在网络上传输，通过 滑动窗口的位置 消除回绕带来的歧义。
更具体地：
TCP 的 发送窗口 可以按照逻辑划分为四个部分：
其中第 2、3 个部分构成 TCP 的发送窗口，当发送方收到 ackno 在第 2 个部分内的确认报文时，调整滑动窗口的大小后向前移动滑动窗口，并且发送接下来可以发送的数据。
TCP 的 接收窗口 可以按照逻辑划分为四个部分：
在 TCP 传输过程中，窗口的概念决定了发送方能够“在等待确认之前”一次性发送多少数据。常见的窗口有三类：
下面分别说明这三种窗口的含义、它们是如何相互影响的，以及在 TCP 运行期间会受到哪些因素的调节。
TCP 可以看成在一条连续的字节流上维护一个“滑动窗口”，窗口表示当前允许发送且尚未确认的数据范围。
[左边界, 右边界)，并一次性发送窗口内的数据（按序列号对应的字节序列）。本质就是一句话：
ACK 推动窗口向前滑动，释放发送空间，从而实现连续高效的数据传输。
流量控制（TCP Transmission Control Protocol）是一种端到端的机制，旨在协调发送方和接收方之间的数据传输速率，防止接收方因处理能力或缓冲区限制而被压垮，从而避免数据包的丢失和重传。流量控制的核心目标是保证数据的可靠交付，同时尽可能高效地利用可用的网络带宽。
在 TCP 中，流量控制通过 滑动窗口机制 实现，具体过程如下：
需要注意的是，流量控制 关注的是单个连接内部的发送/接收平衡，而拥塞控制 则针对网络整体的拥塞状态（例如链路容量、路径上的竞争）进行调节，两者相互独立但常常协同工作，以实现端到端的可靠与高效传输。
TCP 的 可靠传输 通过多种机制共同实现，下文将对三个关键机制进行介绍。
序列号（seqno, sequence number）和 确认号（ackno, acknowledge number）是 TCP 首部的两个字段，TCP 协议通过 序列号 来记录目前已经发送了哪些数据，通过 确认号 记录哪些数据已经被接收方所接收。
发送方发送 序列号 和 接收方返回 确认号 的交互可能存在以下几种情况：
TCP 是一种 可靠传输协议，它要确保发送的数据 被对方接收并确认。但网络中可能发生：
为了应对这些情况，TCP 协议在发送一个 数据段（segment）时，会为每一个发送的 segment 设置一个 重传定时器。
如果某个 segment 的定时器超时了，就说明发送方在 超时时间阈值 内没有接收到该 segment 的确认，发送方就会触发 超时重传（Retransmission Timeout），重新发送超时的 segment。
TCP 首部包含一个 校验和（Checksum）字段，用于检测数据在传输过程中的任何变化。如果 接收方 检测到校验和错误，该数据段会被 丢弃，然后接收方会要求发送方 重传 该数据段。
TCP 的校验和计算方法和 IP 校验和计算方法 一致，不过两者校验的范围和目的有所不同。
其 IP 校验和只针对 IP 头部进行校验，主要用于检测数据在传输过程中由于网络故障等原因造成的错误。 而 TCP 校验和不仅要校验 TCP 头部，还要校验 TCP 载荷（即数据部分）。因此，TCP 校验和能提供 更全面的错误检测。
拥塞控制（tcp）指的是 tcp 限制传输数据的速率，进而防止注入过多的数据到网络中，进而造成网络链路过载。
大家需要了解，tcp 不是一个 “自私” 的算法，一段链路上可以同时包含很多 tcp 连接，tcp 的拥塞控制的目的是尽量去实现一个 总体的最优，而不是个体的最优。当 tcp 检测到数据传输出现拥塞之时，即一段时间内没有接收到一些确认，它就会降低自己传输数据的速率。
慢开始 是 TCP 连接开始时的一个阶段，相较于直接以较高的速率发送数据，慢开始会以一个较低的速率开始，然后 逐步试探 当前网络传输的能力，以指数的速率增加发送速率。慢开始的流程如下：
cwnd 设置为一个很小的值，通常是 1MSS （最大段大小）。ACK，cwnd 会增加一个 MSS。这意味着每个 RTT（往返时间）cwnd 都会翻倍，导致了指数增长。cwnd 达到 ssthresh（慢开始阈值）时，TCP 会从慢开始模式转换到拥塞避免模式。当 TCP 进入拥塞避免（Congestion Avoidance）阶段后，拥塞窗口（cwnd）的增长方式从慢启动的指数增长改为 线性增长。
具体来说：每收到一个 ACK，cwnd 增加 1/cwnd 个 MSS（最大报文段长度）。由于在一个往返时间（RTT）内会收到大约 cwnd 个 ACK，这等价于在每个 RTT 结束时 cwnd 只增长约 1 MSS。这种“每 RTT 加 1 MSS”的线性增长可以避免窗口迅速膨胀，引起网络拥塞。
TCP 通过两种方式 检测网络是否出现拥塞：
一旦检测到上述任意一种情况，TCP 认为网络已经发生拥塞，并执行如下处理：
ssthresh）设置为当前 cwnd 的 一半（ssthresh = cwnd / 2），以限制后续的窗口增长速度。cwnd 重新设为 1 MSS，相当于回到最保守的状态。通过上述线性增长与灵活的拥塞检测/恢复机制，TCP 能够在保持高吞吐量的同时，尽可能避免网络过载，从而实现可靠且高效的端到端传输。
在传统的 TCP 实现中，重传计时器负责触发超时重传：只要计时器到期而仍未收到对应的数据段的 ACK，发送方就会重新发送该段。在高带宽‑低时延的网络环境下，这种“等计时器”的方式往往效率低下，因为计时器的超时时间往往远大于实际的往返时延（RTT），导致数据恢复延迟。
在 快速重传（Fast Retransmission），当发送方 连续收到三个冗余的 ACK 时，说明网络中已经有一个 数据段丢失，而后续的 ACK 只能确认已经成功到达的后续段。此时，TCP 就会 立即重传 那个被认定为丢失的段，而不必等到重传计时器超时，这一过程被称为快速重传。
触发快速重传后，TCP 会切换到 快速恢复（Fast Recovery）阶段。该阶段的核心目标是：
在快速重传和快速恢复中，cwnd 的变化过程 如下：
快速重传触发后
ssthresh ← cwnd / 2cwnd ← ssthresh + 3·MSS快速恢复期间
（每收到一个重复 ACK）
cwnd ← cwnd + MSS退出快速恢复
（收到一个新的、非重复的 ACK）
cwnd ← ssthresh（即把窗口恢复到慢启动阈值）总结：
cwnd < ssthresh 时，使用 慢开始 算法，cwnd 以指数增长cwnd >= ssthresh 时，使用 拥塞避免 算法，cwnd 线性增长cwnd = ssthresh = cwnd / 2，开始使用拥塞控制算法ssthresh = cwnd / 2, cwnd = 1，开始使用 慢开始 算法cwnd 可能会减少（这里不考察）C/S（Client Server）模型：中心化、依赖服务器，适合稳定服务场景。
C/S（Client Server）模型：中心化、依赖服务器，适合稳定服务场景。
P2P（Peer to Peer）：分布式、节点平等，适合资源共享和去中心化场景。
场景：一套面向中小电商的订单中台，运营在群里提需求：「订单列表加个导出 Excel，每周都要用。」两周后是大促，研发只有前端 1 人、后端 1 人，本期 5 个工作日，权限模型不能动。
约束：
| 约束 | 具体内容 |
|---|---|
| 时间 | 5 个工作日内给出结论，做或不做都要有理由 |
| 人力 | 前端 1 人、后端 1 人，没有专职数据分析师 |
| 兼容 | 本期不能改角色与权限模型 |
| 历史 | 半年前做过「报表中心」，上线后月活不到 30 人 |
场景：一套面向中小电商的订单中台，运营在群里提需求：「订单列表加个导出 Excel，每周都要用。」两周后是大促，研发只有前端 1 人、后端 1 人，本期 5 个工作日，权限模型不能动。
约束：
| 约束 | 具体内容 | |
]]>场景：一款项目管理 SaaS，做了 4 年，只有一档价格：99 元/人/月，功能全包。近 12 个月新增付费客户数停滞，销售说「小团队嫌贵，大客户嫌便宜」。董事会要求 18 个月内现金流打平。
本案例是构造场景：客户数、金额、流失率都用于演示计算口径，不对应任何真实公司，比例也不要直接套用到别的业务。
约束：
| 约束 | 具体内容 |
|---|---|
| 数据 | 只有 12 个月的成交与流失记录，没有完整的获客渠道成本 |
| 人力 | 销售 3 人、客户成功 1 人，本期不能扩编 |
| 产品 | 6 个月内不改核心功能范围，只允许做权限与用量限制 |
| 合同 | 存量客户本期内不强制涨价，续费时才切换 |
场景：一款项目管理 SaaS，做了 4 年，只有一档价格：99 元/人/月，功能全包。近 12 个月新增付费客户数停滞，销售说「小团队嫌贵，大客户嫌便宜」。董事会要求 18 个月内现金流打平。
本案例是构造场景：客户数、金额、流失率都用于演示计算口径，不对应任何真实公司，比例也不要直接套用到别的业务。
约束：
| 约束 | 具体内容 | |
]]>下面用一套示例数据把流程走完。数字是示例，可直接复用的是步骤、判断口径和验收标准。
场景：一款团队协作工具，注册后 7 日留存从 31% 降到 22%。团队已经得出判断：「引导流程太长，用户没耐心。」两周后准备重做 onboarding。
约束：
| 约束 | 具体内容 |
|---|---|
| 时间 | 2 周内给出结论，赶在改版排期之前 |
| 人力 | 1 名研究员兼产品，没有专职数据分析师 |
| 技术 | 埋点已冻结，本迭代不能加新事件 |
| 预算 | 访谈礼金 14 份，问卷无付费样本渠道 |
| 目标 | 判断「重做引导」是否是对的方向，并给出可执行的改动清单 |
下面用一套示例数据把流程走完。数字是示例，可直接复用的是步骤、判断口径和验收标准。
场景：一款团队协作工具，注册后 7 日留存从 31% 降到 22%。团队已经得出判断：「引导流程太长，用户没耐心。」两周后准备重做 onboarding。
约束：
| 约束 | 具体内容 | |
]]>说明：以下为脱敏后的示例场景，客户与数字仅用于演示判断过程，不代表行业统计。
场景：一套 B 端协同产品，需求池积了 47 条。销售每天在群里催「这个客户要，那个客户也要」，团队上一季度按「谁催得急」排期，做了 12 个需求，收入没涨，新用户上手时间反而从 30 分钟涨到 45 分钟。
约束：
| 约束 | 具体内容 |
|---|---|
| 人力 | 前端 3 人、后端 3 人，本季度不能加人 |
| 容量 | 30% 人力用于线上维护与故障，可做新需求的只有约 70% |
| 周期 | 一个季度 3 个迭代，每个迭代 2 周 |
| 合同 | 2 家客户有定制条款，需在本季度给出处理方案 |
| 目标 | 需求池从 47 条收敛到可交付范围，并让销售能接受「不做」的理由 |
说明：以下为脱敏后的示例场景，客户与数字仅用于演示判断过程，不代表行业统计。
场景：一套 B 端协同产品，需求池积了 47 条。销售每天在群里催「这个客户要，那个客户也要」，团队上一季度按「谁催得急」排期，做了 12 个需求，收入没涨，新用户上手时间反而从 30 分钟涨到 45 分钟。
约束：
| 约束 | 具体内容 | |
]]>场景：一套仓储后台，仓库管理员在订单列表里逐条点「发货」。大促期间一天 300 单，点完要 40 多分钟，还经常点错行。客服转来需求原话：「能不能批量处理订单，现在一条条点太慢了。」
约束：
| 约束 | 具体内容 |
|---|---|
| 迭代 | 2 周一个迭代，本期只有 1 个迭代 |
| 人力 | 前端 1 人、后端 1 人、测试 1 人 |
| 范围 | 本期只做「批量发货」，批量取消、批量打印排后 |
| 兼容 | 订单状态机不能改，旧版列表页仍在使用 |
| 数据 | 单次最多 200 条，超过需提示分批 |
场景：一套仓储后台，仓库管理员在订单列表里逐条点「发货」。大促期间一天 300 单，点完要 40 多分钟，还经常点错行。客服转来需求原话：「能不能批量处理订单，现在一条条点太慢了。」
约束：
| 约束 | 具体内容 | |
]]>场景：一家做企业采购的团队，要把订单后台从「Excel + 聊天工具」迁进系统。本期只做一个模块：订单改价与批量导出。使用方是运营（发起改价）、财务（对账）、主管（审批）三类角色，日订单量在几千到一万之间（以实际数据为准）。
约束：
场景：一家做企业采购的团队，要把订单后台从「Excel + 聊天工具」迁进系统。本期只做一个模块：订单改价与批量导出。使用方是运营（发起改价）、财务（对账）、主管（审批）三类角色，日订单量在几千到一万之间（以实际数据为准）。
约束：
交付定义：开发能据此拆任务，测试能据此写用例，评审能据此做出「做 / 不做 / 砍什么」的决定。三者有一个不成立，文档就还没写完。
| 项 | 内容 | |
]]>场景：支付流程要改版，新增企业转账和拆单支付。上一次同类评审开了 90 分钟，结束时没有人说得清「到底定了什么」，开发按自己的理解做了两周，联调时才发现财务的对账口径没对齐。
本次约束：
场景：支付流程要改版，新增企业转账和拆单支付。上一次同类评审开了 90 分钟，结束时没有人说得清「到底定了什么」，开发按自己的理解做了两周，联调时才发现财务的对账口径没对齐。
本次约束：
目标：会议结束时，三个问题都有明确结论、有责任人、有复核时间；没结论的进入问题池并写清「缺什么信息」。
评审不是「讲一遍方案」，而是「收集反对意见并做决定」。所以会前第一件事不是写 PPT，而是把要决策的问题写成可选项。
| 待决问题 | 选项 | 推荐 | 影响 | |
]]>场景：一个 B 端协作 SaaS，免费版 + 按席位付费。最近两个季度 DAU 在涨，但付费转化和续费没有同步变化，客诉里「通知太多」的反馈变多。团队每天只看一张 DAU 曲线，老板要求下季度汇报一套能解释「增长来自哪里」的指标。
约束：
场景：一个 B 端协作 SaaS，免费版 + 按席位付费。最近两个季度 DAU 在涨，但付费转化和续费没有同步变化，客诉里「通知太多」的反馈变多。团队每天只看一张 DAU 曲线，老板要求下季度汇报一套能解释「增长来自哪里」的指标。
约束：
目标：产出一棵能落到 SQL 的指标树、一份口径字典、三层看板，以及「什么情况下停止推送」的决策规则。
指标不是越多越好，而是「为哪个决定服务」。先把要做的决定列出来，再倒推需要什么数。
| 决策 | 需要的指标 | 不需要的指标 | |
]]>场景：协作工具上线了「自动化规则」：当任务状态变化时，自动通知、自动建子任务。上线 4 周，周使用率很低（以实际数据为准，假设只有个位数百分比）。老板问：下个版本继续投入做模板和条件分支，还是把人力撤回去。
约束：
场景：协作工具上线了「自动化规则」：当任务状态变化时，自动通知、自动建子任务。上线 4 周，周使用率很低（以实际数据为准，假设只有个位数百分比）。老板问：下个版本继续投入做模板和条件分支，还是把人力撤回去。
约束：
约束带来的边界：只能回答 Web 用户里「不知道 / 不需要 / 不好用 / 没场景」的比例，答不了移动端有没有需求；没有对照组，就不能直接说功能带来了留存。
目标：不是证明「功能好不好」，而是回答「使用率低是因为不知道、不需要、不好用，还是没场景」，并给出继续/缩小/砍掉的决策和验证方式。
| 模糊问题 | 可回答的问题 | 需要的数 | |
]]>场景：一个审批流 SaaS，研发 12 人（8 开发、2 测试、1 设计、1 产品）。上季度路线图排了 12 个功能，实际完成 7 个；销售拿着路线图向客户承诺「下季度都有」，结果两次失信；团队连续加班，线上事故也变多。下季度不能再扩编，还要接两个大客户的定制诉求和一个合规改造节点。
约束：
场景：一个审批流 SaaS，研发 12 人（8 开发、2 测试、1 设计、1 产品）。上季度路线图排了 12 个功能，实际完成 7 个；销售拿着路线图向客户承诺「下季度都有」，结果两次失信；团队连续加班，线上事故也变多。下季度不能再扩编，还要接两个大客户的定制诉求和一个合规改造节点。
约束：
目标：产出一份「有目标、有分层、有缓冲、有砍单顺序」的路线图，以及一份销售能用的对外口径。
| 项 | 计算 | 结果 | |
]]>场景：一个 6 人团队（4 开发、1 测试、1 设计兼部分产品工作），连续 5 个迭代计划 10 个故事，实际完成 5–6 个。客户版本还有 3 周到期（约 1–2 个迭代），团队已经在连续加班，线上缺陷还在增加。
约束：
场景：一个 6 人团队（4 开发、1 测试、1 设计兼部分产品工作），连续 5 个迭代计划 10 个故事，实际完成 5–6 个。客户版本还有 3 周到期（约 1–2 个迭代），团队已经在连续加班，线上缺陷还在增加。
约束：
目标：先用 1–2 个迭代保住客户版本的核心范围，再用三个迭代让计划量与实际完成量基本对齐（通常以完成率 80% 以上为参考，按团队历史波动调整），不靠加班换速度。
| 指标 | 取法 | 现状（示例） | |
]]>场景：一家制造企业，集团加 3 个工厂、2 个售后团队，共约 1200 人（示例数据量）。工单现在靠 Excel 和邮件流转，采购已经选定一套多租户 SaaS 工单系统，要求 6 周上线，不改代码，只做配置。约束条件写在合同附件里：
场景：一家制造企业，集团加 3 个工厂、2 个售后团队，共约 1200 人（示例数据量）。工单现在靠 Excel 和邮件流转，采购已经选定一套多租户 SaaS 工单系统，要求 6 周上线，不改代码，只做配置。约束条件写在合同附件里：
目标不是「把功能做全」，而是产出一套可复用的权限模型、审批流和验收表。做完这一单，后面 20 个同行业客户只换组织树和阈值，不再开代码分支。
这一单的交付物固定为五份：组织与租户边界表、功能/数据/字段三张权限表、审批流配置表、迁移对账报告、验收记录。每份都要能被下一个人直接拿去复用，而不是只存在实施顾问的电脑里。
先做权限模型的原因：B 端项目最常见的返工不是功能少，而是权限太粗。第一版只有「管理员 / 普通用户」，第二个客户就会提出「销售只看自己、主管看团队、财务看全部但只能改金额」。一旦为客户写分支，后面每个客户都要维护一条分支，产品再也回不到主线。
动手前确认：组织架构表含汇报线；岗位清单与兼岗情况；旧系统字段、状态机、附件存放方式；客户编码规则；SSO 协议是 OIDC 还是 SAML；审计保留期限与导出要求。本节金额、阈值、比例均为示例。
下面出现的存储表与模型设计属于平台侧工作，不是为这个客户改代码；给客户交付时只动配置。两者混在一起看，容易把「产品要支持多租户」误解成「这一单要写多租户代码」。
先分清五个概念。它们经常被混成一张「部门表」，导致后面权限、报表、计费全部缠在一起。
| 概念 | 回答的问题 | 本项目的取值 | 变更频率 | |
]]>场景：一家做项目管理工具的 SaaS 公司，30 人，800 个付费租户，ARR 示例 1200 万元，MRR 示例 100 万元（年初），NRR 88%，毛利率 62.6%（均为示例）。现有计费只有一个维度：按席位 99 元/人/月（示例）。全年新签约约 128 个租户（月均约 11 个），但老客户降级与流失把新增吃掉，年末 MRR 只涨到 104 万元，一年增长 4%。
三个具体问题摆在桌面上：
场景：一家做项目管理工具的 SaaS 公司，30 人，800 个付费租户，ARR 示例 1200 万元，MRR 示例 100 万元（年初），NRR 88%，毛利率 62.6%（均为示例）。现有计费只有一个维度：按席位 99 元/人/月（示例）。全年新签约约 128 个租户（月均约 11 个），但老客户降级与流失把新增吃掉，年末 MRR 只涨到 104 万元，一年增长 4%。
三个具体问题摆在桌面上：
目标：8 周上线新计费系统；12 个月内 NRR 到 100% 以上、毛利率到 75%；老客户不立即涨价；账单必须能逐项复算。
先做收入拆解的原因：NRR 低有很多种原因，可能是获客不对、激活不足、降级、被动流失。不拆开就做「涨价」，往往会把还能救的客户先推走。
动手前确认：近 24 个月的合同、账单、收款流水；每个租户的席位、用量、工单量；云资源与第三方成本能否按租户归集；销售是否有私下折扣承诺。
要交付的五样东西：新价格书（三档 + 超额单价）、合同附件（计费单位、封顶、调价、数据导出）、可下钻的账单模板、老客户迁移方案、12 项验收清单。没有这五样，所谓「上线新计费」只是改了个价格页。
本节出现的金额、比例、折扣、套餐额度均为示例，只用于说明算法，不代表任何厂商的真实报价；实际数字以公司财务与合同为准。
MRR 不是「上月加本月新签」这么简单。期初与期末之间只有四个动作：新签、扩容、降级、流失。留存类指标（NRR、GRR）通常按 12 个月看，也可以按季度，但同一张报表里周期必须一致；下面这张桥是一年的桥，不能把月度数字直接当年度 NRR。
期初 MRR（年初） 100.0 万
+ 新签（New） +16.0 万 约 128 个租户 × ARPU 1250 元
+ 扩容（Expansion） +8.0 万
- 降级（Contraction） -8.0 万 约 32 个中客户
- 流失（Churn） -12.0 万 约 120 个租户 × ARPU 1000 元
= 期末 MRR（年末） 104.0 万
NRR = (100 + 8 - 8 - 12) / 100 = 88%
GRR = (100 - 8 - 12) / 100 = 80%注意 NRR 不含新签。新签是增长，不是留存；把新签算进 NRR，会让一条正在漏水的船看起来在加速。
| 指标 | 公式 | 回答的问题 | 本案例（示例） | |
]]>场景：一家 SaaS 公司的客服团队约 46 人（按满负荷折算），每月约 6 万次会话（示例），人工平均处理时长 8 分钟，人力成本按 1.2 万元/人月（示例）。老板给的目标很直接：「上大模型，替代一半人工。」团队已经试过两个模型，demo 效果不错，但没人能回答三个问题：哪些会话能交给模型、错误率到什么程度可以上线、每月最多花多少钱。
约束条件：
场景：一家 SaaS 公司的客服团队约 46 人（按满负荷折算），每月约 6 万次会话（示例），人工平均处理时长 8 分钟，人力成本按 1.2 万元/人月（示例）。老板给的目标很直接：「上大模型，替代一半人工。」团队已经试过两个模型，demo 效果不错，但没人能回答三个问题：哪些会话能交给模型、错误率到什么程度可以上线、每月最多花多少钱。
约束条件：
目标不是「上一个 AI 客服」，而是产出一张场景决策矩阵、一套评测集、一份成本测算表和一张上线门槛表。做完之后，老板能看到「能省多少、要花多少、风险在哪」，而不是只看一个 demo。
先做任务分层的原因：客服不是一个任务，是十几个意图的集合。密码重置和退款争议的错误成本差几个数量级，用同一个模型、同一个准确率指标去评估，结论一定是错的。
动手前确认：近 3 个月会话抽样；知识库文档的版本与权限；工单系统的转人工接口；模型服务的数据条款；客服团队谁能抽出两天做标注。本节金额、比例、阈值均为示例。
先按「意图」拆，不按「渠道」拆。渠道决定接入方式，意图决定能不能用 AI。
| 意图 | 占比 | 现有解决方式 | AI 适合度 | 错误成本 | 结论 | |
]]>场景：一个 AI 写作助手，月活 2 万，付费用户 3000，混合 ARPU 39 元/月（示例），月收入 11.7 万元。毛利率只有 42%，财务要求 4 周内看到成本结构，并把毛利率拉到 70% 以上。约束是不能降质量：盲测结果不差于基线（低 2 个百分点以内按抽样波动处理，超过即视为下降），事实错误率不能上升。
现有数据很粗：只记录了每天的总 token 数和模型账单，没有按任务、用户、租户归集。团队知道「模型贵」，但不知道贵在哪一类任务、哪一类用户，也不知道优化后会不会把质量改坏。
]]>场景：一个 AI 写作助手，月活 2 万，付费用户 3000，混合 ARPU 39 元/月（示例），月收入 11.7 万元。毛利率只有 42%，财务要求 4 周内看到成本结构，并把毛利率拉到 70% 以上。约束是不能降质量：盲测结果不差于基线（低 2 个百分点以内按抽样波动处理，超过即视为下降），事实错误率不能上升。
现有数据很粗：只记录了每天的总 token 数和模型账单，没有按任务、用户、租户归集。团队知道「模型贵」，但不知道贵在哪一类任务、哪一类用户，也不知道优化后会不会把质量改坏。
目标不是「换个便宜模型」，而是产出四样东西：任务单元定义、成本拆解表、分群成本表、质量回归门槛。做完之后，任何一次模型或 Prompt 改动，都能回答「成本降了多少、质量有没有掉、哪些用户在补贴哪些用户」。
先定义任务单元的原因：按「API 调用」算成本会漏掉重试、检索、后处理；按「用户」算又太粗，无法定位问题。只有按「一次完整生成」算，才能同时对上产品体验和财务账单。
动手前确认：近 60 天请求日志是否带 request_id；模型账单能否按日期与模型版本拆分；付费与免费用户的用量是否分开；有没有一套可复跑的质量评测集。
本节所有单价、用量、比例、门槛均为示例，只用于说明计算方法；模型单价、计费规则与缓存折扣以实际供应商账单为准。
一次「生成」不是一次模型调用。用户点一次「生成文案」，背后可能是：意图识别、大纲、正文、润色、事实校验，共 3 到 5 次调用。
| 层次 | 单位 | 用途 | |
]]>场景：一个多租户 SaaS 的报表模块，把「同步导出 Excel」改成「异步任务 + 完成后邮件与站内信通知」。改动跨前端导出按钮与进度页、后端新增 report_job 表、report 表加三个可空列、一个常驻 worker、一家第三方邮件服务。日活约 8000，付费客户 120 家。
约束（这些约束决定方案，不是背景装饰）：
| 约束 | 来源 | 对方案的影响 |
|---|---|---|
| 不能停机 | 客户 9:00–18:00 在用，合同 SLA 99.9% | 只能滚动发布，不开维护窗口 |
| 迁移只增不减 | 新列可空、有默认值，老代码能忽略 | 不删列、不改类型、不重命名 |
| 人力 4 人 | 1 运维、2 后端、1 前端 | 灰度压到 4 批，观察靠看板不靠人盯 |
| 3 家大客户要提前告知 | 合同写明重大变更提前 7 天 | 通知走客户成功，不走群公告 |
| 导出是高频动作 | 日均约 1.2 万次 | 出问题不是「少个功能」，是核心流程断 |
场景：一个多租户 SaaS 的报表模块，把「同步导出 Excel」改成「异步任务 + 完成后邮件与站内信通知」。改动跨前端导出按钮与进度页、后端新增 report_job 表、report 表加三个可空列、一个常驻 worker、一家第三方邮件服务。日活约 8000，付费客户 120 家。
约束（这些约束决定方案，不是背景装饰）：
| 约束 | 来源 | 对方案的影响 | |
]]>本文所有数字均为示例，仅用于说明口径与算法，以实际数据为准，不代表任何真实产品。
场景：一个协作笔记工具，月新增注册约 4 万（示例）。近 3 个月 7 日留存从 26.6% 掉到 19.4%，投放预算没变，但获客结构变了：信息流从 20% 升到 60%。管理层的要求是「下周就看到数字抬头」。
约束（决定了动作的优先级，不是背景）：
]]>本文所有数字均为示例，仅用于说明口径与算法，以实际数据为准，不代表任何真实产品。
场景：一个协作笔记工具，月新增注册约 4 万（示例）。近 3 个月 7 日留存从 26.6% 掉到 19.4%，投放预算没变，但获客结构变了：信息流从 20% 升到 60%。管理层的要求是「下周就看到数字抬头」。
约束（决定了动作的优先级，不是背景）：
| 约束 | 来源 | 对动作的影响 | |
]]>场景：一套跑了三年的工单系统，前端 4 人、后端 3 人，没有设计系统。37 个页面里数出 14 种字号、15 种间距、11 种灰色。设计师每开一张新稿都要重新决定「这里用几号字」，开发每接一个需求都要从截图里吸色。目标：两周内产出间距、字号、颜色三套 token，落成 CSS 变量，先覆盖工单列表、工单详情、新建工单、登录、报表 5 个页面。
约束：
场景：一套跑了三年的工单系统，前端 4 人、后端 3 人，没有设计系统。37 个页面里数出 14 种字号、15 种间距、11 种灰色。设计师每开一张新稿都要重新决定「这里用几号字」，开发每接一个需求都要从截图里吸色。目标：两周内产出间距、字号、颜色三套 token，落成 CSS 变量，先覆盖工单列表、工单详情、新建工单、登录、报表 5 个页面。
约束：
为什么先做这三套：颜色决定「能不能看清」，字号决定「能不能读到」，间距决定「能不能看出分组」。这三件事覆盖了日常返工的大头；圆角、阴影、动效可以后补，它们不影响信息是否可读。
交付物（5 项，缺一项不算完成）：
| # | 产出物 | 确认人 | |
]]>场景：一套 B 端审批系统的「新建审批」流程，上线半年，客服每周收到 20 多条「填不明白」的反馈。流程本身不复杂：选类型、填金额与事由、传附件、选审批人、提交。但用户会在某个字段卡住，反复提交失败，最后打电话问客服。产品经理的诉求是「把体验优化一下」，没有具体方向。
约束：
场景：一套 B 端审批系统的「新建审批」流程，上线半年，客服每周收到 20 多条「填不明白」的反馈。流程本身不复杂：选类型、填金额与事由、传附件、选审批人、提交。但用户会在某个字段卡住，反复提交失败，最后打电话问客服。产品经理的诉求是「把体验优化一下」，没有具体方向。
约束：
为什么用走查而不是直接改：「体验不好」是结论，不是问题。走查的价值是把「用户填不明白」拆成「哪个页面、哪一步、什么现象、违反哪条规律、证据是什么」，拆到能排期、能验收的粒度。
走查最怕范围失控。先把流程拆成三个用户任务，每个任务一条可判定的成功标准：
| 任务 | 起点 | 成功标准 | |
]]>场景：一套 API 调试工具，用户是后端与前端开发者，控制台平均每天使用 1–2 小时；另有一个官网负责获客。早期版本照着某开源项目抄了一套深色界面，结果控制台「看着像半成品」，官网「看着像内部工具」。品牌主色已经定了（蓝紫 #4F46E5），不能改。
约束：
场景：一套 API 调试工具，用户是后端与前端开发者，控制台平均每天使用 1–2 小时；另有一个官网负责获客。早期版本照着某开源项目抄了一套深色界面，结果控制台「看着像半成品」，官网「看着像内部工具」。品牌主色已经定了（蓝紫 #4F46E5），不能改。
约束：
为什么先定风格再定组件：组件的圆角、阴影、密度、字重全都由风格决定。先做组件再补风格，会出现「按钮是简约风、卡片是新粗野」的拼装感，返工成本更高。
风格不是选美，是在约束里找可行解。三项各打 1–5 分：
| 约束 | 问题 | 本案评分 | 推论 | |
]]>场景：一套内部采购系统，申请流程是「选类型 → 填明细 → 上传报价 → 选审批人 → 提交」。设计稿只有五张正常态页面，开发按图做完，上线后问题集中爆发：用户重复提交、审批人默认错、提交超时后不知道成没成、被驳回后要重填全部内容。产品要求「两周内把交互补全」，不改后端主流程。
约束：
场景：一套内部采购系统，申请流程是「选类型 → 填明细 → 上传报价 → 选审批人 → 提交」。设计稿只有五张正常态页面，开发按图做完，上线后问题集中爆发：用户重复提交、审批人默认错、提交超时后不知道成没成、被驳回后要重填全部内容。产品要求「两周内把交互补全」，不改后端主流程。
约束：
为什么要补交互说明：设计稿回答「长什么样」，不回答「什么条件下显示什么、点了发生什么、失败怎么办」。这些不写清楚，开发只能猜，测试也没法写用例，最后靠上线后收集投诉来补。
先不画界面，列出用户真正要完成的事：
| 任务 | 触发 | 成功标准 | 高频异常 | |
]]>场景：一套客服工单系统，列表页是使用频率最高的界面。设计稿只有一张「有数据」的图，开发照着做完，上线后问题不断：新用户进来看到空白，以为系统坏了；搜索无结果也显示「暂无数据」，用户不知道该清筛选；接口报错时页面一片白，客服只能刷新；没权限的账号看到空列表，反复找主管确认。
约束：
场景：一套客服工单系统，列表页是使用频率最高的界面。设计稿只有一张「有数据」的图，开发照着做完，上线后问题不断：新用户进来看到空白，以为系统坏了；搜索无结果也显示「暂无数据」，用户不知道该清筛选；接口报错时页面一片白，客服只能刷新；没权限的账号看到空列表，反复找主管确认。
约束：
为什么状态要先画：页面结构决定「信息放哪」，状态决定「没有信息时放什么」。只画有数据态，等于只设计了系统正常运行时的那一半。
工单列表是「集合视图 + 可批量操作」，所以骨架按列表页来：筛选区、批量操作栏、表格、分页。不要在这个页面里塞复杂表单，那是详情页或独立表单页的职责。
页面标题：工单列表 [导出] [新建工单]
├── 搜索框（工单号 / 标题 / 客户）
├── 常用筛选：状态下拉 · 优先级 · 负责人 · 时间范围
├── 更多筛选（折叠）：来源 · 标签 · SLA 状态
├── 批量操作栏（选中后出现）：已选 3 项 [批量分配] [批量关闭]
├── 表格
│ ├── 表头：勾选 · 工单号 · 标题 · 状态 · 优先级 · 负责人 · 更新时间 · 操作
│ ├── 数据行：可选中、行内操作不超过 3 个
│ └── 分页：共 1,204 条 · 20/页 · 跳到第 N 页
└── 空态 / 加载态 / 错误态（占据表格区域）骨架里要预留状态的位置。状态不是弹层，它占据表格区域，尺寸和表格一致，切换时页面不跳动。
六个基础状态，加三个叠加状态：
| # | 状态 | 触发条件 | 用户该看到什么 | |
]]>场景：一个 6 人前端团队维护的后台产品，40 多个页面，技术栈是 React + TypeScript + Ant Design（版本以团队和官方当前版本为准），设计侧用 Figma。当前状态：按钮有 7 种样式（3 种圆角、4 种蓝），弹窗有 3 套实现，表格分页有 4 种写法，每开一个新页面都要重新讨论一次标题字号。
约束：
场景：一个 6 人前端团队维护的后台产品，40 多个页面，技术栈是 React + TypeScript + Ant Design（版本以团队和官方当前版本为准），设计侧用 Figma。当前状态：按钮有 7 种样式（3 种圆角、4 种蓝），弹窗有 3 套实现，表格分页有 4 种写法，每开一个新页面都要重新讨论一次标题字号。
约束：
目标：拿到三个可交付的结果——一套能落地的 token、3 个高频组件的统一 API、一条能拦住新增硬编码的 CI 规则。组件数量不是目标。
交付物：
tokens/ 下三层 token（JSON 源文件 + 生成的 CSS 变量），每个变量有用途说明先量化「乱」在哪里，否则做完无法证明收益。
# 颜色硬编码分布
grep -rhoE '#[0-9a-fA-F]{3,8}' src --include='*.css' --include='*.scss' --include='*.tsx' \
| tr 'A-F' 'a-f' | sort | uniq -c | sort -rn | head -30
# AntD 组件直接引用量
grep -rn "from 'antd'" src --include='*.tsx' | wc -l
grep -rn "<Button" src --include='*.tsx' | wc -l
grep -rn "<Modal" src --include='*.tsx' | wc -l
# 疑似重复封装
find src \( -iname "*button*" -o -iname "*modal*" -o -iname "*table*" \) -print盘点的产出不是一份长报告，而是三张短表：
| 表 | 记录什么 | 用途 | |
]]>场景：一个 B2B SaaS 产品，后台是 Vite + React + CSS Modules + Ant Design 5，官网是 Next.js。设计侧在 Figma 里维护变量，代码侧有 73 种十六进制颜色、19 种间距、6 种圆角。深色模式是两年前手写的一套 .dark 覆盖，刷新时先白一下，弹窗和下拉菜单经常不跟随。
约束：
场景：一个 B2B SaaS 产品，后台是 Vite + React + CSS Modules + Ant Design 5，官网是 Next.js。设计侧在 Figma 里维护变量，代码侧有 73 种十六进制颜色、19 种间距、6 种圆角。深色模式是两年前手写的一套 .dark 覆盖，刷新时先白一下，弹窗和下拉菜单经常不跟随。
约束：
目标：建立一份 DTCG JSON 作为唯一来源，自动生成 CSS 变量、TypeScript 常量和 Tailwind 主题；三层 token 边界清楚；主题切换不闪白；存量代码按模块迁移。
交付物：
tokens/core.json：唯一来源，含三层 token 与别名tokens.css、tokens.ts、theme.css# 颜色硬编码分布
grep -rhoE '#[0-9a-fA-F]{3,8}' src --include='*.css' --include='*.tsx' \
| tr 'A-F' 'a-f' | sort | uniq -c | sort -rn | head -40
# 现有暗色覆盖的规模
grep -rn "data-theme\|\.dark" src/styles --include='*.css' | wc -l
# 内联颜色
grep -rnE 'style=\{\{[^}]*color' src --include='*.tsx' | wc -l盘点的结果要写成数字，不写感受：
| 项 | 盘点结果 | 结论 | |
]]>场景：一个中后台产品改版，40 个页面，2 名设计师、5 名前端，周期 7 周。设计侧 Figma 组件库有 68 个组件，代码侧是 Ant Design 5 加 41 个自研封装。上一次改版上线后走查记录 187 条偏差，返工 2 周，主要问题是颜色、圆角、hover 态和空态。
约束：
场景：一个中后台产品改版，40 个页面，2 名设计师、5 名前端，周期 7 周。设计侧 Figma 组件库有 68 个组件，代码侧是 Ant Design 5 加 41 个自研封装。上一次改版上线后走查记录 187 条偏差，返工 2 周，主要问题是颜色、圆角、hover 态和空态。
约束：
目标：在开发前建立一张可执行的映射表、一份缺项即打回的交接清单、一套三端共用的状态词表，把走查偏差压到 20 条以内。
前五步各占一周，交接与走查压在后两周；门禁不通过就退回补件，不进入开发队列。
# 代码侧组件使用量
grep -rhoE "<App[A-Z][A-Za-z]+" src --include='*.tsx' | sort | uniq -c | sort -rn
# 代码侧组件文件
find src/components -name "*.tsx" | wc -l
# 原生标签与第三方组件的残留
grep -rn "<table\|<button" src --include='*.tsx' | wc -l盘点的产出是一张差距表，不是组件清单：
| 项 | 数量 | 处理方式 | |
]]>场景：一套已上线的运营后台，12 个页面，全部由矩形和文字拼成。颜色直接填十六进制，同一档灰色出现了 6 个值；间距靠手动拖，按钮有 7 种圆角；没有任何组件。产品要求三周内加暗色模式，并在同一套稿上继续加 20 个页面。团队 1 名设计、2 名前端。
为什么必须做：按现状加暗色，等于把 12 页重画一遍；下一轮改主色，还要再改 40 多处。更麻烦的是，设计稿和代码各有一份色值，谁也说不清哪个是准的。这次改造的目标不是「把稿子画漂亮」，而是把文件变成改一处、全站生效的结构，并且这套结构能被下一个项目直接复制。
]]>场景：一套已上线的运营后台，12 个页面，全部由矩形和文字拼成。颜色直接填十六进制，同一档灰色出现了 6 个值；间距靠手动拖，按钮有 7 种圆角；没有任何组件。产品要求三周内加暗色模式，并在同一套稿上继续加 20 个页面。团队 1 名设计、2 名前端。
为什么必须做：按现状加暗色，等于把 12 页重画一遍；下一轮改主色，还要再改 40 多处。更麻烦的是，设计稿和代码各有一份色值，谁也说不清哪个是准的。这次改造的目标不是「把稿子画漂亮」，而是把文件变成改一处、全站生效的结构，并且这套结构能被下一个项目直接复制。
动手前确认：先复制一份文件做改造，原文件保留只读。改造期间新需求继续在原文件上做，避免两边同时改同一页。
① 盘点现状（半天）
不先数，就不知道要改多少。把五个数写进一张基线表，改造前后各记一次：
| 指标 | 改造前 | 目标 | 说明 | |
]]>场景：一套 B 端后台改版，5 个模块、18 个页面，1 名设计、2 名前端，周期 3 周。设计和开发在两个城市，只能异步沟通，每天最多一次 15 分钟站会。目标是上线前设计走查 P0 为 0、P1 不超过 5 条，且每条都能直接被开发修掉。
为什么必须做：上一版只往群里发了一个链接。开发做到一半来问「空态在哪」，走查时发现 3 个状态没做、12 处间距不是 token、2 个图标糊了，返工 4 天。问题不在设计画得不好，而在交付物没有把该说的说完。这次要把「开发来问」变成「开发查表」。
]]>场景：一套 B 端后台改版，5 个模块、18 个页面，1 名设计、2 名前端，周期 3 周。设计和开发在两个城市，只能异步沟通，每天最多一次 15 分钟站会。目标是上线前设计走查 P0 为 0、P1 不超过 5 条，且每条都能直接被开发修掉。
为什么必须做：上一版只往群里发了一个链接。开发做到一半来问「空态在哪」，走查时发现 3 个状态没做、12 处间距不是 token、2 个图标糊了，返工 4 天。问题不在设计画得不好，而在交付物没有把该说的说完。这次要把「开发来问」变成「开发查表」。
动手前确认：开发侧是否有 Dev Mode 席位和文件权限；组件库当前版本是否已发布；测试环境是否有真实数据；谁对「能不能上线」拍板。这四件事任何一件没确认，后面的节奏都会断。
① 启动对齐（第 1 天，90 分钟）
不是听产品讲需求，是把下面六件事逐条确认并写下来：
| 项 | 要问出的结果 | 没确认的后果 | |
]]>场景：一个电商站点，数据看板显示「进入结算 → 支付成功」的转化在收货地址这一步掉了 30%，但不知道原因。产品和设计各有一套猜测：有人说是地址表单字段太多，有人说是优惠券入口太显眼。决定用 5 名真实用户做一次形成性测试：准备 2 天、执行 2 天，最后一场结束后 48 小时内出报告。
为什么必须做：埋点只能告诉你「在哪一步掉」，不能告诉你「用户当时在想什么」。猜测驱动的改版很容易改错地方——把表单从 8 个字段减到 6 个，结果用户仍然卡在「区/县」的联动上。
]]>场景：一个电商站点，数据看板显示「进入结算 → 支付成功」的转化在收货地址这一步掉了 30%，但不知道原因。产品和设计各有一套猜测：有人说是地址表单字段太多，有人说是优惠券入口太显眼。决定用 5 名真实用户做一次形成性测试：准备 2 天、执行 2 天，最后一场结束后 48 小时内出报告。
为什么必须做：埋点只能告诉你「在哪一步掉」，不能告诉你「用户当时在想什么」。猜测驱动的改版很容易改错地方——把表单从 8 个字段减到 6 个，结果用户仍然卡在「区/县」的联动上。
约束：没有实验室，全部远程主持；用户分散在三个城市；不能装插件，只能用浏览器和系统录屏；每人 45 分钟；预算只够 5 人。约束越多，越要把任务和记录做扎实，而不是靠人数补。
动手前确认：录屏与录音的知情同意话术；测试账号能走通支付沙箱；每个用户一份独立优惠券；备用会议链接；一名记录员（主持人不兼记录）。
① 把模糊疑问改成可回答的研究问题（1 小时）
| 模糊疑问 | 改成研究问题 | 靠什么回答 | |
]]>场景：一套 B 端后台，采购合同要求「符合 WCAG 2.2 AA」。8 个核心页面要在两周内完成走查和第一轮修复，没有专职无障碍工程师：1 名设计师和 1 名前端各投入一半时间，QA 配合复测，合计约 11 人天。第一次自动化扫描报了 63 条，逐条修不现实。
为什么必须做：合同只是表面原因。客服近三个月反复收到「Tab 键没反应」「弹窗关不掉」的工单，说明键盘用户已经在流失。63 条里大量重复，真正影响任务的是少数几类。先按类修，再按条清，两周内才能看到可验证的改善。
]]>场景：一套 B 端后台，采购合同要求「符合 WCAG 2.2 AA」。8 个核心页面要在两周内完成走查和第一轮修复，没有专职无障碍工程师：1 名设计师和 1 名前端各投入一半时间，QA 配合复测，合计约 11 人天。第一次自动化扫描报了 63 条，逐条修不现实。
为什么必须做：合同只是表面原因。客服近三个月反复收到「Tab 键没反应」「弹窗关不掉」的工单，说明键盘用户已经在流失。63 条里大量重复，真正影响任务的是少数几类。先按类修，再按条清，两周内才能看到可验证的改善。
约束：不改整体视觉风格；不引入新框架；测试数据要覆盖空值、超长、无权限；读屏只有 macOS 的 VoiceOver 和 Windows 的 NVDA 可用。
动手前确认：浏览器矩阵；两个读屏工具能启动；测试账号覆盖管理员与只读角色；能造出空数据和错误状态；修复分支与发布窗口。
① 定范围与抽样（半天）
8 个页面要覆盖八类结构，不能只挑登录页：
| 类型 | 页面 | 为什么必须包含 | |
]]>场景：工单系统后台的「工单列表」页。桌面 1440 宽下是「左侧导航 240 + 筛选栏 280 + 表格 8 列」。业务要求同一套前端代码覆盖三类终端：桌面 1440（客服坐席）、平板 768（主管在会议室看进度）、手机 375（一线客服在外面处理紧急工单）。
约束：
| 约束 | 具体内容 | 影响 |
|---|---|---|
| 只有一套代码 | 不做独立 App，不做 m. 域名 | 布局必须靠 CSS 断点与结构替换 |
| 老组件库 | 表格组件不支持列隐藏配置 | 只能在页面层包一层 |
| 375 上的真实任务 | 只看「我的待办」并处理 | 批量操作、导出、报表一律不做 |
| 排期 | 设计 3 人天，前端 5 人天 | 不允许重做一套移动端页面 |
场景：工单系统后台的「工单列表」页。桌面 1440 宽下是「左侧导航 240 + 筛选栏 280 + 表格 8 列」。业务要求同一套前端代码覆盖三类终端：桌面 1440（客服坐席）、平板 768（主管在会议室看进度）、手机 375（一线客服在外面处理紧急工单）。
约束：
| 约束 | 具体内容 | 影响 | |
]]>场景：一套已上线两年的审批系统，桌面端是 1440 的三栏布局。业务要求「手机上能审批」，不做 App，只做 H5，嵌在企业微信工作台里。范围是 3 个页面 + 3 个浮层：待办列表、我的申请、审批详情，以及通过确认、驳回抽屉、更多操作。
约束：
| 约束 | 具体内容 | 设计上的后果 |
|---|---|---|
| 容器是企业微信 | 顶部有平台导航条，底部可能有平台工具栏 | 自己的导航只能从第二层开始 |
| 设备跨度 | 企业微信里 iOS 与 Android 都有，宽度从 320 到 430 | 按 375 出图，用 320 / 360 / 430 三档做极值检查 |
| 用户场景 | 会议间隙、通勤路上、被消息打断 | 必须支持中断恢复、单手操作 |
| 数据 | 单条审批最多 40 个字段，事由可能 500 字 | 详情必须分组折叠 |
| 交付 | 设计 4 人天，前端 6 人天 | 不引入新手势，不做自定义动画 |
场景：一套已上线两年的审批系统，桌面端是 1440 的三栏布局。业务要求「手机上能审批」，不做 App，只做 H5，嵌在企业微信工作台里。范围是 3 个页面 + 3 个浮层：待办列表、我的申请、审批详情，以及通过确认、驳回抽屉、更多操作。
约束：
| 约束 | 具体内容 | 设计上的后果 | |
]]>场景：订单中心改版，涉及 12 个页面（订单列表、订单详情、退款申请、退款审核、发货、物流、发票、售后记录等），前端已提测，计划 5 天后上线。设计只有 1 人，前端 3 人，测试 2 人。上次改版上线后视觉与交互问题集中爆发，这次要求「上线前一次走完，问题闭环」。
约束：
| 约束 | 具体内容 | 影响 |
|---|---|---|
| 时间 | 提测后、上线前，只有 3 个工作日 | 不能全量细查，必须分批 |
| 人力 | 设计 1 人、前端 3 人、测试 2 人 | 走查不能只靠设计 |
| 环境 | 测试环境数据是脱敏的旧数据 | 需要提前造边界数据 |
| 范围 | 12 个页面，含 4 个弹层流程 | 弹层必须单独看 |
| 标准 | 已有设计系统，但组件版本落后一版 | 部分偏差是系统问题，不是实现问题 |
场景：订单中心改版，涉及 12 个页面（订单列表、订单详情、退款申请、退款审核、发货、物流、发票、售后记录等），前端已提测，计划 5 天后上线。设计只有 1 人，前端 3 人，测试 2 人。上次改版上线后视觉与交互问题集中爆发，这次要求「上线前一次走完，问题闭环」。
约束：
| 约束 | 具体内容 | 影响 | |
]]>场景：一个 B2B SaaS 的试用注册页，从「进入注册页」到「注册成功」的转化率长期在 38% 左右。产品团队判断是「表单太长」，砍掉了「公司规模」「职位」两个字段，改版后转化率 39%，几乎没动。第二次改版前，要求先补齐埋点、用数据定位，再做一次可验证的实验。
约束：
| 约束 | 具体内容 | 影响 |
|---|---|---|
| 流量 | 日均进入注册页约 2400 人 | 大改动可分实验，小改动样本不够 |
| 埋点现状 | 只有页面曝光与「注册成功」，点击与失败原因全缺 | 必须补埋点，且要兼容历史数据 |
| 归因 | 多渠道投放，来源参数不统一 | 分群口径要先统一 |
| 排期 | 埋点 3 天，观察 2 周，实验 2 周 | 不能边改边看 |
| 合规 | 收集手机号、邮箱，需告知与脱敏 | 参数里不能带明文个人信息 |
场景：一个 B2B SaaS 的试用注册页，从「进入注册页」到「注册成功」的转化率长期在 38% 左右。产品团队判断是「表单太长」，砍掉了「公司规模」「职位」两个字段，改版后转化率 39%，几乎没动。第二次改版前，要求先补齐埋点、用数据定位，再做一次可验证的实验。
约束：
| 约束 | 具体内容 | 影响 | |
]]>场景：后台改版，工单列表的筛选从「常驻侧栏」改成「右侧抽屉」。第一版由前端随手实现：transition: all 0.3s linear，遮罩与抽屉同时开始、同时结束。上线后反馈集中在三点——「弹出来很生硬」「关的时候像卡了一下」「低端笔记本上会抖」。
约束：
| 约束 | 具体内容 | 影响 |
|---|---|---|
| 一套 token | 全站动效统一从变量取 | 不能给单个弹层写死数值 |
| 设备跨度 | 客服笔记本（集显）+ 设计部 MacBook | 必须按低端设备验收 |
| 同一组件复用 | 抽屉还用于「工单详情」「批量派单」 | 参数要覆盖三种内容量 |
| 可关闭 | 无障碍要求支持「减少动态效果」 | 必须有降级方案 |
| 排期 | 半天定参数，半天联调 | 不做复杂编排 |
场景：后台改版，工单列表的筛选从「常驻侧栏」改成「右侧抽屉」。第一版由前端随手实现：transition: all 0.3s linear，遮罩与抽屉同时开始、同时结束。上线后反馈集中在三点——「弹出来很生硬」「关的时候像卡了一下」「低端笔记本上会抖」。
约束：
| 约束 | 具体内容 | 影响 | |
]]>场景：一个运营了两年的 SaaS 后台，图标来自三个时期：早期从素材站下载的线性图标、一次改版引入的面性图标、开发临时用 emoji 顶替的状态图标。同一个页面里出现 4 种描边粗细、3 种风格、2 种尺寸，法务在版权审查时还发现部分素材授权不明。
约束：
| 约束 | 具体内容 | 影响 |
|---|---|---|
| 时间 | 两周内完成替换 | 不能逐个重画，只能选现成库 |
| 授权 | 必须可商用、可修改、允许闭源分发 | 排除仅限个人使用、要求界面署名的素材 |
| 技术栈 | React + SVG Sprite | 图标必须能被 currentColor 着色 |
| 覆盖面 | 现有 180 个图标，含 12 个业务专用图形 | 通用图标换库，专用图形自绘 |
| 兼容 | 需要支持深色模式 | 不允许导出多套配色 |
场景：一个运营了两年的 SaaS 后台，图标来自三个时期：早期从素材站下载的线性图标、一次改版引入的面性图标、开发临时用 emoji 顶替的状态图标。同一个页面里出现 4 种描边粗细、3 种风格、2 种尺寸，法务在版权审查时还发现部分素材授权不明。
约束：
| 约束 | 具体内容 | 影响 | |
]]>场景：花店「山野花房」要一个商品列表页：6 个在售商品、按关键词与分类筛选、每件商品能直接发起询价。没有构建工具、没有框架，交付 index.html + base.css + assets/，后端只给两个接口：GET /search 与 POST /api/inquiry。硬指标是断网、禁用 JS、只用键盘三种情况下页面都还能用。
为什么必须做：这一页把 HTML 的五个高风险区一次踩全——文档骨架、语义结构、图片替代文本、表单数据模型、原生校验。任何一处写错都不会报错，只会在上线后变成「搜索抓不到」「手机上字小得看不清」「后端收不到字段」这类没人认领的问题。
]]>场景：花店「山野花房」要一个商品列表页：6 个在售商品、按关键词与分类筛选、每件商品能直接发起询价。没有构建工具、没有框架，交付 index.html + base.css + assets/，后端只给两个接口：GET /search 与 POST /api/inquiry。硬指标是断网、禁用 JS、只用键盘三种情况下页面都还能用。
为什么必须做：这一页把 HTML 的五个高风险区一次踩全——文档骨架、语义结构、图片替代文本、表单数据模型、原生校验。任何一处写错都不会报错，只会在上线后变成「搜索抓不到」「手机上字小得看不清」「后端收不到字段」这类没人认领的问题。
动手前确认：Node 18+（跑校验器）、Chrome 或 Safari 当前稳定版、一个空目录。先建 shop/，后文所有相对路径都以它为根；图片用任意同比例 JPG 占位（复制改名即可），文件名与代码一致。
文件只有三类：index.html、base.css、assets/。assets/ 里 6 件商品各一对同图不同宽度的 JPG，下文以玫瑰为例：rose-400.jpg、rose-800.jpg，其余 5 件同理（lily-400.jpg 等）。
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>鲜花预订 | 山野花房</title>
<meta name="description" content="当季鲜花每周直采，北京同城次日达，支持到店自提。">
<link rel="stylesheet" href="base.css">
</head>
<body>
<a class="skip-link" href="#main">跳到主内容</a>
<!-- header / main / footer 见下面各段 -->
</body>
</html>四个位置不能动：<!DOCTYPE html> 在第一行；charset 在 head 最前面（必须落在文件前 1024 字节内）；viewport 紧跟其后；title 每页单独写。lang="zh-CN" 让读屏选中文语音、让浏览器判断断行与字体，不是装饰。
<header class="site-header">
<a class="brand" href="/">山野花房</a>
<nav aria-label="主导航">
<ul>
<li><a href="#goods">全部商品</a></li>
<li><a href="#filter">筛选</a></li>
<li><a href="#inquiry">询价</a></li>
</ul>
</nav>
</header>nav 只包主要导航，页脚的小链接组不必再套一个。锚点 #goods 的目标必须是页面里真实存在且唯一的 id。aria-label 在页面有多个导航区时才必要，写上便于以后扩展。
<main id="main">
<h1>当季鲜花</h1>
<p>每周一凌晨从昆明直采，北京同城次日达。</p>
<section id="goods" aria-labelledby="goods-title">
<h2 id="goods-title">本周在售</h2>
<ul class="goods">
<li>
<article class="card">
<img src="assets/rose-400.jpg"
srcset="assets/rose-400.jpg 400w, assets/rose-800.jpg 800w"
sizes="(min-width: 768px) 33vw, 100vw"
width="400" height="300" loading="lazy"
alt="深红色玫瑰，一束二十枝，牛皮纸包装">
<h3><a href="/goods/rose">赤霞玫瑰</a></h3>
<p>20 枝 / 束，花径约 6cm，附带保鲜剂。</p>
<p><data value="199">¥199</data> <del>¥259</del></p>
</article>
</li>
<!-- 其余 5 张结构相同，只换 src、srcset、alt、标题、价格 -->
</ul>
</section>
</main>三处决定成败：ul > li > article 是列表的标准结构，article 表示「单独拿出来也完整的一张商品卡」；width / height 写图片的原始像素尺寸，浏览器据此算出宽高比、提前占位，图片慢加载时页面不跳；alt 写「看到什么」，纯装饰花纹用 alt="" 明确让读屏跳过。
<section id="filter" aria-labelledby="filter-title">
<h2 id="filter-title">筛选</h2>
<form action="/search" method="get" role="search">
<p>
<label for="q">关键词</label>
<input type="search" id="q" name="q" placeholder="玫瑰 / 百合 / 满天星" autocomplete="off">
</p>
<p>
<label for="category">分类</label>
<select id="category" name="category">
<option value="">全部</option>
<option value="rose">玫瑰</option>
<option value="lily">百合</option>
</select>
</p>
<p>
<label for="max-price">最高价（元）</label>
<input type="number" id="max-price" name="max_price"
min="50" max="999" step="10" value="300">
</p>
<button type="submit">筛选</button>
<a href="/">清空条件</a>
</form>
</section>筛选是「读」操作，用 GET：参数进 URL，能收藏、能分享、刷新不重复提交。role="search" 让读屏把这块标成搜索区。清空条件用链接回 /，不用 type="reset"——reset 只回到 HTML 里写的默认值（最高价仍是 300），不是清空。
<section id="inquiry" aria-labelledby="inquiry-title">
<h2 id="inquiry-title">询价</h2>
<p id="inquiry-hint">提交后 2 小时内回电，仅工作日 9:00–18:00。</p>
<form action="/api/inquiry" method="post" enctype="multipart/form-data">
<fieldset>
<legend>联系方式</legend>
<p>
<label for="name">称呼</label>
<input type="text" id="name" name="name" required maxlength="20" autocomplete="name">
</p>
<p>
<label for="phone">手机号</label>
<input type="tel" id="phone" name="phone" required
inputmode="numeric" autocomplete="tel"
pattern="1[3-9][0-9]{9}" aria-describedby="phone-hint">
<small id="phone-hint">11 位中国大陆手机号，用于回电</small>
</p>
</fieldset>
<fieldset>
<legend>需求</legend>
<p>
<label for="item">商品</label>
<select id="item" name="item" required>
<option value="">请选择</option>
<option value="rose">赤霞玫瑰</option>
<option value="lily">白香水百合</option>
</select>
</p>
<p>
<label for="qty">数量（束）</label>
<input type="number" id="qty" name="qty" min="1" max="50" step="1" value="1" required>
</p>
<p>
<label for="ref">参考图</label>
<input type="file" id="ref" name="ref" accept="image/*">
</p>
<p>
<label for="note">备注</label>
<textarea id="note" name="note" rows="4" maxlength="300"
placeholder="卡片留言、忌用花材、配送时间"></textarea>
</p>
</fieldset>
<p>
<input type="checkbox" id="agree" name="agree" value="yes" required>
<label for="agree">同意仅将以上信息用于本次询价</label>
</p>
<input type="hidden" name="source" value="goods-list">
<button type="submit">提交询价</button>
<button type="reset">重填</button>
</form>
</section>表单四个固定件：action 决定去哪、method 决定怎么去、name 决定字段名、value 决定字段值。上传文件必须 enctype="multipart/form-data"，否则后端只收到文件名。required、type、min / max、pattern 由浏览器直接校验，不写 JS 也能拦住空值和格式错误。
<section aria-labelledby="spec-title">
<h2 id="spec-title">花材与养护</h2>
<table>
<caption>主要花材保鲜期（室温 20℃、每日换水）</caption>
<thead>
<tr><th scope="col">花材</th><th scope="col">瓶插期</th><th scope="col">换水频率</th></tr>
</thead>
<tbody>
<tr><th scope="row">玫瑰</th><td>5–7 天</td><td>每日</td></tr>
<tr><th scope="row">百合</th><td>7–10 天</td><td>每两日</td></tr>
<tr><th scope="row">满天星</th><td>10–14 天</td><td>每三日</td></tr>
</tbody>
</table>
</section>
<footer>
<address>
山野花房 · 北京市朝阳区某某路 1 号 ·
<a href="tel:+8613800000000">138‑0000‑0000</a> ·
<a href="mailto:hi@example.com">hi@example.com</a>
</address>
<p><small>© 2026 山野花房 · 京 ICP 备 00000000 号</small></p>
</footer><caption> 是表格标题，读屏进入表格会先念它；scope 告诉读屏表头在行上还是列上。<address> 只用于「最近的文章或整个页面的联系方式」，不是随便的地址文本。号码里的连字符写成 ‑（不换行连字符）：普通 - 会被当成换行点把号码拆开，html-validate 的 tel-non-breaking 规则也会直接报错。
base.css 只解决可读性与焦点可见，不承担设计：
*, *::before, *::after { box-sizing: border-box; }
body { max-width: 72ch; margin: 0 auto; padding: 24px 16px 64px;
font: 16px/1.6 system-ui, -apple-system, "PingFang SC", sans-serif; color: #1f2937; }
img { max-width: 100%; height: auto; }
.skip-link { position: absolute; left: 16px; top: -48px; padding: 8px 12px; background: #fff; }
.skip-link:focus { top: 8px; }
:focus-visible { outline: 2px solid #1a73e8; outline-offset: 2px; }
label { display: block; margin-top: 8px; }cd shop
python3 -m http.server 8000 # 打开 http://localhost:8000
npx --yes html-validate@9.7.1 index.html && echo "exit=$?"@9.7.1 写死版本：html-validate 的规则集随小版本变化，今天报 0 条不保证半年后还是 0 条，验收要可复现。
必须用 http:// 打开，不要双击 file://：相对路径行为不同，fetch 与部分表单提交也会被浏览器拦。
python3 -m http.server 只是静态服务器，没有 /search 与 /api/inquiry：提交筛选后地址栏会变成 /search?... 但页面 404，询价提交会得到 501（POST 不被支持）。这是预期结果，验收只看 URL 查询串与 Network → Payload；要联调再起一个能响应这两个路径的后端桩。
| # | 检查项 | 命令或检查 | 通过标准 | |
]]>场景：一个 8 人 SaaS 团队的后台首页：顶部栏、左侧菜单、4 张指标卡、一张最近订单表。不用 UI 库、不用框架，交付 admin.html + admin.css，要求 360px 手机、768px 平板、1440px 桌面三档都成立；跟随系统深浅色；键盘能走完全程；用户开启「减少动态效果」时不做位移动画。
为什么必须做：后台页面最容易死在「数据一多就撑破」「手机上表格把整页顶宽」「深色模式下一块白底刺眼」这三件事上。它们都不是某个属性写错，而是布局模型、层叠规则、主题变量没有一起设计。这一节把这三件事一次做完，后面加页面只需复用变量与骨架。
]]>场景：一个 8 人 SaaS 团队的后台首页：顶部栏、左侧菜单、4 张指标卡、一张最近订单表。不用 UI 库、不用框架，交付 admin.html + admin.css，要求 360px 手机、768px 平板、1440px 桌面三档都成立；跟随系统深浅色；键盘能走完全程；用户开启「减少动态效果」时不做位移动画。
为什么必须做：后台页面最容易死在「数据一多就撑破」「手机上表格把整页顶宽」「深色模式下一块白底刺眼」这三件事上。它们都不是某个属性写错，而是布局模型、层叠规则、主题变量没有一起设计。这一节把这三件事一次做完，后面加页面只需复用变量与骨架。
动手前确认：Chrome 或 Safari 当前稳定版、DevTools 的设备模式与 Rendering 面板（模拟 prefers-color-scheme 与 prefers-reduced-motion）。先把内容写进 HTML，再按「骨架 → 区块 → 响应式 → 主题」的顺序加 CSS。
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>AdminPro · 仪表盘</title>
<link rel="stylesheet" href="admin.css">
</head>
<body>
<a class="skip-link" href="#main">跳到主内容</a>
<div class="layout">
<header class="topbar">
<div class="topbar__brand">AdminPro</div>
<h1 class="topbar__title">仪表盘</h1>
<div class="topbar__user">
<span class="topbar__avatar">张</span>
<span class="topbar__name">张伟</span>
</div>
</header>
<aside class="sidebar">
<nav aria-label="侧边导航">
<ul class="sidebar__menu">
<li><a class="sidebar__link is-active" href="#" aria-current="page">仪表盘</a></li>
<li><a class="sidebar__link" href="#">订单管理</a></li>
<li><a class="sidebar__link" href="#">用户管理</a></li>
<li><a class="sidebar__link" href="#">系统设置</a></li>
</ul>
</nav>
</aside>
<main class="content" id="main">
<section class="stats" aria-label="关键指标">
<article class="stat-card"><p class="stat-card__label">今日订单</p><p class="stat-card__value">1,280</p><p class="stat-card__trend stat-card__trend--up">↑ 12.5%</p></article>
<article class="stat-card"><p class="stat-card__label">销售额</p><p class="stat-card__value">¥86,400</p><p class="stat-card__trend stat-card__trend--up">↑ 8.2%</p></article>
<article class="stat-card"><p class="stat-card__label">新增用户</p><p class="stat-card__value">312</p><p class="stat-card__trend stat-card__trend--down">↓ 3.1%</p></article>
<article class="stat-card"><p class="stat-card__label">转化率</p><p class="stat-card__value">4.8%</p><p class="stat-card__trend stat-card__trend--up">↑ 0.6%</p></article>
</section>
<section class="table-panel">
<h2 class="table-panel__title">最近订单</h2>
<div class="table-wrap">
<table class="data-table">
<thead><tr><th>订单号</th><th>客户</th><th>金额</th><th>状态</th><th>时间</th></tr></thead>
<tbody>
<tr><td>#20260001</td><td>李娜</td><td>¥1,299</td><td><span class="tag tag--success">已完成</span></td><td>10-11 09:32</td></tr>
<tr><td>#20260002</td><td>王强</td><td>¥399</td><td><span class="tag tag--pending">待发货</span></td><td>10-11 10:05</td></tr>
<tr><td>#20260003</td><td>赵敏</td><td>¥2,680</td><td><span class="tag tag--warning">售后中</span></td><td>10-11 10:48</td></tr>
<tr><td>#20260004</td><td>陈晨</td><td>¥899</td><td><span class="tag tag--success">已完成</span></td><td>10-11 11:12</td></tr>
<tr><td>#20260005</td><td>周涛</td><td>¥5,299</td><td><span class="tag tag--pending">待发货</span></td><td>10-11 11:40</td></tr>
<tr><td>#20260006</td><td>吴敏</td><td>¥268</td><td><span class="tag tag--warning">售后中</span></td><td>10-11 12:03</td></tr>
<tr><td>#20260007</td><td>郑凯</td><td>¥1,680</td><td><span class="tag tag--success">已完成</span></td><td>10-11 12:26</td></tr>
<tr><td>#20260008</td><td>孙丽</td><td>¥76</td><td><span class="tag tag--pending">待发货</span></td><td>10-11 13:05</td></tr>
</tbody>
</table>
</div>
</section>
</main>
</div>
</body>
</html>以上 HTML 与后面的 CSS 片段合起来就是完整交付：把 1.2–1.9 的代码按编号顺序粘进同一个 admin.css，与 admin.html 放在同一目录，双击打开或用 npx --yes serve . 起一个静态服务即可验收。片段之间有覆盖关系（例如 .content 的 padding 由断点接管），顺序不能调换。
所有颜色、圆角、间距先收进自定义属性。组件只引用变量，不写死颜色，主题切换才有落点。
:root {
color-scheme: light dark;
--c-bg: #f3f4f6; --c-surface: #ffffff;
--c-text: #1f2937; --c-muted: #6b7280;
--c-border: #e5e7eb; --c-primary: #1a73e8;
--c-primary-weak: rgba(26, 115, 232, 0.12);
--c-success: #047857; --c-danger: #b91c1c; --c-warning: #92400e;
--radius: 10px;
--shadow: 0 1px 3px rgba(0, 0, 0, 0.08);
--topbar-h: 56px; --sidebar-w: 220px; --gap: 16px;
}
@media (prefers-color-scheme: dark) {
:root {
color-scheme: dark;
--c-bg: #0f172a; --c-surface: #1e293b;
--c-text: #e2e8f0; --c-muted: #94a3b8;
--c-border: #334155; --c-primary: #7cb0ff;
--c-primary-weak: rgba(124, 176, 255, 0.16);
--c-success: #6ee7b7; --c-danger: #fca5a5; --c-warning: #fcd34d;
--shadow: 0 1px 3px rgba(0, 0, 0, 0.4);
}
}color-scheme 让滚动条、输入框、日期选择器跟随深浅色；只改自定义属性而不写它，原生控件仍会是白底。
*, *::before, *::after { box-sizing: border-box; }
html { -webkit-text-size-adjust: 100%; }
body {
margin: 0; min-height: 100svh;
background: var(--c-bg); color: var(--c-text);
font: 0.875rem/1.6 system-ui, -apple-system, "PingFang SC", "Microsoft YaHei", sans-serif;
}
h1, h2, h3, p, ul { margin: 0; }
ul { padding: 0; list-style: none; }
a { color: inherit; text-decoration: none; }
img, svg { display: block; max-width: 100%; }
button, input, select, textarea { font: inherit; color: inherit; }
:focus-visible { outline: 2px solid var(--c-primary); outline-offset: 2px; }body 的 font 简写同时设定字号与行高；button 不会自动继承字体，必须单独声明，否则按钮文字会变成浏览器默认的 13px 系统字体。
.layout {
display: grid;
grid-template-columns: minmax(0, 1fr);
grid-template-rows: var(--topbar-h) auto 1fr;
grid-template-areas: "topbar" "sidebar" "content";
min-height: 100svh;
}
.topbar { grid-area: topbar; }
.sidebar {
grid-area: sidebar;
background: var(--c-surface); border-bottom: 1px solid var(--c-border);
overflow-x: auto;
}
.sidebar__menu { display: flex; gap: 4px; padding: 8px 12px; }
.content {
grid-area: content;
display: grid; gap: var(--gap); align-content: start;
padding: 16px;
}
@media (min-width: 768px) {
.layout {
grid-template-columns: 180px minmax(0, 1fr);
grid-template-rows: var(--topbar-h) 1fr;
grid-template-areas: "topbar topbar" "sidebar content";
}
.sidebar { border-right: 1px solid var(--c-border); border-bottom: 0; overflow: visible; }
.sidebar__menu { flex-direction: column; padding: 12px; }
.content { padding: 20px; }
}
@media (min-width: 1200px) {
.layout { grid-template-columns: var(--sidebar-w) minmax(0, 1fr); }
.content { padding: 28px 32px; gap: 24px; }
}手机端不是把侧栏藏起来，而是把它变成顶栏下方的一排横向滚动菜单——纯 CSS 就可用，不需要一个点了没反应的 ☰ 按钮。minmax(0, 1fr) 防止内容的最小宽度把网格列撑破。
.topbar {
display: flex; align-items: center; gap: 12px;
height: var(--topbar-h); padding: 0 16px;
background: var(--c-surface); border-bottom: 1px solid var(--c-border);
}
.topbar__brand { font-weight: 700; color: var(--c-primary); letter-spacing: 0.3px; }
.topbar__title { font-size: 0.9375rem; font-weight: 500; color: var(--c-muted); }
.topbar__user { display: flex; align-items: center; gap: 8px; margin-left: auto; }
.topbar__avatar {
display: inline-flex; align-items: center; justify-content: center;
width: 30px; height: 30px; border-radius: 50%;
background: var(--c-primary); color: var(--c-surface); font-size: 0.8125rem;
}
@media (max-width: 479px) { .topbar__name { display: none; } }margin-left: auto 把用户区推到最右，比 justify-content: space-between 更灵活：前者只吃左侧剩余空间，后者会把所有项目分成两组推向两端。
顶栏这里不写 position: sticky：它只占 56px 的网格行，粘性元素在自己的包含块里没有可移动距离，写了也不会吸顶。确实要固定顶栏，就把它移出 .layout，或改用 position: fixed 并给内容补上 padding-top。
.stats {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(150px, 1fr));
gap: 12px;
}
.stat-card {
padding: 16px; background: var(--c-surface);
border: 1px solid var(--c-border); border-radius: var(--radius); box-shadow: var(--shadow);
}
.stat-card__label { color: var(--c-muted); font-size: 0.8125rem; }
.stat-card__value { margin: 4px 0; font-size: 1.5rem; font-weight: 700; line-height: 1.3; font-variant-numeric: tabular-nums; }
.stat-card__trend { font-size: 0.75rem; }
.stat-card__trend--up { color: var(--c-success); }
.stat-card__trend--down { color: var(--c-danger); }
@media (min-width: 1200px) {
.stats { grid-template-columns: repeat(4, minmax(0, 1fr)); }
}auto-fill + minmax(150px, 1fr) 让 360px 宽排 2 列、平板排 3 列；桌面在 1200px 断点显式固定四列，因为同样的宽度 auto-fill 会排出 5 列。这条覆盖必须写在本节 .stats 基础样式之后，否则基础样式反而把它盖掉。align-content: start 防止内容不满一屏时被 Grid 拉伸摊开。
.table-panel {
background: var(--c-surface); border: 1px solid var(--c-border);
border-radius: var(--radius); box-shadow: var(--shadow); overflow: hidden;
}
.table-panel__title { padding: 14px 16px; font-size: 0.9375rem; font-weight: 600; border-bottom: 1px solid var(--c-border); }
.table-wrap { max-height: min(60vh, 360px); overflow: auto; }
.data-table { width: 100%; min-width: 520px; border-collapse: separate; border-spacing: 0; }
.data-table th, .data-table td {
padding: 12px 16px; text-align: left; white-space: nowrap;
border-bottom: 1px solid var(--c-border);
}
.data-table thead th {
position: sticky; top: 0; z-index: 1;
background: var(--c-bg); color: var(--c-muted);
font-weight: 500; font-size: 0.8125rem;
}
.data-table tbody tr:hover { background: var(--c-bg); }
.data-table tbody tr:last-child td { border-bottom: 0; }
.tag { display: inline-block; padding: 2px 10px; border-radius: 999px; font-size: 0.75rem; }
.tag--success { background: rgba(16, 185, 129, 0.16); color: var(--c-success); }
.tag--pending { background: var(--c-primary-weak); color: var(--c-primary); }
.tag--warning { background: rgba(217, 119, 6, 0.16); color: var(--c-warning); }table-wrap 同时承担两件事：窄屏横向滚动，以及给表头的 position: sticky 提供滚动容器。表头必须有不透明背景，否则数据行会从下面透出来；表头用 border-collapse: separate 配 border-spacing: 0，避免 collapse 下合并边框由表格绘制、滚动时与单元格错位。min-width 取 520px：768px 档的内容区约 548px，正好放得下，360px 档则必然横向滚动。示例给了 8 行数据，容器高度封顶到 360px，所以纵向一定出现滚动，第 6 项验收才有得看。
.sidebar__link {
display: block; padding: 7px 12px; border-radius: 999px;
color: var(--c-muted); white-space: nowrap;
transition: background 0.15s ease, color 0.15s ease;
}
.sidebar__link:hover { background: var(--c-bg); color: var(--c-text); }
.sidebar__link.is-active { background: var(--c-primary-weak); color: var(--c-primary); font-weight: 500; }.sidebar 与 .sidebar__menu 的底色、边框、横排样式放在 1.4 的断点之前，桌面端那两条覆盖才压得住：同特异性下后写的赢，顺序一颠倒，桌面侧栏就会多出一条下边框和横向滚动。
选中态用 .is-active 与 aria-current="page" 双标记：前者给眼睛，后者给读屏。只改颜色不够，色弱用户可能分不出选中项。
.skip-link {
position: fixed; left: 16px; top: -48px; z-index: 100;
padding: 8px 12px; background: var(--c-surface);
border: 1px solid var(--c-border); border-radius: 8px;
}
.skip-link:focus { top: 8px; }
@media (prefers-reduced-motion: no-preference) {
.stat-card { transition: transform 0.18s ease, box-shadow 0.18s ease; }
.stat-card:hover { transform: translateY(-2px); box-shadow: 0 8px 24px rgba(0, 0, 0, 0.12); }
}把动效写进 no-preference 而不是在 reduce 里逐个关掉：默认无动画，用户允许时才加。这比 animation: none !important 干净，也不会漏掉后来新增的动画。
| # | 检查项 | 命令或检查 | 通过标准 | |
]]>