第 11 章　文件与异常

11.1内存的短暂：为什么需要持久化

回到第 4 章：变量存在内存（RAM）里。内存有个根本特点——易失性（volatile）：它靠电力维持，一断电（或程序一结束），里面的数据就全部消失。

这带来一个现实问题：你辛辛苦苦用程序算出的一堆结果，程序一关就没了。这显然不行——记账本、文章、游戏存档，都得「长期保存」。

解决办法就是持久化（persistence）：把内存里的数据，写到磁盘（硬盘）上。磁盘的特点是非易失——断电了数据也还在。

内存为什么会「失忆」：电容里的电

「断电就丢」不是内存的毛病，而是它的工作原理使然。主流内存（DRAM）的每个存储位，本质是一枚微型电容：充电代表 1，放电代表 0。电容会漏电，所以内存芯片必须每隔几毫秒就把所有电容刷新一遍（重新充电），像一群得不停续水的小水杯；一旦断电，没有人再续水，杯里的电在瞬间漏光，0 和 1 的记忆随之蒸发。磁盘则不同——它靠介质的物理状态记数据（磁性方向等），写好之后不依赖电力维持，所以断电也不丢。一句话：内存用电的「现状」记数据，磁盘用介质的「烙印」记数据——现状随电而去，烙印长存。

# 程序 A：计算并保存
temps = [12.5, 13.0, 11.8]
total = 0
for t in temps:
    total = total + t
avg = round(total / len(temps), 2)   # 12.43
f = open("today.txt", "w")
f.write(str(avg))                    # 数字先转字符串再写入
f.close()

# 程序 B：另一个程序，重新读回
f = open("today.txt", "r")
print("程序A存的平均温度:", f.read())  # 程序A存的平均温度: 12.43
f.close()

11.2文件：磁盘上的「持久容器」

那「文件」到底是什么？

文件（file）是磁盘上一块被命名、能读写的数据区域。一个文件有：

• 名字：如 notes.txt，用来找到它。
• 内容：一串数据（文字、数字、图片的字节……）。
• 位置：在磁盘的哪个路径下。

从程序的角度看，文件就像一个「放在磁盘上的大盒子」：你可以往里面写数据，也可以从里面读数据。写 = 存，读 = 取。

把「位置」说清楚：路径与目录树

文件三要素里的「位置」，在真实电脑上是以路径（path）表达的。磁盘上的文件夹（目录）一层套一层，像一棵倒挂的树：顶层是盘符或根目录，往下分叉出各级文件夹，树叶才是文件。data/2024/temps.txt 就是一条路径——顺着 data 进 2024 文件夹，找到 temps.txt。路径有两种写法：绝对路径从根写起（如 Windows 的 C:\data\temps.txt、Linux/Mac 的 /data/temps.txt），像寄信写全地址；相对路径从「程序当前所在的文件夹」写起，像在自家小区里说「三号楼」——省事，但换了出发点就得重说。前面例题里直接写 "today.txt"，就是最短的相对路径：文件与程序在同一层。

回到文件名本身，再看一眼「名字 + 扩展名」的边界：扩展名以最后一个点为准。一个文件名里可以有好几个点，真正标记类型的是最后那个；名字里也可以一个点都没有，那就是「无扩展名」文件。这条规则完全可以用已学的字符串操作算出来。

name = "archive.tar.gz"
i = name.rfind(".")     # 最后一个点的下标
print(i)                # 11
print(name[i+1:])       # gz        ← 扩展名
print(name[:i])         # archive.tar  ← 主体
print(len(name))        # 14

name2 = "notes"
print(name2.rfind(".")) # -1 → 没有点，无扩展名

11.3打开、写入、读取、关闭

在 Python 里操作文件，有固定的四步套路：打开 → 操作（写/读）→ 关闭。

写入：把数据存到文件

f = open("notes.txt", "w")   # 1. 打开文件，w = 写入模式
f.write("你好，世界")          # 2. 写入内容
f.close()                    # 3. 关闭文件

逐行拆解：

1. open("notes.txt", "w")：打开（或创建）名为 notes.txt 的文件，"w" 表示「写入模式」（write）。它返回一个「文件对象」f，你可以把它想象成「文件的操作手柄」。
2. f.write("你好，世界")：通过手柄 f，把这段文字写进文件。
3. f.close()：关闭文件，释放这个手柄。

读取：把文件里的数据拿出来

f = open("notes.txt", "r")   # r = 读取模式
content = f.read()           # 读出全部内容
print(content)               # 输出：你好，世界
f.close()

几种常见的模式：

被 close 遗忘的数据：缓冲区

前文说过「不关闭的话，写入的数据可能还堵在缓冲区」——现在把这句话拆开讲透。每次 f.write(...)，数据并不是立刻写到磁盘，而是先存进内存里的一块「候车区」（缓冲区，buffer）；攒够一批或文件关闭时，才整批真正落盘。为什么这样设计？磁盘 I/O 极慢（11.6 节会给这笔慢账算出数量级），一条一条零散地写会慢到无法忍受；攒成整批一次写，是拿「极少数慢操作」换「无数快操作」。但缓冲区也有代价：数据在没落盘前只存在于内存里，此时断电，它和普通变量一样会蒸发。这就是「写完没 close，文件是空的/少了半截」事故的根源。

于是有一个直击要害的改进：能不能让 Python 自己保证 close？能——这就是文件操作的标准姿势 with open：

with open("log.txt", "a") as f:
    f.write("新一条记录\n")
# 离开 with 这两行缩进的瞬间，自动 close，缓冲区自动落盘

with ... as f 读作「打开文件并把手柄记作 f，在本块内负责」。它布置了两道防线：第一道，代码正常跑完，离开缩进块时自动关闭；第二道，块内哪怕中途抛出异常，退出前也会先关闭文件再让异常冒出去。相比之下，手写 open/close 有个致命盲区——f = open(...) 之后、f.close() 之前若出了异常，程序直接跳走，close 永远执行不到，手柄就漏在外面了。with 把「善后」从「靠人自觉」变成「语言机制保证」，这正是专业 Python 代码几乎都这样写文件的原因。

with open("run.log", "w") as f:
    f.write("start\n")        # w：新建/清空，写入第 1 行

with open("run.log", "a") as f:
    f.write("temp=93.1\n")    # a：接着写第 2 行

with open("run.log", "a") as f:
    f.write("stop\n")         # a：接着写第 3 行

with open("run.log", "r") as f:
    content = f.read()
print(content)
print("共", content.count("\n"), "行")

start
temp=93.1
stop
共 3 行

with open("t.txt", "w", encoding="utf-8") as f:   # 文本模式
    f.write("适航")
with open("b.bin", "wb") as f:                    # 二进制模式
    f.write("适航".encode("utf-8"))
with open("t.txt") as f:
    print(f.read())        # 适航 —— 读回字符串
with open("b.bin", "rb") as f:
    print(f.read())        # b'\xe9\x80\x82\xe8\x88\xaa' —— 读回字节串
with open("t.txt", "rb") as f:
    print(len(f.read()))   # 6：两个文件落盘的字节一模一样

11.4异常：程序出错时怎么办

程序运行中会「出岔子」：读一个不存在的文件、除以 0、把字符串和数字相加……这些运行时错误，Python 叫 异常（exception）。

print(1 / 0)          # 触发异常：ZeroDivisionError
open("不存在.txt", "r")  # 触发异常：FileNotFoundError

异常一旦触发，如果没人处理，程序就会立刻中断、崩溃，后面的代码都不执行。对于一个小脚本，崩了也就崩了；但对于一个正经的程序，随便一个异常就崩溃，体验极差——用户可能会因为「文件不存在」这种小事，看到程序直接闪退。

所以我们需要一种机制：预先「兜住」可能出现的异常，出错时不让程序崩溃，而是走另一条「补救」的路。这就是异常处理。

读懂 Traceback：报错不可怕，不会读才可怕

异常真发生时，Python 会打印一段「天书」，例如：

Traceback (most recent call last):
  File "demo.py", line 3, in <module>
    x = int("abc")
ValueError: invalid literal for int() with base 10: 'abc'

这段天书叫 Traceback（回溯），阅读口诀是「从最后一行读起，再向上找位置」：最后一行先给你结论——异常类型（ValueError）和一句原因（invalid literal：没法把 abc 当数字转成整数）；往上找最后一处 File "…", line N，就是出错的文件与行号；如果上面还有更多 File 行，说明错误是从更深的调用里层层传上来的。三步读完，你就知道「发生了什么、坏在哪」。把报错全文读懂再动手，是修程序的第一习惯。

底层直觉：异常是一次「计划外跳转」

CPU 逐行执行程序，靠一个叫程序计数器的「书签」记住「下一步执行哪一行」。正常情况下书签一行行往后挪；异常触发的瞬间，本质是这张书签被猛地抽走，改插到「能处理这个错误的地方」——一次不由分说的跳转。第 7 章讲过，if 分支是「你计划好的跳转」；异常则是「出错引发的计划外跳转」。如果代码里没人接手（没有 except），这张书签会一路往上交给 Python 本身：Python 的处理方式就是打印 Traceback 然后终止程序——这就是「没人兜住就崩溃」的底层含义。下一节要学的 try/except，就是在跳转的落点处安排一个接手人，把计划外跳转驯化成可控流程——下一节的图 11-4 会把这记跳转画出来。

print(1 / 0)          # ZeroDivisionError：数学上不成立的运算
open("x9.txt")        # FileNotFoundError：要读的文件不存在
int("abc")            # ValueError：值的内容转不成目标类型
print("3" + 5)        # TypeError：类型之间不支持这种运算

11.5try/except：兜住错误

Python 用 try / except 来兜异常。结构是：

try:
    可能出错的代码
except 异常类型:
    出错后执行的补救代码

它的逻辑是：先尝试（try）执行代码；如果执行中抛出了异常，就跳到 except 里执行补救代码，而不是崩溃。

看一个真实场景：读文件时，文件可能不存在。

try:
    f = open("notes.txt", "r")
    content = f.read()
    f.close()
except FileNotFoundError:
    print("文件不存在，请先创建它")

如果文件存在，正常读取；如果文件不存在，不会崩溃，而是打印一句友好的提示。

except 的「精确匹配」规则

try/except 最容易用错的地方是「兜的类型不对」。except ValueError: 只接 ValueError；此时若 try 块里抛的是 FileNotFoundError，这个 except 接不住，异常照样向外冒、程序照样崩——兜错类型等于白兜。所以写 except 前，先想清楚「这里最可能出什么类型的异常」：读文件想到 FileNotFoundError，转换用户输入想到 ValueError，做除法想到 ZeroDivisionError。上一节例题 4 的四类异常，就是配 except 的常用清单。还有一条新手须知：只兜预期的类型，别写不带类型的裸 except: 把一切统统吞掉——程序表面不崩了，可真正的大问题也被悄悄埋掉，排查难度翻倍。异常要「按类型精确接住、明确处理」。

再强调一遍跳转直觉：异常行之后的 try 代码不再执行。执行流在出错行被拦腰截断，直接落到 except 块；except 块跑完后，从 try/except 结构之后的代码继续——所以「兜住」之后程序是真的活着，不是假装活着。

# ① 不设防：直接崩
x = int("abc")        # ValueError: invalid literal ... 程序在此终止

# ②③ 设防 + 续命
try:
    x = int("abc")
    print("转换成功")   # ← 这行永远不会执行：异常行之后的 try 代码被跳过
except ValueError:
    print("这不是数字") # 兜住，走补救

print("程序还活着")     # try/except 之后，正常继续

try:
    with open("scores.txt", "r") as f:
        content = f.read()
    print("读到:", content)
except FileNotFoundError:
    print("scores.txt 不存在，先用默认值")
    content = ""        # 兜底：给个能用的值，让后面代码走得下去

辨析一套与 try/except 打对台的「上古机制」：返回错误码。C 语言的传统做法是函数出错时返回特殊值（−1、NULL），由调用者自己检查：查了就处理，忘了程序就带着坏数据继续跑——错得静悄悄，排查无从下手。异常机制反其道而行：出错点主动举手，没人接住就沿调用链层层上抛，直到有人处理；全程无人处理才让程序显式倒下。两个红利立见高下：其一「不会忘」——不写 except 就藏不住，没人能悄悄绕过；其二「不掺私货」——正常逻辑里不必每行都塞 if 判断错误码，主干代码读起来干干净净。但硬币有两面：错误码「忘了查才出事」，异常「乱兜才出事」——上一段那个空 except 反模式，正是从错误码时代平移过来的坏习惯在新机制里的变形。工程上两条底线记牢：错误码要检查，异常要有动作；在两种风格混用的老项目里，先看清每个函数说的是哪种「报错方言」再动手。

11.6输入输出的本质

最后把视角拉高，看一个贯穿始终的概念：输入输出（Input/Output，简称 I/O）。

第 1 章我们说过，计算机的本质是「输入 → 处理 → 输出」。而编程里，处处都是 I/O：

一个关键认知：I/O（尤其是磁盘读写）比纯计算慢得多。读一次磁盘，可能比做几百万次加法还慢。这就是为什么第 11.1 节说磁盘「慢」——它是程序性能的常见瓶颈。专业的程序员写程序时，会尽量减少不必要的 I/O 次数。

慢在哪里：给 I/O 算一笔数量级的账

「读一次磁盘比几百万次加法还慢」——这句话值得算清楚。做个数量级估算：CPU 做一次加法大约是纳秒级（10 的负 9 次方秒），机械硬盘读一次数据大约是毫秒级（10 的负 3 次方秒）——差了 6 个数量级。换算一下：10 毫秒 = 10,000,000 纳秒，即磁盘动一「格」，CPU 已经做完约一千万次加法。就算换成快得多的固态硬盘（SSD，约百微秒级），仍然比一次加法慢十万倍上下。所以那张 I/O 表里的每一行，都要在心里标上「贵」字：键盘、屏幕、磁盘、网络，都是比 CPU 慢几个量级的「慢亲戚」。

把镜头拉远，这张表其实是一座存储金字塔：塔尖是 CPU 里又快又小的寄存器，往下一层是内存，再往下是固态硬盘、机械硬盘，越往塔基越慢、越便宜、也越大。程序的数据必须在这座塔里上下搬家：正在算的住塔腰（内存里的变量，第 4 章），要长期保管的搬到塔基（磁盘上的文件，本章）。所谓「减少 I/O」，翻译过来就是让数据尽量住在离 CPU 近的楼层，能不下塔就不下塔；而「持久化」则是把重要数据及时送到塔基存好。两个诉求拉扯，工程上的解法前面已经见过：攒小批、定期落盘。第 12 章的项目会做一次真实的搬家——把算好的成绩统计写进磁盘。

n = 30
cost_per_open = 1.0   # 每次打开+关闭合计 1 秒

A = n * cost_per_open    # 30 × 1 = 30 秒
B = 1 * cost_per_open    # 1 × 1 = 1 秒
print(A)            # 30.0
print(B)            # 1.0
print(A / B)        # 30.0