1. 从"变量是盒子"到"变量是标签"：Python3 里最该先纠正的心智模型
很多人在接触 Python3 基础语法之前，多少都写过一点其他语言。C、Java 那套"变量就是盒子，赋值就是把东西装进盒子"的模型，在 Python 里会处处碰壁。我刚从 C 转过来的时候，第一个坑就踩在这里。
先看一段看起来人畜无害的代码：
a = [1, 2, 3] b = a b.append(4) print(a) # 输出 [1, 2, 3, 4]如果按照"盒子模型"理解，b 是 a 的复制品，改 b 不应该影响 a。但实际输出表明，a 和 b 指向的是同一个列表对象。在 Python3 里，所有变量本质上都是"贴在对象上的标签"，而不是装对象的容器。赋值语句b = a做的事是：把 b 这个标签也贴到 a 所指向的那个对象上。两个标签贴同一个对象，通过任何一个标签修改对象，另一个标签看到的内容自然也会变。
这个心智模型一旦建立，后面很多东西都会顺理成章。比如为什么 Python3 的变量不需要声明类型？因为对象本身才携带类型信息，变量只是引用。a = 1时，a 贴到整数对象 1 上；a = "hello"时，a 被撕下来贴到字符串对象上。变量没有任何类型约束，它可以随时指向任意类型的对象。
再看一个经典的"原地修改"问题：
def append_item(lst, item): lst.append(item) return lst my_list = [1, 2] new_list = append_item(my_list, 3) print(my_list) # [1, 2, 3] print(new_list) # [1, 2, 3] print(my_list is new_list) # True函数参数传递的也是引用，不是拷贝。如果你希望函数内部操作不影响外部列表，需要用切片或 copy 显式创建副本：
def append_item_safe(lst, item): new_lst = lst[:] # 切片创建新列表 new_lst.append(item) return new_lst判断两个变量是否指向同一个对象，用is；判断两个对象内容是否相等，用==。这两者的区别在 Python3 里极其重要，尤其是在处理None的时候——官方推荐用x is None而不是x == None，因为None是单例对象，is的判等既快又准确。
注意：当你写
a = b = []时，a 和 b 指向同一个空列表。如果后面a.append(1)，b 也会变成[1]。这通常不是你想要的结果。想要两个独立的列表，应该分两行写：a = []和b = []。
这个"标签与对象"的模型，建议在写第一行代码之前就先刻在脑子里。它不是抽象的理论，而是直接影响你代码正确性的核心认知。我在给新人做代码评审时发现，很多"诡异的 bug"最终都追到了对变量赋值的错误理解上，尤其是那些涉及列表、字典等可变对象的场景。
2. 动态类型与类型转换：Python3 的"灵活"恰恰需要更强的边界感
Python3 是动态类型语言，这意味着解释器在运行时才检查类型。这种灵活性的代价是，类型错误往往要到运行那一刻才暴露。我在一个数据处理脚本里遇到过这类问题：从文件读进来的数字全是字符串，直接相加得到的是拼接字符串而非数值求和，结果下游报表全错了。
2.1 常用内置类型的行为边界
Python3 的常用内置类型大体可分为两类。不可变类型包括int、float、str、tuple、frozenset；可变类型包括list、dict、set。这个属性决定了你能否在原有对象上修改内容。
s = "hello" # s[0] = "H" # 报错：TypeError，字符串不可变 t = (1, 2, 3) # t[0] = 99 # 报错：TypeError，元组不可变 lst = [1, 2] lst[0] = 99 # 正常，列表可变很多人不理解为什么 Python3 要同时提供list和tuple。核心原因就是不可变性带来的安全性：元组可以作为字典的键，而列表不行；元组可以作为集合的元素，而列表不行。函数返回"多值"时，用元组隐式打包是惯例：
def get_min_max(data): return min(data), max(data) # 返回一个元组 low, high = get_min_max([3, 1, 4, 1, 5])2.2 类型转换：显式优于隐式
Python3 不会帮你做隐式的类型转换。"3" + 5会直接抛TypeError，而不是像某些语言那样自动转成"35"或8。这在早期会让人抓狂，但从工程角度看，这是好事——它逼着你显式地表达意图。
常见的显式转换写法：
num_str = "42" num_int = int(num_str) # 字符串转整数 num_float = float("3.14") # 字符串转浮点数 text = str(123) # 数字转字符串转换时最常踩的坑是舍入方式。int(3.99)返回 3，它永远是截断而非四舍五入。如果想四舍五入，要用round(3.99)。更隐蔽的是浮点数精度问题：0.1 + 0.2 == 0.3在 Python3 里结果是False，因为二进制无法精确表示 0.1。涉及金额或精确比较的场景，建议用Decimal：
from decimal import Decimal price = Decimal("19.99") tax = Decimal("0.10") total = price * tax # 精确的十进制运算很多新手会在这里翻车，所以我把这条列在显式类型转换之后的第二顺位。它不是一个冷门知识，而是每个用 Python 处理数字的人都躲不开的潜在问题。
2.3 鸭子类型与协议：真正理解"不检查类型"的哲学
动态类型的底层逻辑是"鸭子类型"：如果它走起来像鸭子、叫起来像鸭子，那它就是鸭子。Python3 不强制要求对象继承某个抽象基类，只要对象实现了需要的方法，就能参与相应运算。
class MyListLike: def __init__(self, items): self._items = items def __len__(self): return len(self._items) def __getitem__(self, index): return self._items[index] obj = MyListLike([10, 20, 30]) print(len(obj)) # 3 for item in obj: # 支持迭代，因为定义了 __getitem__ print(item)这个设计让 Python3 的代码具有极强的组合性。你不需要为了复用写一堆接口，只要协议对齐就行。但这也要求你具备更强的边界感——调用别人写的函数时，要清楚约定传入什么类型、返回什么类型。写代码时多用名字辅助：一个变量叫user_ids，就别往里塞字符串；一个函数叫parse_config，就只返回字典而不要偶尔返回一个None。类型注解（PEP 484）和静态检查工具（比如 mypy）如今已经成熟，我建议在项目第一天就开启，它不会束缚动态类型的灵活，但会在运行前帮你拦截掉大量低级类型错误。
3. 缩进才是真正的"大括号"：Python3 代码块的执行规则与常见陷阱
Python3 用缩进表示代码块，这在所有主流语言里独树一帜。很多从其他语言转过来的人，第一个月写出来的 Python 都会带着"大括号癖"——喜欢随手敲{}和;，然后在报错中慢慢纠正。但缩进真正的难点不是"要不要用空格"，而是理解"缩进级别就是代码块的层级结构"。
我见过一个经典的 bug：字符串变量没有按要求拼接，原因就是在 if 块结束后多加了一层缩进，导致赋值语句被吞进了条件分支。排查思路其实很简单，但发现过程很头疼。
这个 bug 的原始代码长这样：
name = "Alice" if len(name) > 0: prefix = "Hello, " result = prefix + name执行到result那一行的时候，如果len(name) > 0成立，一切正常；如果不成立，代码会直接崩溃，因为prefix从未定义。从语法层面看没有问题，这行代码不在 if 块内部——但如果你的缩进让result看起来在 if 内部，逻辑就完全变了。这就是缩进代码块的执行规则最容易坑人的地方。
3.1 四空格约定与混用禁忌
Python 官方 PEP 8 推荐用 4 个空格做一级缩进。这里有一条铁律：同一个文件里永远不要混用 Tab 和空格，因为解释器会直接报TabError: inconsistent use of tabs and spaces in indentation。我在实际开发中都是统一用空格，编辑器里把 Tab 键自动转换成 4 个空格，一劳永逸。
另一个轻微但影响阅读的问题是缩进层级过深。如果一层接一层的嵌套，代码的可读性会迅速下降——这通常意味着你该抽函数了。一个很好的自检标准是：如果缩进超过 4 层，就停下来想一想，是不是可以把某个分支重构到独立函数里。
3.2 复合语句的语义：if、elif、else 的对齐逻辑
Python3 没有 switch/case 语句，多分支判断用if/elif/else的链式结构。elif是else if的缩写，它的缩进级别必须与if对齐，而不是嵌在else下面：
score = 85 if score >= 90: grade = "A" elif score >= 80: grade = "B" elif score >= 70: grade = "C" else: grade = "D"我在代码评审里频繁看到的错误是：有人在else下面再写一个深一层的if，而不是使用elif，无端增加了一层嵌套，还会造成"悬垂 else"理解困难。另外短路求值也是值得注意的规则：and和or会从左到右求值，一旦结果确定，后面的表达式不再执行。这意味着你可以安全地写if x is not None and x.value > 0:，而不用担心 x 为空时报错——因为当x is not None为 False 时，后半段根本不会执行。
提示：条件链里用
elif而不是多个并列if还有一层性能含义——并列的if会逐个判断每个条件，而if/elif链在某个条件满足后就跳出了整条链。对性能敏感的场景，两者会有可观察的差异。
3.3 for 与 while 的 else 子句：一个容易记错的隐藏语法
Python3 的for循环和while循环都可以带一个else子句，这个特性在别的语言里几乎看不到。它的语义是：如果循环正常结束（没有中途 break），就执行 else 块。
def find_contains(items, target): for item in items: if item == target: print("找到了") break else: print("没找到")这个写法比"标志位 + 循环后判断"干净得多。我经常用它来写查找逻辑，比如在数据库连接池里找空闲连接，扫描列表找首个匹配项，诸如此类。容易记错的地方是：如果你本来是想捕获"循环没执行任何迭代"的情况，else也会执行，因为一次都没执行也是"正常结束"。所以它的语义应该是"没有 break 就执行"，而不是"循环体被执行过"。
缩进相关的核心记忆口诀就一句话：同一个层级就是同一个作用域，代码块以缩进为边界，不存在其他任何意义上的块级作用域。这既是你读 Python3 代码时快速定位逻辑的抓手，也是你写代码时需要时刻保持清醒的规矩。
4. 序列的边界行为：为什么 Python3 的切片和索引总是"差一位"
Python 序列的索引和切片规则，是我见过新手提问频率最高的基础语法点之一。排队数人这种事大家都干过，但 Python3 的索引是从 0 开始排队的，而且切片区间是左闭右开——[start:end]包含 start，不包含 end。这套规则一旦理解透，几乎所有序列操作都顺了。
lst[0]取第一个元素，对应生活中说的"第 1 个"；lst[-1]取最后一个，lst[-2]取倒数第二个。负索引本质是len(lst) + 负索引的语法糖，所以对长度为 5 的列表而言，lst[-5]就是lst[0]。越界访问会报IndexError，这比静默返回错误值要友好得多。
切片则更灵活：
data = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] data[2:5] # [2, 3, 4]，含头不含尾 data[:3] # [0, 1, 2]，start 缺省为 0 data[7:] # [7, 8, 9]，end 缺省为 len(data) data[::2] # [0, 2, 4, 6, 8]，步长为 2 data[::-1] # [9, 8, ..., 0]，逆序复制有几个特别容易出错的地方：
其一，切片永远不越界报错。data[100:200]返回空列表而非异常，这是刻意设计——你可以在不确定长度的情况下放心切。很多断言的 bug 恰恰源于此，所以需要"切完判断是否为空"的场景，要记得显式检查。
其二，lst[::-1]用来反转列表很常用，但它生成的是副本，不是原地反转。如果追求效率和内存友好，用lst.reverse()原地反转。对于字符串，没有.reverse()方法，只能s[::-1]，返回的是逆序的新字符串。
其三，lst[0:5]和lst[:5]等价，但对可读性来说，省略 0 会让意图更清晰——"我要前 5 个"。反过来lst[-3:]表示"最后 3 个"。
提示：切片不仅能读，还能赋值。
lst[1:3] = [9, 9, 9]会把原位置上的两个元素替换成三个新元素。这个特性可以用来做列表的插入和删除，但新手容易在长度不匹配时搞出无法预期的结果，写代码时务必确认替换前后的长度关系。
关于左闭右开区间，还有一个实际场景最能说明它的价值：当你需要把列表分成等长的两半时，length = len(lst)，左半边lst[:length//2]，右半边lst[length//2:]。这个写法不用去记"中间元素的下标到底加不加一"，因为切片天然保证了两个半区无缝且不重叠。Python3 中内置的range函数也遵循同样的区间逻辑，range(5)产生 0 到 4 五个数，不会产生 5。循环遍历列表时，配合enumerate同时拿到下标和元素，是节奏最舒服的写法：
for idx, value in enumerate(data): print(idx, value)序列的边界行为看似细枝末节，实际上它是切片、循环、二分查找、分页逻辑等几乎所有算法的基础。把"左闭右开"这条规则内化成肌肉记忆之后，你会发现过去总想"要不要减一"的地方变得毫不费力。
5. 数据结构选型：列表、元组、字典、集合的适用场景与踩坑记录
Python3 基础语法不只是语法规则本身，还包括把这些语法用在什么数据结构上。选错了数据结构，代码虽然能跑，但会在可读性、内存占用和运行效率三方面同时付出代价。我这里列几个高频决策场景。
5.1 列表 vs 元组：可变性就是选型依据
列表是通用的"万能动态数组"，增删改查都很方便。元组是不可变的，它没有 append/remove 这类方法，但正因为不可变，它有两个独特优势：一是可以作为字典的键，二是作为集合的元素。如果你要表示一个"不该被修改"的记录，用元组比列表更安全——任何人都没法意外地改掉它。
conf_item = ("app_name", "my-service") # 元组当键没问题 d = {conf_item: 42}项目里常见的一种错误是用列表当字典的键，直接报TypeError: unhashable type: 'list'。听懂这句话在说什么，比死记硬背结论更根本：只有不可变对象才有稳定的哈希值，才能做键。
5.2 字典：默认值机制与嵌套访问的坑
字典是 Python3 里使用频率最高的数据结构之一。取值的核心方法是get(key, default)，它比直接用dict[key]安全，因为键不存在时返回默认值而不是抛KeyError。
user = {"name": "Alice", "age": 30} print(user.get("email", "未填写"))另一个容易忽视的场景是"计数"和"分组"，很多人会写多余的 if 判断。更优雅的做法是用defaultdict：
from collections import defaultdict word_count = defaultdict(int) words = ["apple", "banana", "apple"] for w in words: word_count[w] += 1 print(dict(word_count)) # {'apple': 2, 'banana': 1}再一个是键值的嵌套访问。当字典嵌套字典时，想取内层某个键，用链式dict["a"]["b"]["c"]很容易中途抛出KeyError。Java 社区有专门的 Optional 链式取值，Python3 里比较实用的是方案是逐层用get：
data = {"user": {"profile": {"city": "上海"}}} city = data.get("user", {}).get("profile", {}).get("city", "未知")这看起来啰嗦，但确实能避免一长串异常堆栈。collections模块里还有ChainMap、Counter这些工具，处理特定场景时比手写循环清晰得多。
5.3 集合：去重与成员判断的不二选择
集合set是无序、无重复元素的结构。它的核心价值有两个：一是去重，二是 O(1) 平均复杂度的成员判断。去重用一行代码，效率碾压手写的 for 循环：
items = [1, 2, 2, 3, 3, 3] unique = list(set(items))成员判断x in set比x in list要快出一个量级。列表是 O(n) 扫描，集合是基于哈希表的 O(1) 查询。当你有大量"是否包含某个元素"的判断需求时，就该把列表转成集合来用。但集合有一个需要注意的边界：它内部的元素必须是可哈希的。列表本身不可哈希，所以如果想存"一系列坐标对"，你要么用元组，要么用frozenset。
我在实际项目里常用的一个组合是"把集合当作已处理任务的标记表"。循环处理一批任务时，每处理完一个就把 ID 加入一个集合，下次遇到先if id in processed_set:，直接跳过。这个写法既简洁又高效，比在列表里辗转查找优雅得多。
5.4 推导式：浓缩但不失可读性的语法糖
列表推导式是 Python3 里最常用的"浓缩"写法：
squares = [x * x for x in range(10)] even_squares = [x * x for x in range(10) if x % 2 == 0]它对应的展开写法是"for 循环 + append"。推导式快且清晰，但有一点实践感悟：如果推导式嵌套超过两层，或者条件部分超过一个if，可读性会急剧下降，读者很难一眼看明白。这种时候我更倾向于展开成循环加注释。所谓"基础语法"的功夫，其实就体现在这种度量的把握上——能简洁地用推导式，但不会被推导式绑架。
类似地，字典推导式和集合推导式也很有用：
square_dict = {x: x * x for x in range(5)} unique_chars = {c for c in "hello world"}这些推导式的执行顺序与展开循环完全一致，所以推导式逻辑不好读时，直接展开成循环来调试即可——它们本质上是同一件事。
6. 函数入门与作用域：默认参数的坑、装饰器的思维以及与可变对象的纠缠
Python3 里函数是一等对象——它可以像整数、字符串一样被传递、被赋值、被作为返回值。如果要把 Python3 基础语法按重要性排序，函数作用域和参数传递规则能排进前三，因为这里藏着一个几乎所有教程都会提到、但很多人依然犯错的经典问题：默认参数用可变对象。
6.1 默认参数陷阱与正确写法
看这个函数：
def add_item(item, container=[]): container.append(item) return container第一次调用add_item("a")返回['a']，第二次调用add_item("b")返回['a', 'b']。如果你期望第二次调用也返回全新的['b']，就踩进了 Python3 的经典陷阱：默认参数只会在函数定义时求值一次，同一个列表对象会被所有没有显式传入参数的调用共享。
正确做法是：默认参数写成不可变对象，函数体内部再创建可变结构：
def add_item(item, container=None): if container is None: container = [] container.append(item) return container这也解释了一个更底层的规则：Python3 中"传参"传的是引用，默认参数只是这个引用的预置位置。实际项目里看到过因为这个邪门行为导致了诡异的服务状态污染——多个请求共用同一个列表，逻辑全混在一起。排查了很久才意识到是默认参数共享的问题，从那以后凡是默认参数是可变类型的代码，一律打回重写。
6.2 作用域规则：LEGB 与 global/nonlocal
Python3 的变量作用域遵循 LEGB 规则，查找顺序是 Local（局部）→ Enclosing（外层闭包）→ Global（全局）→ Built-in（内置）。这意味着，函数内部如果没有显式声明global，任何赋值都只在局部作用域里生效。尝试在函数里修改全局变量，结果往往是你改了一个新的局部变量，原来的全局值一动不动：
count = 0 def increment(): count += 1 # 这里会报 UnboundLocalError increment()为什么会报错？因为在函数体内出现了对count的赋值，Python3 把它标记为局部变量，于是count += 1中的count在赋值前被访问，触发未绑定错误。解决方式是：
count = 0 def increment(): global count count += 1嵌套函数里修改外层函数的变量，则需要nonlocal：
def outer(): total = 0 def inner(amount): nonlocal total total += amount inner(10) return total关于作用域有一条实践建议：尽量减少global的使用，因为过度依赖全局状态会让函数变成不可预测的黑盒。更合理的设计是让函数通过参数和返回值来通信，全局状态只留给那些真正"全局不变"的配置项。
6.3 装饰器：理解"函数即对象"后的第一个进阶
装饰器是 Python3 中最经典的高级特性，但它的语法糖极其简洁，核心逻辑反而容易被忽略：装饰器就是一个接收函数、返回新函数的函数。
def my_decorator(func): def wrapper(*args, **kwargs): print("调用前") result = func(*args, **kwargs) print("调用后") return result return wrapper @my_decorator def say_hello(): print("你好")@my_decorator本质上等价于say_hello = my_decorator(say_hello)。理解到这层，装饰器就不再神秘。但有一个容易踩的坑：直接用上面的写法会丢失原函数的元信息（函数名__name__、文档字符串__doc__都会变成 wrapper 的）。标准解决方案是使用functools.wraps：
from functools import wraps def my_decorator(func): @wraps(func) def wrapper(*args, **kwargs): return func(*args, **kwargs) return wrapper@wraps会把被装饰函数的元信息复制到 wrapper 上。这样在使用方按函数名查找、生成文档时，一切才能保持正确。我在做日志装饰器、重试装饰器、权限校验装饰器时，都会把这条规则当作默认动作来写。装饰器的参数形式还可再套一层，比如 Accept 里加参数：
def repeat(times): def decorator(func): @wraps(func) def wrapper(*args, **kwargs): for _ in range(times): func(*args, **kwargs) return wrapper return decorator @repeat(3) def hello(): print("Hello")掌握装饰器的思维模型，对后续理解上下文管理器、类型注解元数据、Web 框架中的路由注册都很有帮助。它本质上是 Python3"万物皆对象"设计哲学的延伸。
7. 异常处理与调试习惯：把 traceback 当作线索而非噪音
异常处理是 Python3 基础语法中"兜底"能力的关键一环。很多初学者对异常的第一反应是"程序崩了"，但其实traceback输出的是最宝贵的调试线索。学会读它，能让你的排查效率提升一个量级。
7.1 try/except/else/finally 的正确姿势
Python3 的异常处理结构有四个块，各自职责不同：
try: result = risky_operation() except ValueError as e: print(f"值错误: {e}") except (TypeError, KeyError) as e: print(f"其他已知错误: {e}") else: print("没有异常，正常执行到这里") finally: print("无论如何都会执行")try：监控可能出错的代码；except：捕获指定异常类型，可并列、可分组。捕获顺序很重要，子类异常要写在父类异常前面，否则子类永远被父类拦下；else：在 try 块没有异常时执行。这是常被忽略的块，它能避免把"该正常执行的代码"也塞进 try 导致混淆——如果 try 里既有风险操作又有后续逻辑，异常堆栈会变得不清晰；finally：无论是否异常都会执行，适合做资源释放。
一个常见误区是企图捕获所有异常：
try: ... except Exception: # 过度宽泛 pass这种写法会吞掉真正的 bug，让错误在看不见的地方酿成大祸。我的经验是：只捕获你明确知道怎么处理的异常，其他异常让它直接暴露出来，然后根据 traceback 定位修复，而不是用兜底捕获掩盖。
关于异常类型的选择，自己抛异常时也要具体化。最常用的内置异常有ValueError（值不合法）、TypeError（类型不匹配）、KeyError（字典键不存在）、IndexError（索引越界）。自定义异常继承Exception，可在异常对象里附加额外信息：
class ValidationError(Exception): def __init__(self, field, message): self.field = field self.message = message super().__init__(f"字段 {field} 校验失败: {message}")这样捕获到异常时，拿到的不只是字符串，而是结构化的上下文，极大方便调试。
7.2 常见异常排查速查表
| 异常类型 | 触发场景 | 最可能的原因 |
|---|---|---|
NameError | 访问未定义的变量 | 拼写错误或作用域外使用 |
TypeError | 操作不相容类型 | 如字符串与整数相加、调用未定义参数数量 |
ValueError | 值不合法但类型对 | int("abc")等转换失败 |
KeyError | 字典用不存在键取值 | 未检查键是否存在于dict[key] |
IndexError | 序列索引越界 | 直接用越界下标 |
AttributeError | 对象没有该属性 | 调用了不存在的方法或属性 |
FileNotFoundError | 文件不存在 | 路径拼写错误、目录层级不对 |
每种异常在 traceback 里都会定位到具体文件和行号，异常类型也直接告诉你问题性质。很多时候根本不用断点，看一眼异常类型和反馈的行号，脑子里已经知道大概什么情况。
7.3 调试习惯：print 之外的工具
基础语法阶段，大家最常用print调试。但代码量一大，到处插print会让自己都看不清输出。我建议至少掌握两种方式：
第一种是logging模块，它支持分级日志、输出到文件、格式化时间戳，长期维护项目必备：
import logging logging.basicConfig(level=logging.DEBUG) logger = logging.getLogger(__name__) logger.debug("这是调试信息") logger.info("这是进度信息") logger.warning("这是警告") logger.error("这是错误")第二种是pdb交互式调试，在代码中插入断点：
import pdb pdb.set_trace() # 程序运行到这里会进入交互式调试界面调试界面里可以用n步过、s步入、p打印表达式、q退出，非常直观。新版 Python3 里还提供了breakpoint()内置函数，不需要再import pdb。进入断点后逐行看变量的变化，往往比盯着 print 输出更容易还原问题现场。
我个人的习惯是：开发阶段用print/breakpoint快速定位怀疑点；修复完成之后，把临时调试语句删除，换成精简的logger输出长期留存。这样既能保证开发效率，也不会给代码留下大量调试垃圾。
8. 用一个小案例串起全部基础语法：命令行词频统计脚本
讲了很多散点，把它们串起来最有感觉。我写一个超短但五脏俱全的命令行词频统计脚本，覆盖文件读取、字符串处理、字典操作、函数组织、异常处理、推导式这些基础语法点。你可以直接把代码粘到文件里跑一跑。
import sys import re from collections import Counter def load_text(path): try: with open(path, "r", encoding="utf-8") as f: return f.read() except FileNotFoundError: print(f"错误：找不到文件 {path}") sys.exit(1) def count_words(text): words = re.findall(r"[a-zA-Z0-9]+", text.lower()) return Counter(words) def main(): if len(sys.argv) != 2: print("用法：python word_count.py <文件路径>") sys.exit(1) text = load_text(sys.argv[1]) word_counter = count_words(text) print("词频最高的 10 个词：") for word, count in word_counter.most_common(10): print(f"{word:<15} {count}") if __name__ == "__main__": main()这段代码里体现了几个基础语法要点：
sys.argv是命令行参数列表，索引 0 是脚本名，索引 1 开始是用户参数；with open(...) as f是上下文管理，保证文件自动关闭；sys.exit(1)表示以异常状态退出，供外部调用者感知失败；Counter是字典的子类，自动处理"词频统计"需要的计数逻辑；if __name__ == "__main__":确保模块被导入时不执行入口，只有直接运行脚本时才执行。
运行结果示例：
$ python word_count.py sample.txt 词频最高的 10 个词： the 15 and 12 to 10 ...这个 30 行的小程序覆盖了本篇讲的大部分内容：变量与对象、数据类型与转换、函数与作用域、数据结构选型、异常处理、推导式以及模块化组织。我建议初学者把它打一遍，然后扩展几个功能——比如支持忽略停用词表、支持统计中文分词后词语、把结果导出到 CSV。每加一个功能，你都会重新触碰一遍"基础语法"的底层细节，这种触碰比看任何教程都牢固。
