GIL（Global Interpreter Lock）是CPython解释器中的一把全局互斥锁，它确保任何时刻只有一个线程在执行Python字节码。GIL存在的根本原因是CPython的内存管理机制——引用计数。每个Python对象都有一个引用计数器，当引用变为0时对象被回收。如果没有GIL，多线程并发修改引用计数会导致竞态条件，可能出现内存泄漏或对象被提前释放。GIL大约每5ms释放一次（Python 3.2+改为基于时间的切换机制），让其他线程有机会执行。对于I/O密集型任务，GIL影响不大——线程在执行网络请求、文件读写、数据库查询等I/O操作时会主动释放GIL，其他线程可以趁机执行。所以多线程爬虫、Web服务的并发请求处理是完全有效的。但对CPU密集型任务（数值计算、图像处理、数据转换），GIL是性能瓶颈。多个线程竞争GIL反而增加了上下文切换开销，可能比单线程更慢。解决方案有几种：第一是multiprocessing模块，启动多个进程，每个进程有独立的Python解释器和GIL，实现真正的并行，缺点是内存开销大、进程间通信复杂。第二是使用NumPy、Pandas等C扩展库，它们在执行底层C代码时会释放GIL。第三是asyncio协程，单线程内通过协作式多任务实现并发，适合I/O密集场景。第四是Python 3.13引入的实验性free-threaded模式（PEP 703），通过per-object锁和延迟引用计数完全移除了GIL，可以实现真正的多线程并行。需要注意的是，GIL是CPython的实现细节，Jython（Java实现）和IronPython（.NET实现）没有GIL。

Python装饰器的原理基于两个核心概念：函数是一等对象和闭包。在Python中，函数可以像普通变量一样传递和返回。闭包是指内部函数引用了外部作用域的变量，即使外部函数执行结束，这些变量仍然存活在内部函数的__closure__中。装饰器本质上就是一个接收函数、返回函数的高阶函数。@my_decorator放在函数定义上方，等价于func = my_decorator(func)。标准写法是：def my_decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): 前置逻辑; result = func(*args, **kwargs); 后置逻辑; return result; return wrapper。这里functools.wraps非常重要，它会把原函数的__name__、__doc__、__module__等元信息复制到wrapper上，不加的话调试时看到的函数名是wrapper而不是原函数名。带参数的装饰器需要三层嵌套：最外层接收装饰器参数，中间层接收被装饰函数，内层是wrapper。例如@retry(max_attempts=3)，先执行retry(max_attempts=3)返回真正的装饰器，再用这个装饰器包装函数。类装饰器通过实现__init__（接收函数）和__call__（执行逻辑）来实现，好处是可以维护调用间的状态。多个装饰器堆叠时从下往上包装：@A @B def func相当于func = A(B(func))，执行时A的前置逻辑先执行。实际项目中常见的装饰器包括：Flask的@app.route绑定路由、@property实现属性访问器、@functools.lru_cache实现缓存、@pytest.fixture管理测试依赖等。

asyncio是Python自带的单线程协作式并发——一个线程、一个事件循环、多个协程轮流执行。协程、Task、Future三个概念最容易搞混。协程是async def函数不加await调用时得到的对象：async def foo(): ...，c = foo()返回的是coroutine对象不是结果。它是挂起的代码——保留了局部状态但还没执行。让它跑有两种方式：另一个协程里await它（串行），或者包成Task（并发）。Future是底层占位符——"这里将来会有个值"。它有状态pending/finished/cancelled，和一个最终被set的result。业务代码几乎不直接创建Future，底层库在用。Task是Future的子类，它包装一个协程并注册到事件循环，让这个协程和其他Task并发跑。asyncio.create_task(coro)显式创建，asyncio.gather(*coros)隐式批量创建——gather会等所有task完成返回result列表。事件循环本身是个调度器+selector。每个await点要么awaited的值已就绪立即返回，要么告诉loop"文件描述符/定时器/Future就绪了叫我"。loop在epoll（Linux）里睡觉直到有注册事件触发，再恢复对应协程。因为全程单线程，协程之间没有GIL竞争——就是你一步我一步轮流。这让asyncio非常适合IO密集——同时跑几千个HTTP请求或数据库查询毫不费力——但完全不适合CPU密集，CPU活会卡死这个单线程。最经典的坑是协程里调了阻塞函数（requests.get、time.sleep、同步DB驱动）——整个loop冻住，所有在等的协程都被拖住。CPU任务要用asyncio.to_thread或run_in_executor把阻塞调用丢到线程池。

Python的GC是两层机制。主力是引用计数——CPython每个对象的C结构里有refcount字段，每次引用操作都+1或-1。归零立即释放——tp_dealloc调用、析构函数跑、内存还给分配器。这和JVM本质不同——大部分Python对象回收是确定性同步的，不用等GC周期。代价是每次赋值和函数调用都有计数开销，这也是CPython比JIT过的JVM慢的原因之一。第二个缺点：引用计数处理不了循环。对象a持有b的引用，b持有a的引用，refcount互相算着，外面没人引用时两个都不会归零。Python用分代循环GC解决——gc模块周期性扫容器对象（list、dict、class等任何可以装引用的），用mark-sweep找不可达环并释放。三代：新建容器进gen 0，存活升gen 1，再存活升gen 2。高代扫得少，基于"活久了的对象更可能继续活"的假设。触发阈值默认(700, 10, 10)——gen 0在净分配700次后扫、gen 1在gen 0扫10次后扫，以此类推。不是时间触发，纯粹分配压力触发。实战含义：gc.collect()强制全量回收，内存敏感操作前可以调。gc.disable()在性能关键热路径里用——避免不可预测停顿，之后要记得enable+collect。提前知道的"逻辑循环"——比如DOM树或树数据结构的父子引用——用weakref.ref或weakref.proxy根本不创建循环，让引用计数确定性回收，比等循环GC更高效。

GIL的由来：CPython用引用计数，每次操作都原子化计数会让单线程性能崩盘。于是用一把全局锁串行化字节码执行。面试级结论：CPU密集线程不加速（被串行化），IO密集线程能加速（阻塞IO时GIL释放）。爬虫、socket、DB查询用线程OK。数值计算要么用multiprocessing、要么靠numpy/torch这类在C层释放GIL的库。Python 3.13 free-threaded是实打实的进展但生产多数还是有GIL。口诀：CPU密集→多进程或C扩展；IO密集→asyncio（比线程更干净）；混合→带队列的线程池。

装饰器就是任意"接受函数返回可调用"的东西。`@foo`在`def f()`上面等价于`f = foo(f)`。套路：外层函数里定义wrapper，wrapper在调用原函数前后加逻辑，返回wrapper。永远在wrapper上加`@functools.wraps(fn)`——否则__name__、__doc__、trace都会变成"wrapper"。`@retry(times=3)`要三层：retry(times)返回decorator(fn)，decorator返回wrapper(*a, **kw)在其中循环捕获异常。带参数装饰器绕晕人的点：最外层拿到参数，它的返回值才是真正的装饰器。

三向选择。CPU密集：multiprocessing或原生（numpy/numba）——threading被GIL卡住没法并行。IO密集<100并发：线程够简单够用。IO密集上千并发socket：asyncio——事件循环比每连接一线程扩得多。混合场景常见：asyncio调度IO、CPU热点用run_in_executor丢进ProcessPoolExecutor。坑：asyncio handler里任何同步阻塞都冻结整个loop——要用to_thread包。Windows的multiprocessing一切都pickle重启，闭包不保留。我新服务默认asyncio、数据管道式CPU任务用multiprocessing。