manager.dict()和manager.list()返回代理对象，不支持.update()或+=等原生方法，调用会报AttributeError；需用逐项赋值、extend()或初始化传参方式操作，且必须在with Manager()上下文内使用。
为什么 manager.dict() 和 manager.list() 不能直接用 .update() 或 +=
因为 manager.dict() 返回的是代理对象（proxy），不是原生 dict，它不支持所有原生方法。调用 .update() 会触发 AttributeError: 'DictProxy' object has no attribute 'update'；同理 manager.list() + [1,2] 或 += 也会失败。
实操建议：
- 逐项赋值：
shared_dict['key'] = value，或用循环for k, v in data.items(): shared_dict[k] = v - 初始化时传入数据：
manager.dict({'a': 1, 'b': 2})是安全的 - 想批量追加列表项？用
shared_list.extend([x, y, z])，而不是+=
manager.Value('i', 0) 中的 'i' 不是 Python int 类型
Value 的第一个参数是 ctypes 类型码，不是字符串化的 Python 类型名。写成 Value('int', 0) 或 Value(int, 0) 都会报 TypeError。
常见类型码对照：
立即学习“Python免费学习笔记（深入）”；
-
'i'：有符号 32 位整数（对应ctypes.c_int） -
'd'：双精度浮点数（ctypes.c_double） -
'f'：单精度浮点数（ctypes.c_float） -
'c'：字符（ctypes.c_char）
修改值必须显式访问 .value 属性：counter.value += 1，直接写 counter += 1 不生效。
Manager 启动服务进程带来隐性开销
Manager() 实际会 fork 出一个独立的服务进程来托管共享对象，所有读写都经由 IPC（进程间通信）序列化/反序列化。这意味着：
- 每次访问
shared_dict['x']比本地字典慢 10–100 倍 - 在 tight loop（比如每毫秒更新一次的监控循环）里频繁读写，性能会明显拖垮主逻辑
- 对象内容必须可被
pickle序列化；含 lambda、嵌套不可序列化对象会报PicklingError
如果只是计数或开关标志，优先考虑 Value；若需结构化但读写不密集，再用 Manager。
with Manager() as manager: 必须缩进在上下文内使用
离开 with 块后，manager 自动 shutdown，所有代理对象失效。常见错误是把 shared_dict 提前赋值给模块级变量，然后在 with 外调用：
shared_dict = None
with Manager() as manager:
shared_dict = manager.dict()
# 此处 shared_dict 已失效，再访问会抛 RuntimeError正确做法：所有子进程启动、数据读取、结果收集，全部放在 with 块内部完成。别试图“缓存”代理对象到外部作用域。
多进程共享变量最易被忽略的点，其实是生命周期管理——Manager 不是“创建一次、随处可用”的全局句柄，它和文件句柄一样，需要严格配对打开与关闭。一旦越界访问，错误可能延迟到子进程 join 后才暴露，排查成本很高。
