直接传普通类实例会失效，因含Lock、文件句柄等不可序列化对象会报错，且子进程修改的是独立副本，主进程无感知；需用Manager注册、Value/Array或SharedMemory方案实现跨进程状态共享。
直接传普通类实例会失效
Python多进程默认用pickle序列化参数，但大多数自定义类实例无法被正确序列化——尤其是含threading.Lock、文件句柄、生成器、闭包或C扩展对象的实例。即使能序列化，子进程拿到的也只是副本，修改不会回传到主进程。
常见错误现象：AttributeError: Can't pickle local object 或主进程看到的实例字段完全没变。
- 不是所有类都支持
pickle；__getstate__/__setstate__需手动实现才能控制序列化行为 - 即使序列化成功，子进程修改的是独立副本，主进程无感知
- 若类内部用了
threading.Lock等不可跨进程对象，fork后可能死锁（尤其在macOS/Windows spawn模式下）
用Manager注册自定义类型是可行路径
multiprocessing.Manager允许你注册新类型，让其代理对象支持跨进程访问。核心是把类的“状态”抽离为可序列化的数据结构（如dict），再用Manager托管该结构，最后封装一层接口模拟原类行为。
示例关键步骤：
立即学习“Python免费学习笔记（深入）”；
- 定义一个纯数据类（只含
int/str/list/dict等基础类型）作为状态容器 - 用
Manager().dict()或Manager().list()托管该容器 - 写一个包装类，所有属性读写都代理到托管容器上
- 调用
BaseManager.register()注册该包装类，返回可跨进程构造的代理类
注意：注册必须在if __name__ == '__main__':块内完成，且要在任何子进程启动前执行。
Value/Array + ctypes更适合轻量状态共享
如果你的自定义类实际只封装几个数值型字段（比如class Counter: def __init__(self): self.count = 0; self.max_val = 100），直接用Value和Array更高效、更可靠。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
例如：
from multiprocessing import Process, Value, Array
import ctypes
<h1>把两个int字段映射到共享内存</h1><p>count = Value('i', 0)
max_val = Value('i', 100)</p><p>def worker(count, max_val):
count.value += 1
if count.value > max_val.value:
max_val.value = count.value * 2
优势：Value和Array走底层共享内存，不经过Manager进程代理，延迟低、吞吐高；缺点是只能表达固定结构的简单类型，不支持嵌套或动态字段。
SharedMemory + 自定义序列化是高性能但高风险方案
从Python 3.8起，multiprocessing.shared_memory.SharedMemory提供裸内存块，你可以用struct或numpy手动布局对象二进制结构。这对高频更新的自定义类（如实时传感器状态）有明显性能优势。
但必须自己处理：
- 内存布局对齐（
struct.pack格式字符串要精确匹配） - 并发读写时的锁同步（
Lock必须也放在共享内存里或单独管理） - 生命周期管理：谁创建谁销毁，否则
shm.unlink()漏掉会导致内存泄漏 - 跨平台兼容性：Windows对
SharedMemory名长度和权限更敏感
这不是“共享对象”，而是“共享字节块+约定协议”。一旦序列化逻辑出错，读到的就是乱码或崩溃。
真正难的从来不是“怎么让对象出现在另一个进程里”，而是“怎么让多个进程对同一份状态达成一致的理解和修改顺序”。Manager注册、Value封装、SharedMemory手写——选哪个，取决于你愿不愿意为一致性多写几行同步代码，以及能不能接受那几毫秒的IPC延迟。
