因为子进程内存隔离，全局变量无法共享；Manager通过IPC代理实现协调，适合小量状态传递而非高性能场景。
为什么直接用全局变量在multiprocessing里行不通
因为每个子进程拥有独立的内存空间，父进程里的全局字典、列表在子进程中是完全隔离的副本。改了没用，也看不到其他进程的修改。这不是线程，没有共享内存，默认一切都不共享。
-
Manager()本质是启一个服务进程，所有共享对象都由它托管，其他进程通过代理（proxy）远程读写 - 所有通过
Manager().list()、Manager().dict()创建的对象，底层走的是跨进程通信（IPC），不是内存共享，所以有明显开销 - 不要把它当成“高性能共享容器”用——它适合协调、同步、小量状态传递，比如任务计数、运行标志、结果汇总
哪些数据类型能用Manager安全共享
Manager 支持的类型有限，且不是所有操作都原子。常用且相对稳妥的有：
-
Manager().dict()：支持<strong>setitem</strong>、<strong>getitem</strong>、keys()、values()，但dict.update()不是原子操作 -
Manager().list()：支持索引、切片、append()、pop()，但list.extend()会触发多次 IPC 调用 -
Manager().Value()和Manager().Array()：只适用于基础类型（'i'、'd'等 ctypes 类型），性能比 dict/list 高，但无动态结构能力 -
Manager().Queue()和Manager().Lock()：推荐用于任务分发和临界区控制，比手动同步更可靠
别试图用 Manager().dict()['nested'] = {'a': 1} 去嵌套赋值——内层字典不会被自动代理，后续修改不会同步。
Manager启动慢、吞吐低？试试这几种优化方式
Manager 启动本身要 fork 进程 + 建立 socket 连接，首次调用延迟明显；高频读写还会因序列化/反序列化拖慢整体吞吐。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 把共享结构拆细：不要一个大
Manager().dict()存所有状态，按职责拆成多个小对象（如status_dict、result_dict），减少锁争用 - 读多写少场景下，考虑“定期快照”：子进程本地缓存一份副本，只在必要时从
Manager拉一次最新值，避免每轮都 IPC - 写操作尽量批量：比如用
list.extend(items)代替循环list.append(item)，虽然仍非原子，但能显著减少 IPC 次数 - 如果只是需要进程间通知，优先用
multiprocessing.Event()或Queue.put_nowait()，它们比 Manager 轻量得多
常见报错和调试盲点
遇到 AttributeError: 'AutoProxy[dict]' object has no attribute 'update' 或 TypeError: cannot pickle '_thread.RLock' object 是最典型的信号。
-
Manager代理对象不支持所有原生方法：dict.update()、list.sort()、list.reverse()都不可用，必须用等价的循环或重建方式替代 - 不要把带线程锁、文件句柄、数据库连接的对象塞进 Manager——它们无法被序列化（pickle），会直接抛
TypeError - 在 Windows 上，
Manager必须在if <strong>name</strong> == '<strong>main</strong>':下启动，否则子进程重复初始化导致卡死或 OSError - 调试时别依赖
print(shared_dict)——它输出的是代理对象本身，看不出真实内容；要用dict(shared_dict)或list(shared_list)强制取值
Manager 不是万能共享总线，它的存在意义是“让跨进程协作变得可行”，而不是“让并发数据结构变快”。真正高吞吐的共享，得靠 multiprocessing.Array + ctypes 手动管理，或者换用 Redis 这类外部服务。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
