Manager通过启动独立管理进程托管共享对象，其他进程用代理对象发RPC请求操作，每次访问均需IPC，开销大；普通dict/list因进程内存隔离无法直接共享；嵌套结构需显式用manager.dict()创建；操作非原子且性能差，高并发下管理进程成瓶颈。
Manager 是怎么让 dict/list 跨进程共享的
它不直接共享内存，而是启动一个独立的管理进程（SyncManager 子进程），所有共享对象都由这个进程托管。其他进程通过代理（proxy）对象间接读写——实际是发 RPC 请求给管理进程，由它完成操作再返回结果。
这意味着：dict 和 list 看起来像本地对象，但每次访问（哪怕只是 len(d) 或 d.keys()）都涉及进程间通信（IPC），开销远大于普通对象。
为什么不能直接传普通 dict/list 给子进程
因为 multiprocessing 默认用 fork（Unix）或 spawn（Windows/macOS）方式启动子进程，父子进程内存空间完全隔离。你传一个普通 dict，子进程拿到的是副本，修改不会反映回父进程，反之亦然。
常见错误现象：
- 子进程中修改
shared_dict['x'] = 1，父进程里读不到变化 - 用
manager.dict()初始化后，误当成普通dict调用.update()或解包（{**d}），结果报TypeError: unhashable type: 'DictProxy'
Manager.dict() 和 Manager.list() 的行为边界
它们只保证顶层对象可共享，嵌套结构默认不自动代理。比如：
d = manager.dict()
d['nested'] = {'a': 1} # ❌ 这个内层 dict 不受管理，修改不会同步
d['nested'] = manager.dict(a=1) # ✅ 才能跨进程更新 a常用操作兼容性注意点：
-
dict支持：__getitem__,__setitem__,keys(),values(),items()，但不支持popitem()、setdefault()（会抛AttributeError） -
list支持：append(),extend(),__getitem__,__setitem__，但不支持切片赋值（l[1:3] = [4,5]报错） - 所有操作都不是原子的——
d['x'] += 1是读+算+写三步，多进程下可能丢更新，需配合Lock
性能差在哪？什么时候该换方案
每次访问都要走 IPC，实测在千次级操作时延迟已是毫秒级；若频繁读写（如循环中反复 d[k] += 1），性能可能比单进程还慢。
替代建议：
- 高频小数据：改用
multiprocessing.Queue或multiprocessing.Pipe主动推送变更 - 只读大字典：用
multiprocessing.Value+ctypes或序列化后共享内存（shared_memory模块，Python 3.8+） - 需要原子计数器：直接用
multiprocessing.Value('i', 0)配合Lock，比Manager.dict()快一个数量级
最易被忽略的一点：Manager 进程本身是单点，如果大量子进程同时高并发调用，它会成为瓶颈，且一旦崩溃，所有 proxy 对象失效——别把它当数据库用。
