multiprocessing.Manager()适合低频修改、多进程只读或偶发更新的协调场景，如任务状态汇总、配置热更新；其代理对象需显式传参，不支持in-place操作且性能较低。
multiprocessing.Manager() 适合什么场景
Manager() 提供进程安全的共享对象，比如 dict、list、Namespace，底层通过服务器进程代理访问。它不是为高频读写设计的，而是适合「低频修改 + 多进程只读或偶发更新」的协调场景，比如任务状态汇总、配置热更新、简单计数器。
- 修改操作会序列化并跨进程通信，性能比本地对象低一个数量级
- 不支持任意自定义类，只能用
Manager().dict()等显式构造的类型 - 所有子进程拿到的是代理对象，不能直接对底层内存做 in-place 操作（例如
my_list.append()可以，但my_list += [1,2]可能出错或不生效） - 如果主进程退出而未调用
.shutdown()，子进程可能卡在连接上
multiprocessing.Value 和 Array 为什么快但受限
Value 和 Array 直接映射到共享内存，无序列化开销，适合单值或固定长度数组的高性能共享，比如全局计数器、缓冲区、标志位。
-
Value('i', 0)中的'i'是 ctypes 类型码，必须严格匹配（'d'表示 double，'b'表示 signed char），写错会导致静默截断或段错误 -
Array('i', [1,2,3])初始化后长度固定，不能.append()或del - 不支持嵌套结构：不能用
Array存字典或列表，也不能存 Python 对象引用 - 多进程并发读写同一
Value时需手动加锁（Lock()），否则数值可能丢失（例如两个进程同时执行counter.value += 1）
queue.Queue 与 multiprocessing.Queue 的根本区别
标准库的 queue.Queue 是线程安全的，不能用于多进程；跨进程必须用 multiprocessing.Queue，它基于管道（pipe）或共享内存实现，自带序列化和同步。
-
multiprocessing.Queue的put()和get()会 pickle/unpickle 数据，因此对象必须可序列化（不能含 lambda、嵌套闭包、文件句柄等） - 队列满时
put()默认阻塞，可通过timeout参数控制，但超时抛出Full异常，不是返回 False - 主进程结束前应确保子进程已消费完消息，否则可能死锁；推荐配合
join_thread()或显式调用close()+join_thread() - 大量小消息易引发 IPC 开销，不如批量传
Array或用Manager().list()缓存后再刷入
共享数据时容易被忽略的初始化时机
子进程启动时不会自动继承父进程中已创建的共享对象引用——尤其是 Manager() 创建的对象，必须显式传参或通过全局变量（在 if name == 'main': 下定义）访问。
立即学习“Python免费学习笔记（深入）”；
- 在 Windows/macOS 上，
spawn启动方式会重新导入主模块，若共享对象在顶层创建，每个子进程都会新建一份，而非共享同一份 - 正确做法是把共享对象作为参数传给
Process(target=..., args=(shared_dict,))，或在子进程函数内部通过Manager()实例获取（但注意 Manager 进程必须持续运行） - 使用
fork（Linux 默认）看似能继承，但 Manager 对象仍是代理，其底层连接仍需主进程的 Manager 进程存活；一旦 Manager 进程退出，所有代理失效，后续操作抛RemoteError
共享本身不难，难的是清楚每种机制的边界在哪里：什么时候该用 Value，什么时候宁可多走一趟 Manager 也要换灵活性，以及为什么看似一样的代码在 Windows 和 Linux 上行为不同。这些细节往往在压测或切换平台时才暴露。
