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）或共享内存实现，自带序列化和同步。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• multiprocessing.Queue 的 put() 和 get() 会 pickle/unpickle 数据，因此对象必须可序列化（不能含 lambda、嵌套闭包、文件句柄等）
• 队列满时 put() 默认阻塞，可通过 timeout 参数控制，但超时抛出 Full 异常，不是返回 False
• 主进程结束前应确保子进程已消费完消息，否则可能死锁；推荐配合 join_thread() 或显式调用 close() + join_thread()
• 大量小消息易引发 IPC 开销，不如批量传 Array 或用 Manager().list() 缓存后再刷入

共享数据时容易被忽略的初始化时机

子进程启动时不会自动继承父进程中已创建的共享对象引用——尤其是 Manager() 创建的对象，必须显式传参或通过全局变量（在 if <strong>name</strong> == '<strong>main</strong>': 下定义）访问。

立即学习“Python免费学习笔记（深入）”；

• 在 Windows/macOS 上，spawn 启动方式会重新导入主模块，若共享对象在顶层创建，每个子进程都会新建一份，而非共享同一份
• 正确做法是把共享对象作为参数传给 Process(target=..., args=(shared_dict,))，或在子进程函数内部通过 Manager() 实例获取（但注意 Manager 进程必须持续运行）
• 使用 fork（Linux 默认）看似能继承，但 Manager 对象仍是代理，其底层连接仍需主进程的 Manager 进程存活；一旦 Manager 进程退出，所有代理失效，后续操作抛 RemoteError

共享本身不难，难的是清楚每种机制的边界在哪里：什么时候该用 Value，什么时候宁可多走一趟 Manager 也要换灵活性，以及为什么看似一样的代码在 Windows 和 Linux 上行为不同。这些细节往往在压测或切换平台时才暴露。