list.append()是原子操作，CPython中由单条字节码LIST_APPEND实现且受GIL保护，线程安全；而list += [...]等价于extend()，需循环调用append，中间可能被中断，非原子。
list.append() 是原子的，但 list += [...] 不是
Python 的 list.append() 和 list.pop() 确实被 CPython 实现为字节码层面的单条指令（LIST_APPEND、LIST_POP），在 GIL 保护下是线程安全的。但「原子」只针对该操作本身，不延伸到复合逻辑。
常见误判点：
-
L += [x]看似简单，实际等价于L.extend([x])，而extend内部会循环调用append，中间可能被线程切换打断 -
L[i] = x涉及索引查找 + 赋值两个步骤，不是原子操作 -
L.sort()、L.reverse()这类就地修改方法全程持有 GIL，但它们不保证“对外可见性”——其他线程可能在你调用中途读到中间态
验证方式：用 dis.dis(lambda: L.append(1)) 看到只有 1 条指令；而 dis.dis(lambda: L += [1]) 会显示多条 LOAD/BINARY_ADD/STORE 指令。
竞态条件常出现在“读-改-写”组合中
最典型的非原子场景是“先判断再修改”，比如：
立即学习“Python免费学习笔记（深入）”；
if len(L)if x in L: L.remove(x)L[0] = L[0] + 1
这些都不是单步动作。即使 append 自身原子，前面的 len() 或 in 检查和后续 append 之间存在时间窗口，多个线程可能同时通过检查，然后都执行 append，导致超限或重复。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
错误现象：两个线程同时执行 if len(L) == 0: L.append("first")，结果 L 变成 ["first", "first"]。
threading.Lock 不能只锁“修改”，还要锁“读-改-写”整个临界区
很多人以为只要给 append 加锁就够了，其实错在粒度不对：
- 如果只锁
append，那len(L)、L[0]、for x in L:这些读操作仍可并发执行，可能读到不一致状态 - 迭代时修改列表（如边遍历边
remove）会直接触发RuntimeError: list changed size during iteration，这不是线程问题，而是 Python 解释器的保护机制，但它暴露了更深层的同步缺失
正确做法：把所有依赖列表当前状态的逻辑包进同一把锁里，例如：
with lock:
if len(L) < 10:
L.append(x)
# 其他基于 L 当前状态的操作也放在这里别信“GIL 保你平安”这种经验主义
GIL 只保证「单个字节码指令」不被中断，不保证你的业务逻辑有确定性。比如：
-
counter += 1编译成 3 条字节码（LOAD→INPLACE_ADD→STORE），GIL 可能在任意两条之间释放 - 同样，
L[i] += x是先取值、再算、再存，三步全可打断
真正安全的边界是：你自己定义的「临界区」——即一段必须以原子方式执行、不允许其他线程穿插的代码块。这个边界由你画，不是由 GIL 划。
复杂点在于，有些看似安全的操作（比如只读 len(L)）在极端并发下也可能因缓存不一致导致逻辑错乱；最容易被忽略的是「迭代过程中允许外部修改」这一假设——它从来就不成立，无论有没有多线程。
