企业官网建设流程全解析

1. 段页式到底解决什么问题

段页式内存管理这个题目，我第一次接触是在操作系统的课堂上，练习册里编号 4.3 的那道题。当时前面刚学完分页和分段，脑子里还残留着页表和段表两套公式，结果一看到题目里同时出现段号和页号，直接懵了——一个逻辑地址要被切成三块，还得先查段表再查页表，最后才算是摸到物理内存的边。后来工作里做性能调优、翻内核文档，才发现这套东西不是课本为了考试硬凑出来的，它是真实存在过的内存管理方案，32 位保护模式下的地址翻译就是段式和分页叠在一起跑的。

这篇东西我想按自己当年啃它的顺序写：先说清楚它为什么要被设计出来，再说数据结构长什么样、地址怎么一步步翻译过去，然后拿几道典型题手算一遍，最后用 Python 把整个过程模拟出来。如果你正在准备操作系统期末或者考研 408，可以直接照着算例对照；如果你已经工作，只是想搞明白 CPU 到底怎么把虚拟地址变成物理地址，那第 6 节关于真实机器那部分对你更有用。

1.1 分页和分段各自的强项与软肋

先把两套方案摆在一起看。分页的核心动作是把物理内存和逻辑地址空间都切成固定大小的块，块大小由硬件定死，常见的就是 4KB。它的好处很直接：内存分配以页为单位，任何空闲页都能塞给任何进程，外部碎片基本被消灭，只剩最后一页的内部碎片，平均浪费半页。但这个"整齐"是有代价的——程序被机械地切开，一个函数和它用不到的数据可能被塞进同一页，逻辑上的边界完全被抹掉了。想共享一段代码？只要那段代码不是刚好整页对齐，就得处理跨页问题。想给某段代码单独设个只读权限？做不到精细控制。

分段走的是另一条路，它按程序的自然逻辑单位来切：主函数一个段、全局变量一个段、栈一个段、动态库一个段。段的长度不固定，由编译器根据内容决定。这么切的好处是共享和保护都变得自然——整个代码段可以直接在多个进程的段表里指向同一块物理内存，权限位写在段表项里，读写执行一目了然。而且段可以动态增长，堆区不够了就往外扩，边界检查只需要比对段长。

问题也很明显：段长不固定意味着内存分配变成了一个动态适配问题，从一堆大小不一的空洞里找一个能装下这段的洞，装完之后剩下的碎片大小随机，时间一长就会碎成一地，这就是典型的外部碎片。虽然可以用紧凑技术把空闲区合并，但移动内存里的段意味着要修改所有引用它的地址，代价高得离谱。所以纯分段在现代系统里基本退出了主舞台。

1.2 段页式是怎么把两者拼起来的

段页式的思路其实特别朴素：既然分段在逻辑层面好用、分页在物理层面好用，那就让它们各管一头。作业还是先按逻辑单位分成若干个段，但每个段内部不再要求连续存放，而是再切成固定大小的页，页可以散落在物理内存的任意位置。

这样一来，物理内存的分配单位始终是页，外部碎片的问题被分页解决掉了；而段的逻辑边界保留了下来，共享和权限控制可以挂在段这一层做。段内逻辑上是连续的，段间不要求连续——这正好贴合程序的实际访问模式：代码段内部顺序执行，跳转大多发生在段内或者少数几个固定段之间。

代价是地址翻译的层数多了一层。原来分页只要查一次页表，分段只要查一次段表，现在要先查段表拿到这个段的页表在哪，再查页表拿到物理块号，最后拼上页内偏移。逻辑地址的结构也从两段变成了三段：

逻辑地址 = 段号 | 页号 | 页内偏移

这个"三段式"是段页式所有考点和所有坑的源头。你后面遇到的绝大部分错误，都出在对这三段的划分上。

1.3 组合之后付出的代价

天下没有白拿的好处。段页式把两套机制叠起来，代价主要体现在三个地方。

第一是访存次数。不加任何缓存的话，一次数据访问要先读段表、再读页表、最后读数据，三次访问物理内存。如果段表项或者页表项本身还不在内存里，那还得先处理缺页，次数继续往上翻。这就是为什么 TLB（快表）在这套体系里几乎是必需品——它把最近用过的段页映射结果缓存下来，命中之后换算只需要一次访存。

第二是数据结构的维护成本。每个进程需要一张段表，每个段需要一张页表，页表的大小跟段长成正比。段表寄存器指向段表起始地址，段表项里存着段长和该段页表的起始地址。这些结构本身也占内存，而且它们的创建、销毁、缺页时的换入换出，都要操作系统内核来操心。

第三是实现的复杂度。硬件需要支持两级或者更多级的查表流程，操作系统需要同时管理段表和页表两套结构的生命周期，还要处理两级保护检查（段级权限 + 页级权限）。这也是为什么后来的系统更倾向于只保留分页、把分段的逻辑保护功能用别的方式实现。

2. 核心数据结构与地址转换全流程

2.1 段表、页表、页表项里都存了什么

段表是每个进程一张，它的下标就是段号，第 i 项描述第 i 个段。一个典型的段表项包含这几样：段长（注意单位，通常用页数而不是字节数，这是易错点）、该段页表的起始地址（物理地址）、以及访问权限位（可读、可写、可执行）、存在位（该段是否已调入内存）、修改位和访问位（供置换算法使用）。段表寄存器里存放两个东西：段表起始地址和段表长度。前者用来定位，后者用来做段号越界检查——段号大于等于段表长度就直接触发越界中断，连查表都不用。

页表是每个段一张，下标是页号，第 j 项描述该段的第 j 页。页表项里最主要的是物理块号（也叫页框号、帧号），此外还有有效位、修改位、访问位、权限位、是否在磁盘上等等。页表的起始地址不放在别处，就放在对应段表项的那个字段里——这是段页式跟纯分页最大的结构差异，纯分页的页表基址放在专门的寄存器（比如 CR3）里，段页式则是"每个段自带页表"。

这里有个细节值得单独拎出来说：段表项里的段长用页数表示。假设段长字段是 20 位、能表示的最大页数是 2²⁰，页面大小 4KB，那这个段最大就是 4GB。有些题目会说"段长为 4MB"，你要自己换算成页数：4MB ÷ 4KB = 1024 页。如果题目给的段长已经是页数，那就直接比对，不用换算。这个换算我当年错过不止一次，后面在 5.1 节专门写。

2.2 逻辑地址的位段划分与三大尺寸计算

段页式的题目里有一大半是算位数。规律很固定，只要抓住两个公式：

• 页内偏移位数 = log₂(页面大小)
• 页号位数 = log₂(每段最大页数) = log₂(段最大长度 ÷ 页面大小)
• 段号位数 = 逻辑地址总位数 − 页号位数 − 页内偏移位数

反过来也成立：知道了各段的位数，就能推出系统支持的最大段数、每段最大长度和最大总空间。

举几个常见的组合感受一下：

注意看第一行和第二行的差别：页面大小没变，但页号多给了 2 位，每段最大长度就从 4MB 涨到 16MB，代价是段号只剩 8 位，整个系统最多 256 个段。总位数是守恒的，页号和段号是此消彼长的关系，这一点在设计的权衡里反复出现。

做这类题的时候我有个习惯：先把页面大小换算成 2 的幂，秒出偏移位数；然后看题目给的"每段最大长度"，除以页面大小得到页数，取 log₂；最后用总位数一减。三步走下来基本不会错。要注意的是有些题目会绕个弯，比如告诉你"段表最多 256 项"，那其实是直接告诉你段号 8 位，不用再推。

2.3 一次地址转换要访问几次内存

这是另一个高频考点，也是理解 TLB 价值的关键。在不使用快表的情况下，段页式的完整流程是这样：

1. 用段表寄存器里的段表基址，加上"段号 × 段表项大小"得到段表项地址，读出段长和页表基址。这一步访问一次内存。
2. 比对页号和段长，合法的话，用页表基址加上"页号 × 页表项大小"得到页表项地址，读出物理块号。这一步再访问一次内存。
3. 用物理块号乘以页面大小，加上页内偏移，得到物理地址，读出数据。第三次访问内存。

所以答案是三次。如果题目说"引入了 TLB 且命中率为 h"，那命中时只要 1 次访存（TLB 里直接拿到物理块号），不命中时还是 3 次，平均访存次数就是h × 1 + (1 − h) × 3。有些题目还会让你把这个结果和纯分页对比——纯分页不命中时是 2 次，所以段页式在访存效率上是吃亏的，这也解释了为什么后来大家更愿意用多级页表而不是分段。

有个延伸点容易被忽略：如果段表项或页表项本身不在内存（比如被换出到磁盘了），那访存次数还要再加，而且会触发缺页中断。教材上的"三次访存"都是默认表项常驻内存的情况，考试里如果题目没特别说明，按三次算就行。

3. 课堂练习4.3 的典型题型手算实录

3.1 题型归纳与固定的解题顺序

这类练习题基本跑不出四种题型：一是给逻辑地址格式和表内容，求物理地址；二是给地址位数要求，反推各段位数；三是算页表、段表占多少空间；四是判断某个地址是否越界、是否缺页。其中第一种是综合题的主体，通常会连带考查第三、第四种。

我自己的解题顺序固定成四步，写在草稿纸左上角，做完一步划掉一步：

1. 拆地址。按题目给的位数，把逻辑地址的二进制或者十六进制拆成段号、页号、偏移三部分。
2. 查段表。算段表项位置，读段长和页表基址，先做越界判断。
3. 查页表。算页表项位置，读物理块号。
4. 拼物理地址。物理块号 × 页面大小 + 偏移。

这套顺序的关键是第 2 步的越界判断要放在读页表之前。很多同学着急往下算，页号明明超了段长还在那查页表，最后得一个看似正确的物理地址，其实该报越界中断。答题时把判断过程写出来，分数才拿得稳。

3.2 综合算例：从逻辑地址到物理地址

来看一道完整的题。某系统采用段页式存储管理，参数如下：

• 逻辑地址 32 位，划分为段号 8 位 | 页号 12 位 | 页内偏移 12 位
• 页面大小 4KB，页表项大小 4 字节，段表项大小 8 字节
• 段表起始地址为 0x1000
• 段表内容：2 号段，段长 6 页，页表起始地址 0x8000；3 号段，段长 4 页，页表起始地址 0x9000
• 2 号段的页表中，5 号页表项内容为物理块号 0x37

现在求逻辑地址0x020050A3对应的物理地址。

第一步，拆地址。段号 8 位，取最高的 8 位：0x020050A3 >> 24 = 0x02，所以段号是 2。页号 12 位，取接下来的 12 位：(0x020050A3 >> 12) & 0xFFF。0x020050A3 >> 12 = 0x02005，再取低 12 位得到 0x005，也就是 5。页内偏移是低 12 位：0x020050A3 & 0xFFF = 0x0A3。

手算的话更直观，把十六进制按 2/3/3 位切：0x02 | 0x005 | 0x0A3，一一对应段号、页号、偏移，这种切法比敲计算器快。

第二步，查段表。段表项大小 8 字节，2 号段表项的物理地址 = 0x1000 + 2 × 8 = 0x1010。读出段长 6 页，页表起始地址 0x8000。检查页号：5 < 6，合法，继续。

第三步，查页表。页表项大小 4 字节，5 号页表项的物理地址 = 0x8000 + 5 × 4 = 0x8014。读出物理块号 0x37。

第四步，拼地址。物理地址 = 0x37 × 0x1000 + 0x0A3 = 0x37000 + 0x0A3 =0x370A3。

整个过程要访问三次内存：0x1010（段表项）、0x8014（页表项）、0x370A3（数据）。

再顺手把越界的情况过一遍。同一个系统里，如果来的是逻辑地址0x030900C8，拆出来段号 3、页号 9、偏移 0xC8。查段表第 3 项（地址 0x1000 + 3 × 8 = 0x1018），得到段长 4 页。页号 9 ≥ 4，越界中断，后面不用算了。这类题目经常在最后加一问"如果逻辑地址是 X 呢"，就是在考你会不会多做一步判断。

3.3 表空间开销类计算

第二类高频题是算内存开销，而且它特别能体现段页式相对纯分页的优势。

还是上面那个系统，段号 8 位意味着最多 256 个段，段表项 8 字节，所以段表本身占用 256 × 8 = 2048 字节 = 2KB。这部分不管进程用了几个段，只要段号是索引，段表就得按最大段数建（或者至少建到当前最大段号），所以是固定的。

页表就不一样了。页表是按段建立、按需增长的。假设某个进程实际用了 4 个段，分别有 3 页、8 页、20 页、64 页，那么页表占用 = (3 + 8 + 20 + 64) × 4 = 95 × 4 = 380 字节。整个进程的页表结构加起来不到 400 字节，段表 2KB，总计约 2.4KB。

对比一下纯分页方案的极端情况：32 位地址空间、4KB 页面，页表需要 2³² ÷ 2¹² = 2²⁰ = 1048576 个页表项，每项 4 字节，单级页表就是 4MB。哪怕进程只用了 1MB 内存，这 4MB 页表也得老老实实占着，因为索引是连续的页号，中间的洞也得填。

差距是三个数量级。为什么差这么多？因为纯分页的页表必须覆盖整个线性地址空间，而段页式的页表只覆盖实际存在的段。程序不会用满 256 个段，所以大多数段的页表压根不用建。这就是"按需建立"的威力。

不过也不能光看好处。如果真有个程序用满了 256 个段、每段都 4096 页，那页表总量就是 256 × 4096 × 4 = 4MB，和纯分页一模一样，还白白多花 2KB 段表。所以段页式的空间优势建立在程序对地址空间的稀疏使用这个前提上，这也是几乎所有现代内存管理优化的共同前提。

4. 用 Python 把地址转换跑一遍

纸上算清楚之后，我很建议用代码再实现一遍。原因有两个：一是代码会逼你把每个边界条件想明白（比如越界怎么判、表项不存在怎么处理）；二是调代码的时候你会对"三次访存"有肌肉记忆。

4.1 数据结构设计

我用字典来表示段表和页表，键就是段号和页号，值是对应的表项内容。真实系统里表是数组，但这里用字典更直观，也方便表达"某些表项不存在"。

PAGE_SIZE = 0x1000 # 4KB PTE_SIZE = 4 # 页表项 4 字节 STE_SIZE = 8 # 段表项 8 字节 SEG_BITS, PAGE_BITS, OFF_BITS = 8, 12, 12 SEGMENT_TABLE_BASE = 0x1000 # 段表起始物理地址 # 段表：段号 -> {limit: 段长(页数), pt_base: 页表起始地址} segment_table = { 2: {"limit": 6, "pt_base": 0x8000}, 3: {"limit": 4, "pt_base": 0x9000}, } # 页表：(段号, 页号) -> 物理块号 page_tables = { (2, 5): 0x37, (2, 0): 0x12, (3, 1): 0x05, }

这里有个刻意的设计：我把页表拍平成了一个大字典，键是(段号, 页号)元组。真实系统里是"段表项指向一块独立的页表内存区"，用pt_base + page * PTE_SIZE去索引。之所以拍平，是为了代码短、跑起来直观；但我在 4.3 节会额外加一个函数，专门把两级索引的真实地址算出来，保留"三次访存"的物理含义。

4.2 转换函数实现

拆地址的三个位运算是一切的起点，写成函数方便复用：

def split_logical_addr(addr): """把 32 位逻辑地址拆成 (段号, 页号, 页内偏移)""" seg = (addr >> (PAGE_BITS + OFF_BITS)) & ((1 << SEG_BITS) - 1) page = (addr >> OFF_BITS) & ((1 << PAGE_BITS) - 1) off = addr & ((1 << OFF_BITS) - 1) return seg, page, off

注意这里用的是位移位数而不是写死 24、12，这样以后改配置（比如页面大小换成 1KB）只要改常量，函数不用动。这是我自己踩过的一个坑：一开始硬编码了>> 24，后来想试试 16 位的地址格式，改了一堆地方还漏了一处。

然后是主转换函数，把四次访存的地址都返回出来，方便观察：

def translate(logical_addr): seg, page, off = split_logical_addr(logical_addr) # 访存 1：读段表项 if seg not in segment_table: raise ValueError(f"段号 {seg} 越界：段表长度不足") ste_addr = SEGMENT_TABLE_BASE + seg * STE_SIZE entry = segment_table[seg] # 越界检查必须在读页表之前 if page >= entry["limit"]: raise ValueError( f"页号 {page} 超出段 {seg} 的长度 {entry['limit']} 页，越界中断" ) # 访存 2：读页表项 pte_addr = entry["pt_base"] + page * PTE_SIZE if (seg, page) not in page_tables: raise ValueError(f"段 {seg} 页 {page} 不在内存，缺页中断") frame = page_tables[(seg, page)] # 访存 3：合成物理地址并读数据 phys_addr = frame * PAGE_SIZE + off return { "seg": seg, "page": page, "offset": off, "ste_addr": ste_addr, "pte_addr": pte_addr, "frame": frame, "phys_addr": phys_addr, }

有两个地方值得说明。第一，越界检查和读页表的顺序不能反，代码顺序就体现了这一点。第二，我把三种异常分开抛：段号越界、页号越界、缺页。真实系统里它们对应完全不同的中断处理程序，混在一起会掩盖问题。有次我图省事只抛一个通用异常，结果调了半天才发现是页号越界而不是缺页，白折腾。

4.3 测试用例与结果验证

先跑 3.2 节那道题，看看结果对不对：

r = translate(0x020050A3) print(hex(r["phys_addr"]), hex(r["ste_addr"]), hex(r["pte_addr"])) # 0x370a3 0x1010 0x8014

三个值跟手算完全一致，说明位划分和索引计算都对上了。

再补一个逆向生成的验证函数，随机造一批地址正着算一遍、反着算一遍，能抓出隐藏的位运算错误：

def build_logical_addr(seg, page, off): return (seg << (PAGE_BITS + OFF_BITS)) | (page << OFF_BITS) | off # 往返测试 for seg, page, off in [(2, 0, 0x000), (2, 5, 0x0A3), (3, 1, 0xFFF)]: addr = build_logical_addr(seg, page, off) s, p, o = split_logical_addr(addr) assert (s, p, o) == (seg, page, off) print("往返测试通过")

最后跑一遍越界和缺页：

try: translate(0x030900C8) # 段3、页9、偏移0xC8，页号超过段长4 except ValueError as e: print(e) # 页号 9 超出段 3 的长度 4 页，越界中断 try: translate(build_logical_addr(2, 3, 0x10)) # 页表里没建(2,3) except ValueError as e: print(e) # 段 2 页 3 不在内存，缺页中断

调试的时候我一直用build_logical_addr造输入，比手敲十六进制安全得多。手敲0x020050A3这种数，多一个 0 少一个 0 结果全变，而且错了还很难一眼看出来。

5. 常见错误与排查速查

5.1 位划分和进制换算类错误

这类错误占了我在这个练习里翻车的至少一半。最典型的是混淆段长的单位。题目说"段长 4MB"，你直接拿去和页号比，那就全错了，因为页号是页的数量，单位必须统一成页。4MB ÷ 4KB = 1024 页，页号必须小于 1024。

第二个坑是十六进制切分的位置。0x020050A3按 8/12/12 位划分，对应的十六进制正好是 2 位/3 位/3 位。但换成别的位数就不一定整了，比如页号 10 位、偏移 12 位，那就不能简单地按 nibble 切，得老老实实转二进制或者用位移。我见过有人按"每 4 位一个十六进制字符"硬切，结果在非 4 倍数位宽下切错了还浑然不觉。

第三个坑是总位数守恒。把段号、页号、偏移三位数加起来，必须等于逻辑地址总位数。如果算出来是 31 或者 33，那一定哪里错了。这个检查只要 2 秒，建议每道题都做。

5.2 表项大小和页表开销类错误

计算段表项地址的时候，公式是段表基址 + 段号 × 段表项大小。这里的项大小是字节数，不是位、不是字。有些题目会说"段表项占 1 个字，字长 32 位"，那就要换算成 4 字节。同理页表项。

另一个容易被忽略的点：段表和页表本身也占内存，而且它们的换入换出也要消耗 I/O。算总开销的时候，别只算页表忘了段表那 2KB。虽然量级上段表很小，但题目如果问"总共需要多少空间来存放地址映射结构"，漏掉就是错。

还有一个更隐蔽的：页表项的物理块号不是物理地址。0x37这个块号要乘以页面大小才能变成地址的基址部分。直接把块号当成地址的一部分去加偏移，是最典型的低级错误，但它错得很自然，因为块号往往也是十六进制数。

5.3 越界判断与权限检查

段级保护和页级保护是两次独立检查，段表项里有读/写/执行权限位，页表项里也有。一次访问必须两级都通过。教材上的题目通常只考越界，但真机上是双重检查，我在代码里留了口子没实现权限位，如果要做完整模拟，得在translate里再加一层判断。

另外，越界中断和缺页中断的处理方式完全不同：越界是程序 bug，一般直接终止进程；缺页是正常现象，操作系统分配物理页、从磁盘读入、更新页表，然后重新执行那条指令。这个区别在选择题里反复出现。

6. 从课本到真实机器

6.1 32 位保护模式下的段页叠加

学到这里你可能会问：段页式到底有没有真实实现过？有，而且相当典型。32 位保护模式下的地址翻译就是"先分段、再分页"两段式流程：程序给出的段选择符:偏移叫逻辑地址，段选择符是 16 位，其中 13 位是索引，能索引 8192 个段描述符；段描述符里存着 32 位段基址和 20 位段界限，还有个粒度位，粒度设为 1 时界限以 4KB 为单位，最大能表示 4GB。把段基址加上偏移，得到 32 位线性地址；然后线性地址再按 10/10/12 位切成页目录索引、页表索引、页内偏移，查两级页表得到物理地址。

所以它是两级查表 + 两级分页，比课本的段页式还要多一层页表层级。但结构思想完全一样：分段负责逻辑隔离和保护，分页负责物理内存的离散分配。

有意思的是，真正跑在它上面的操作系统往往把分段给"关掉"了。做法很取巧：把代码段、数据段、栈段的基址全设成 0，界限全设成 4GB，这样逻辑地址和线性地址就完全相等，分段在功能上被架空了。这么做不是为了偷懒，而是因为分段机制在多任务、多线程环境下的管理成本太高，而分页配合页级权限位已经能满足大体上的保护需求。这是个很典型的工程选择——机制还在，但被配置成了"直通"。

6.2 TLB 命中与缺页的配合

段页式的三次访存在真机上并没有把人拖垮，靠的就是 TLB。TLB 是一块容量很小但极快的相联存储器，通常几十到几百项，缓存的是"逻辑页 → 物理块"的映射。注意它缓存的是最终的映射结果，段表和页表的中间过程不用重复走。命中时一次访存搞定，不命中时才去趟内存。

现代处理器一般把 TLB 分成指令 TLB 和数据 TLB，各自还可能有多级。这个设计跟段页式的结构配合得挺自然：段级信息（权限、边界）变更频率很低，页级信息变更更频繁（缺页、换出都要改），所以缓存策略也不一样。

缺页的处理流程也值得理一遍。访问某个页发现页表项的有效位是 0，触发缺页中断，操作系统接管：找一个空闲物理块，没有就按置换算法淘汰一个（脏页要先写回磁盘），把目标页从磁盘读进来，更新页表项，然后重新执行刚才那条指令。这条指令重新执行时 TLB 已经有了新映射，就能顺利走完。整个过程对用户程序完全透明。

有个细节值得注意：换出页面会不会把段表、页表也换出去。会，操作系统把页表本身也当成可以换出的内存内容。如果段表项被换出，那查段表时也会触发缺页；如果页表项所在的那一页被换出，查页表时同样会缺页。这就是为什么"最坏情况下一次访存需要五六次缺页处理"这种说法会出现。

6.3 为什么今天还在学分段

现在主流的做法是分页配合多级页表，分段在地址翻译这条路上基本退场了。那为什么操作系统课还要花整整一节讲段页式？

我的理解是，分段解决的是一个分页解决不好的问题：程序的结构信息。程序天生就是有结构的——函数、数据、栈、堆，这些边界是编译器知道的。把这些信息告诉硬件，硬件就能做更精细的保护和共享。分页做不到这一点，因为页是固定大小的、与程序结构无关的切割。

现代系统把这份结构信息交给了别的东西：可执行文件格式里的段表（实际上也是按权限分组的页集合）、页表项里的权限位、以及操作系统维护的虚拟内存区域描述结构。功能还在，只是承载它的抽象换了。理解了段页式，你就理解了"为什么要有这一层结构描述"这个问题本身，这比记住三次访存的计算公式重要得多。

回到课堂练习 4.3，它的价值不在于让你背出转换流程，而在于逼你把一个多层索引的地址翻译过程完整地推一遍。这种"分层查表"的思维，在文件系统索引节点、多级页表、数据库 B+ 树索引里都在反复出现，形式不同，骨架是一个。

最后分享一个我自己的小习惯：做完每道段页式的题，我都会顺手在纸上画一遍那条"逻辑地址 → 段表 → 页表 → 物理地址"的路径，把经过的每个地址都标出来。画上四五遍之后，这类题的解题速度会明显变快，因为脑子里有了一张固定的地图，看到题目就知道下一步该去哪、该读哪个数。真正上考场的时候，能省下来的就是这几秒钟的判断时间。