ITPub博客

1. 基础回顾：负索引怎么算的Python 里负索引是从右往左数的，-1是最后一个元素，-len(lst)是第一个元素。这个大家都懂。切片语法 lst[start:stop:step]里，start 和 stop 都可以是负数。Python 的处理方式是：先把负索引转换成对应的正索引，然后再做切片。a = [0, 1, 2, 3, 4, 5]# a[-1] -> a[5] -> 5#

好，这个问题属于那种平时不用没事，一旦要用就全是坑的典型。__reduce__这东西是 Python pickle 协议的核心钩子，但它设计的出发点跟大多数人想的完全不一样。先给你泼盆冷水：__reduce__不是为了让你方便地序列化对象，而是为了让那些没法正常 pickle 的对象能被 pickle。 这两个目标看着差不多，实际差远了。1. __reduce__到底返回什么？先看最基本的。__r

很多人直觉上觉得，我父进程里 signal.signal(signal.SIGINT, handler)注册好了，fork出来的子进程自然也会用这个 handler。但实际跑起来你会发现各种诡异——要么信号根本没反应，要么直接默认终止了。咱们一步步拆。1. 最典型的翻车现场：subprocess.Popen启动的子进程这是最常见的坑。你用 Popen启动一个子进程，然后在父进程里给它发信号：imp

ChainMap的写操作（增、删、改）永远只作用在它自己的 maps列表里的第一个字典上。来，我给你拆解一下这个“非直觉”到底体现在哪。1. 你以为改了“全部”，其实只改了“第一个”假设我们有这么个场景：pythonfrom collections import ChainMapdefaults = {'color': 'red', 'font':

这个问题其实挺经典的，尤其是在写多层装饰器的时候，经常会出现“明明加了装饰器，结果返回的东西不对了”的情况。我给你拆一下本质原因和常见的翻车现场。核心原因：装饰器的返回值替换装饰器的本质就是一个高阶函数，它接收原函数，返回一个新函数。如果你在装饰器内部没有正确地传递返回值，那原函数的返回值就会被吞掉。看这个典型的错误写法：def log_decorator(func):   

这个坑属于那种你写代码时觉得“这有什么好说的”，然后线上出 bug 查半天才发现的问题。我直接给你拆几个最容易翻车的场景。核心问题：None 在条件判断中的隐式转换Python 里 None在布尔上下文中等价于 False，但这跟显式的 is None判断完全是两码事。很多人习惯写 if not x:来判空，但 x为 0、""、[]、{}的时候也会走进这个分支。def proc

这个问题其实比大多数人想的要阴险，尤其是涉及到消费者被取消时队列里还有未处理的消息这种场景。我直接给你拆几个典型边缘情况。核心问题：取消不等于消费很多人以为 task.cancel()之后，队列里的元素会自动回退或者消失。完全不是。asyncio.CancelledError是在 await点抛出的异常，如果你的消费者正在 queue.get()上阻塞，取消会直接把这个等待打断，但那个元素永远留在

这个问题确实坑过不少人。简单说，Python内置的hash()函数在同一个程序的不同运行实例里，对同一个字符串或者自定义对象返回的值可能不一样。这不是bug，而是安全机制。根本原因Python解释器启动时会随机生成一个PYTHONHASHSEED种子值。默认情况下这个种子是随机的，导致每次运行的哈希表排列不同。这是为了防止针对字典/集合的Hash DoS攻击——如果有人能预测哈希碰撞规律，就能构造

元组拆包的异常处理有几个很“坑”的地方，特别是和其他语言的习惯不一样。第一个坑：拆包时的异常不会回滚data = [1, 2, 3]try:    a, b, c, d = data  # 这里ValueErrorexcept ValueError:    print(f"拆包失败，但前面已经赋值了？a={a}") 

contextlib.ExitStack的异常传播确实有些边角情况容易踩坑。先说最关键的：多个上下文管理器出错时，只有最后一个异常会抛出来，前面的异常被压制了。看看这个典型场景：pythonfrom contextlib import ExitStackdef risky_operation():    with ExitStack() as stack:  &nbs

生成器表达式和闭包组合时有个经典的“延迟绑定”问题。直接上代码示例最容易说明：def create_multipliers():    return (lambda x: i * x for i in range(5))multipliers = list(create_multipliers())print([m(2) for m in multipliers]) 

动态修改模块全局变量在工程实践中存在多种风险，主要包括以下几个方面：破坏封装性与可维护性模块的全局变量本质上是模块内部的状态，外部直接修改会破坏模块边界的完整性。后续维护时，状态变更的源头难以追踪，尤其是在多人协作或代码量较大的项目中，容易引发不可预知的副作用。线程安全问题若模块被多线程引用，直接修改全局变量可能导致数据竞争（race condition）。即使使用global关键字或setatt

Property 装饰器在多继承下的冲突问题1. MRO 顺序导致的属性覆盖class A:    @property    def value(self):        print("A.value")        return "A&quot

Python 弱引用回调的执行时机陷阱Python 弱引用的回调函数（__callback__）执行时机有很多微妙之处，以下是主要的陷阱：1. 不确定的执行时机import weakrefimport gcclass MyClass:    def __del__(self):        print("对象被销毁"

1. 异常处理不完整# ❌ 危险写法async with resource:    raise RuntimeError("Oops")    # 如果 resource.__aexit__ 中也抛出异常，原始异常会被隐藏# ✅ 正确写法try:    async with resource:   

在 Python 中，动态修改模块全局变量（module-level global variables） 虽然方便，但可能带来不少隐蔽问题，尤其是在大型项目、多线程程序和长期运行服务中。1. 意外影响所有导入者假设有一个配置模块：# config.pyDEBUG = False其他地方引用：import configprint(config.DEBUG)运行时修改：import configcon

Python 的字符串 intern（驻留）机制，是最容易出现：“明明内容一样，为什么有时候 is=True，有时候又 False？”的经典陷阱。很多人第一次看到：a = "hello"b = "hello"print(a is b)输出：True会误以为：Python 的字符串都会自动复用内存。实际上根本不是。1. == 和 is 根本不是一回事先区分：a

time.sleep() 和事件循环（尤其是 asyncio）最大的冲突点：time.sleep() 会阻塞整个线程。而事件循环本质上：单线程 + 协作式调度所以一旦你在 async 环境里用了 time.sleep()：整个事件循环都会“卡死”。这是 Python 异步编程里最经典的坑之一。1. 最典型错误很多人会这样写：import asyncioimport timeasync def ta

1. 最反直觉的地方先看：print(0.0 == -0.0)输出：True但：print(str(0.0))print(str(-0.0))输出：0.0-0.0说明：Python 明确认得“负零”。2. 为什么会存在负零因为 IEEE 754 浮点数：浮点结构：符号位 + 指数位 + 尾数位即使数值是 0：符号位仍然存在。所以：+0.0-0.0是两个不同 bit pattern。3. 最经典的坑

multiprocessing.Pipe 看起来像“进程间直接传对象”，但它本质上依赖 pickle 序列化。一旦传输复杂对象，就会出现很多容易忽略的问题。下面是几个最常见、最坑的陷阱。1. 以为传的是“共享对象”很多人第一次用 Pipe 时，会误以为子进程修改对象会影响父进程。实际上：Pipe.send(obj)会先 pickle子进程收到的是“反序列化后的副本”例如：from multipro