Huigr王背了几十道Python面试题，面完出来心里还是没底——这种状态我见过太多次了。原因很简单：题目是死的，能力是活的。尤其当面试官把“Python基础”往深处问的时候，背答案的人通常撑不过三个追问。这篇经典Python面试题合集（二），聚焦我在真实面试里反复遇到、也反复看到别人翻车的几类问题，从类型系统、容器底层、闭包装饰器，到并发编程、对象模型，最后用一道“李白打酒”把手撕代码环节也带上。适合准备求职的Python开发者，也适合工作了两三年想查漏补缺的朋友。
1. 别在基础题上翻车：类型系统与引用语义的盘问
1.1 可变与不可变：为什么默认参数不能用空列表
面试官最喜欢的开场题之一，是下面这段代码：
python复制def add_item(item, bucket=[]):
bucket.append(item)
return bucket
print(add_item("a")) # ["a"]
print(add_item("b")) # ["a", "b"]
第一次调用返回 ["a"]，第二次调用返回 ["a", "b"]，而不是很多新人以为的 ["b"]。这里的关键不是“列表被改了”，而是 bucket=[] 这个默认值在函数定义时就被创建了一次，后续所有调用共享这同一个列表对象。
Python 函数默认参数在 def 语句执行时求值，而不是在每次函数调用时求值。只要理解了这句话，这个题就通了。[] 是一个可变对象，调用时不会重新创建，于是第一次 append 的数据留在了默认列表里，第二次调用继续基于同一份数据操作。
正确写法是使用哨兵值 None：
python复制def add_item(item, bucket=None):
if bucket is None:
bucket = []
bucket.append(item)
return bucket
同样道理可以延伸到字符串。字符串是不可变对象，+= 会创建新对象，在循环里拼字符串性能很差，正确做法是收集到列表后用 "".join(parts)。面试官问默认参数，其实是在考察你对“可变与不可变”“运行时绑定与定义时绑定”这两层概念是否清晰。
1.2 ==、is 与哈希：三个容易混在一起的概念
另一个高频组合题是：
python复制a = [1, 2, 3]
b = [1, 2, 3]
print(a == b) # True
print(a is b) # False
== 比较的是值是否相等，is 比较的是两个名字是否指向同一个对象。这个回答起来不难，难的是引申到哈希。面试官会追问：“如果我要把一个对象作为 dict 的 key，需要满足什么条件？”
答案是：对象必须可哈希，且满足“相等对象哈希值相同”。Python 中 list、dict、set 这类可变容器不可哈希，所以不能当 key；tuple 如果内部元素都可哈希，就可以当 key。自定义类如果要作为 key，需要同时实现 __hash__ 和 __eq__：
python复制class Point:
def __init__(self, x, y):
self.x = x
self.y = y
def __hash__(self):
return hash((self.x, self.y))
def __eq__(self, other):
return self.x == other.x and self.y == other.y
这里还有个易错点：is 不能拿来判断整数大小。CPython 对小整数（-5 到 256）有缓存，a = 257; b = 257; a is b 的结果在不同实现里可能不一样，依赖它是危险的。面试时如果说“整数用 == 判断，None 用 is None 判断”，会显得很有经验。
1.3 浅拷贝、深拷贝与 aliasing 现场
引用语义的第三个常见考点是拷贝。很多人知道 b = a 不是拷贝，但分不清浅拷贝和深拷贝。
python复制import copy
a = [[1, 2], [3, 4]]
b = a[:] # 浅拷贝
b[0].append(99)
print(a) # [[1, 2, 99], [3, 4]]，外层没变，内层变了
切片 a[:]、list(a)、copy.copy() 都是浅拷贝，只复制最外层容器，内层元素还是同一批对象。只有 copy.deepcopy(a) 会递归复制所有嵌套对象。
这个问题背后是 Python 的数据模型：变量名是贴在对象上的标签，不是装着对象的盒子。赋值操作只是让名字指向对象，并不会复制数据。理解了这个，很多 Python 里的“怪现象”都能解释了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一口气说透 Python 容器：列表、字典、集合的底层逻辑
2.1 列表扩容与元组压缩：内存真相
面试题：“列表的 append 为什么均摊复杂度是 O(1)？”这题考的是动态数组扩容。CPython 的 list 不是每次 append 都精确分配内存，而是预分配多余容量。小列表阶段容量会快速增长，大列表阶段大约按原长度的 1.125 倍左右扩容，把整体复制到新内存。因为扩容次数少，平摊下来每次 append 接近常数时间。
元组则完全不同。元组长度不可变，创建时就精确分配内存，没有预留空间，所以更省内存、访问开销也更小。这也是“能用元组就别用列表”这句建议的来源。如果数据量很大且不需要修改，用元组能让内存占用明显下降。
同级的经典题还有 sort 与 sorted 的区别。list.sort() 是原地排序，返回 None；sorted() 返回一个新列表，可作用于任何可迭代对象。key 参数非常常用，比如按字符串长度和字典序排序：
python复制words = ["banana", "apple", "cherry", "date"]
sorted(words, key=lambda x: (len(x), x))
2.2 字典为什么有序？哈希表与冲突处理
“Python 的 dict 是有序的吗？”这个题能劝退一批背答案的人。Python 3.7 开始，dict 的插入顺序在语言规范层面被保证，CPython 3.6 已经通过实现细节做到了。底层是“indices + entries”双数组结构：indices 负责哈希索引，entries 按插入顺序存储键值对。遍历时按 entries 顺序输出，自然就是插入序。
再往深问，字典底层是哈希表，通过计算 key 的哈希值定位槽位。哈希冲突时，CPython 使用开放寻址法，沿探测序列找下一个空槽。这也是为什么 dict 的 key 必须不可变：如果 key 内容变了，哈希值就变了，原本存储的位置就找不到了。
关于哈希还有一道衍生题：“两个内容相同的自定义对象，能作为同一个 dict key 吗？”答案是不能，除非 __eq__ 判断相等且 __hash__ 返回相同的哈希值。如果只实现 __eq__ 不实现 __hash__，Python 会让对象变成不可哈希的，因为协议要求相等对象哈希值必须一致。
2.3 集合与排序：面试官喜欢的延伸题
集合的考点集中在去重和哈希。给定一个列表，保持顺序去重，Python 3.7+ 的 dict 有序特性可以派上用场：
python复制items = ["a", "b", "a", "c", "b"]
unique = list(dict.fromkeys(items))
两步操作：dict.fromkeys 把元素作为 key，相同 key 自动去重，顺序就是第一次出现的顺序；再转回 list 就是去重结果。不用 set() 的原因是 set 不保证顺序。
集合的另一个高级话题是交集并集差集。求两个列表共同元素，用 set(a) & set(b) 通常比双层循环快一个数量级。面试官如果问“为什么快”，答案还是哈希表：判断元素是否在集合中，平均 O(1)，而列表 in 操作是 O(n)。
3. 装饰器与闭包：函数式风格的必考点
3.1 闭包陷阱：经典循环延迟绑定题
闭包几乎是 Python 面试题的“流量担当”，最经典的莫过于这段：
python复制funcs = []
for i in range(3):
funcs.append(lambda: i)
print([f() for f in funcs]) # [2, 2, 2]
期望输出 [0, 1, 2]，实际输出 [2, 2, 2]。原因是 lambda 捕获的是变量 i 本身，而不是创建时的值。循环结束后 i 停在了 2，所有函数调用时读到的都是 2。
修复方法有几种。一是用默认参数绑定当前值：
python复制funcs.append(lambda i=i: i)
二是用工厂函数：
python复制def make_func(x):
return lambda: x
funcs.append(make_func(i))
这个题考查的是“闭包捕获的是变量，不是值”这一本质。更进一步，面试官会问“如果要在闭包里修改外层变量怎么办”，答案是 nonlocal：
python复制def make_counter():
count = 0
def inc():
nonlocal count
count += 1
return count
return inc
3.2 装饰器执行顺序与 functools.wraps
装饰器的核心是“把函数作为参数传入，再返回一个新函数”。@decorator 等价于 func = decorator(func)。多个装饰器叠加时，装饰顺序从下往上，执行顺序从上往下：
python复制@deco_a
@deco_b
def hello():
print("hello")
等价于 hello = deco_a(deco_b(hello))，调用时先进入 deco_a 的 wrapper，再进入 deco_b 的 wrapper，最后执行原函数。
很多人漏掉的是 functools.wraps。如果不加 wraps，装饰后的函数 __name__、__doc__ 都会变成 wrapper 的，导致调试困难和日志异常。加 @wraps(func) 会把原函数的元信息复制过来，这才是生产环境的标准写法：
python复制from functools import wraps
def log(func):
@wraps(func)
def wrapper(*args, **kwargs):
print(f"call {func.__name__}")
return func(*args, **kwargs)
return wrapper
3.3 带参数装饰器与 partial、lambda 的配合
带参数装饰器需要三层函数，第一层接收装饰器参数，第二层接收被装饰函数，第三层接收调用参数：
python复制def retry(max_times=3):
def decorator(func):
def wrapper(*args, **kwargs):
for attempt in range(max_times):
try:
return func(*args, **kwargs)
except Exception:
if attempt == max_times - 1:
raise
return wrapper
return decorator
这个题能写出来的人不多，写出来还把 functools.partial 用上的人更少。partial 是偏函数，用于固定某些参数。比如给 int 固定进制：
python复制from functools import partial
basetwo = partial(int, base=2)
basetwo("101") # 5
partial 和带参装饰器没有直接关系，但面试官往往会连着问。它们的共同点是都体现了“Python 函数是一等对象”这个底层认知。
4. GIL 线程 进程 协程：并发编程选型题
4.1 GIL 到底是什么？它限制了谁
GIL（Global Interpreter Lock）几乎是必考题。首先要说清楚：默认的 CPython 解释器里有一把全局锁，同一时刻只能有一个线程执行 Python 字节码。这就导致纯 CPU 密集型任务在单进程多线程下无法利用多核。
但要说“Python 多线程没用”就不准确了。IO 密集型任务，比如网络请求、文件读写、数据库查询，线程在等待 IO 时会把 GIL 释放掉，其他线程可以继续执行。所以多线程对 IO 密集型场景仍然有效。这也是为什么爬虫用多线程能提速，但纯计算任务用多线程反而可能更慢。
Python 3.13 开始提供 free-threaded 的实验性构建，试图去掉 GIL，但主流 CPython 默认构建仍然保留 GIL。面试时提到这一点，说明你关注解释器演进，是加分项。
4.2 IO 密集用协程/线程，CPU 密集用进程的实战决策
面对并发题目，要先给决策框架：
- CPU 密集型：用多进程，通过
multiprocessing或concurrent.futures.ProcessPoolExecutor把任务分到多个进程，每个进程有独立的解释器和 GIL，可以并行。 - IO 密集型：用多线程或 asyncio 协程。协程更轻量，适合大量高并发的 IO 等待。
- 两者混合：通常用多进程 + 多线程或协程的组合，进程数按 CPU 核数，线程/协程数按 IO 并发需求。
一个典型的多线程示例：
python复制from concurrent.futures import ThreadPoolExecutor
def fetch_url(url):
return f"done: {url}"
with ThreadPoolExecutor(max_workers=8) as pool:
results = list(pool.map(fetch_url, urls))
asyncio 版本则更适合大量并发等待：
python复制import asyncio
async def fetch(url):
await asyncio.sleep(1)
return url
async def main():
tasks = [fetch(f"http://example.com/{i}") for i in range(10)]
results = await asyncio.gather(*tasks)
print(results)
asyncio.run(main())
这块内容信息量大，回答时先给结论再给原因，会让面试官觉得你脑子里有清晰的地图。
4.3 一道让很多人卡壳的并发打印题
一个经典面试题是：10 个线程同时对同一个整数做 10 万次自增，最后结果是多少？
python复制import threading
counter = 0
def work():
global counter
for _ in range(100000):
counter += 1
threads = [threading.Thread(target=work) for _ in range(10)]
for t in threads:
t.start()
for t in threads:
t.join()
print(counter) # 通常小于 1000000
答案是：通常小于 1000000。原因在于 counter += 1 不是原子操作，它分三步：读取当前值、加 1、写回。线程切换可能发生在任意两步之间，导致丢失更新。修复方案是加锁：
python复制lock = threading.Lock()
def work():
global counter
for _ in range(100000):
with lock:
counter += 1
引申问题还有 threading.local() 实现线程私有数据、queue.Queue 做线程安全队列等。这道题考查的是“GIL 不保证操作原子性”这个极易误解的点。
5. 魔法方法与对象协议：用题检验 Python 对象模型的认知
5.1 new 与 init 的分工
“创建对象时先调用 __new__ 还是先调用 __init__？”答案是先 __new__ 后 __init__。__new__ 是类方法，负责创建并返回实例；__init__ 负责初始化实例，不能返回任何值。
这个知识点的经典应用是单例模式：
python复制class Singleton:
_instance = None
def __new__(cls, *args, **kwargs):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
单例为什么要写在 __new__ 而不是 __init__？因为 __init__ 每次都会执行，无法阻止多次创建，控制实例创建入口只能在 __new__。
还可以延伸到不可变类型。自定义一个类继承 tuple 时，由于 tuple 不可变，初始化逻辑不能放在 __init__ 里改值，要在 __new__ 里完成。面试官问这个，基本就是想确认你对对象创建流程有真实理解。
5.2 slots 的内存收益与限制
__slots__ 的面试题通常是：“如果有百万个包含少量属性的对象，怎么优化内存？”
默认情况下，每个 Python 实例都有一个 __dict__ 字典，用来存实例属性。字典本身开销很大。用 __slots__ 声明固定属性后，实例不再创建 __dict__，改为紧凑的数组存储：
python复制class User:
__slots__ = ("name", "age")
def __init__(self, name, age):
self.name = name
self.age = age
u = User("tom", 18)
u.city = "sh" # AttributeError，不能动态添加属性
代价是失去了动态添加属性的能力。还有一个坑：子类如果没有定义 __slots__，子类实例仍然会有 __dict__。继承链上每一层都要声明 __slots__，内存优化才真正生效。
5.3 上下文管理器与属性拦截：低频高价值题
上下文管理器靠 __enter__ 和 __exit__ 实现，with 语句进入时调用 __enter__，离开时无论是否异常都会调用 __exit__。更简单的做法是用 contextlib.contextmanager 把生成器函数变成上下文管理器：
python复制from contextlib import contextmanager
import time
@contextmanager
def timer():
start = time.perf_counter()
try:
yield
finally:
print(f"cost {time.perf_counter() - start:.4f}s")
属性访问拦截的考点是 __getattr__ 与 __getattribute__ 的区别。__getattr__ 只在正常查找失败时调用，适合实现动态属性、延迟加载；__getattribute__ 对每次属性访问都会调用，容易写递归，实际项目中用得很少。能在面试现场准确区分这两者的人，对 Python 对象模型的理解已经超过大部分候选人。
6. 手撕代码：从“李白打酒”看回溯与记忆化搜索
6.1 题目还原与逆向推导：原有多少斗酒
“李白街上走，提壶去买酒。遇店加一倍，见花喝一斗。三遇店和花，喝光壶中酒。试问壶中原有多少酒？”
这道题出现在搜索热词里不是没道理，它考察的核心能力是逆向思维。按“店、花、店、花、店、花”的次序理解，最后一步是见花后酒为 0，那见花前酒量就是 1。逆推过程：
- 第 3 次见花前：0 + 1 = 1
- 第 3 次遇店前：1 ÷ 2 = 0.5
- 第 2 次见花前：0.5 + 1 = 1.5
- 第 2 次遇店前：1.5 ÷ 2 = 0.75
- 第 1 次见花前：0.75 + 1 = 1.75
- 第 1 次遇店前：1.75 ÷ 2 = 0.875
所以原酒量是 7/8 斗。正向验证：7/8 → 遇店 7/4 → 见花 3/4 → 遇店 3/2 → 见花 1/2 → 遇店 1 → 见花 0，完全自洽。
写代码时可以从 0 开始模拟每次“遇店乘 2、见花减 1”，判断最后是否为 0，但更好的方式是直接讲清楚逆向递推。面试官看重的不是你会不会乘除法，而是能不能把“终点状态明确”作为逆向推导的起点。
6.2 DFS 计算方案数：状态设计与剪枝
把原题改成算法题是常考变体：给定店的操作次数 n、花的操作次数 m、初始酒量 initial，求有多少种合法操作序列，使得最后一步是花且酒正好喝完。
可以用 DFS 加记忆化搜索，状态是三元组：剩余店次数、剩余花次数、当前酒量。
python复制from functools import lru_cache
def count_orders(n, m, initial):
@lru_cache(None)
def dfs(shop_left, flower_left, wine):
# 剪枝：酒量不能为负，也不能“喝不完”
if wine < 0 or wine > flower_left:
return 0
if shop_left == 0 and flower_left == 0:
return 1 if wine == 0 else 0
ans = 0
if shop_left > 0:
ans += dfs(shop_left - 1, flower_left, wine * 2)
if flower_left > 0 and wine > 0:
ans += dfs(shop_left, flower_left - 1, wine - 1)
return ans
return dfs(n, m, initial)
这里有一个容易忽视的剪枝条件：wine > flower_left 时直接返回 0。因为剩余的花操作最多消耗 flower_left 斗酒，而遇店只会让酒量增加，所以如果当前酒量已经大于剩余花数，最后一定喝不光。这个剪枝是安全的，也体现了对问题结构的理解。
lru_cache 在这里等价于记忆化搜索。状态总数大约等于 shop_left、flower_left、wine 三个维度的组合数，实际搜索空间远小于暴力枚举所有排列，面试官问到复杂度时可以从这个角度回答。
6.3 从这道题看面试手撕环节的三个加分细节
第一，先定义状态再写代码。很多人上来就写递归，写完发现终止条件不对。先说出“状态是剩余店数、剩余花数、当前酒量”，再写代码，思路会清晰很多。
第二，主动提剪枝。上面 wine > flower_left 的剪枝不是题目硬性要求的，但说出来会让面试官看到你对“搜索空间”的敏感度。
第三，验证边界。比如 initial 为 0 且 n、m 都大于 0 时，合法方案数一定是 0，因为遇店对 0 没作用，见花又要求酒量大于 0。能把这种极端情况主动说出来，比闷头写一大堆代码有用得多。
我在评审候选人时最看重的，往往不是代码是否一次跑通，而是这个人能不能把“为什么会这样”讲明白。Python 面试题看似零散，其实都指向同一个底层能力：对对象模型、执行模型和内存模型的真实理解。如果你能把这篇合集里的每一题都自己动手跑一遍，再试着用口语跟同事讲一遍，面试状态会比只背题库的人稳很多。