进程间共享变量总是错的，因为multiprocessing启动的是内存隔离的独立进程，全局变量或普通对象在各进程中只是独立副本；必须用Value、Array或Manager等显式同步工具。
进程间共享变量为什么总是错的
Python 的 multiprocessing 模块里，直接在多个进程里读写同一个全局变量或普通对象（比如 list、dict），结果几乎必然出错——不是数据丢失，就是值突变，甚至程序卡死。这不是你代码写得不熟，而是底层根本没同步机制。
原因很简单：multiprocessing 启动的是独立进程，内存完全隔离；你看到的“同一个变量”，其实是每个进程里各自拷贝的一份副本。改了 A 进程里的 counter，B 进程里的 counter 一无所知。
- 别用
global变量跨进程传状态 - 别把可变对象（如
list）直接传给Process的args参数指望它能被修改后回传 - 如果真要共享，必须显式选对工具：用
multiprocessing.Value或multiprocessing.Array存基础类型，用multiprocessing.Manager()包装高级结构
Manager() 和 Value() 到底该选哪个
Manager() 灵活但慢，Value() 快但只能存单个数字或字符。选错会拖慢性能，甚至引入隐性竞争。
比如你要统计 10 个子进程一共处理了多少条日志：
– 用 Manager().Value('i', 0) 是对的，轻量且原子；
– 但如果改成 Manager().dict() 存一个计数器再加锁更新，就多了一层网络序列化开销，纯属自找麻烦。
立即学习“Python免费学习笔记（深入）”；
-
Value/Array：只支持 C 类型（'i'、'd'、'c'），读写是原子的，无需额外加锁 -
Manager().list()/.dict()：支持任意 Python 对象，但所有操作都走代理进程通信，延迟高，且append、__setitem__这些不是原子的，仍需手动加Lock - 别混用：比如用
Manager().dict()存了个list，再在子进程里对这个list调用sort()—— 会报AttributeError，因为 Manager 返回的是代理对象，不支持原生方法
Lock 不加在关键路径上等于没加
很多人加了 Lock，但还是出现竞态，问题常出在加锁范围太小或太随意。比如只锁了写入，却忘了读取也需要一致视图；或者把锁对象本身传错了进程，导致各锁各的。
典型错误：lock = Lock() 写在主进程里，然后通过 args=(shared_dict, lock) 传进子进程 —— 这不行。Lock 不能跨进程传递，必须在每个需要它的子进程中重新创建，或由 Manager() 提供（manager.Lock()）。
- 所有对共享资源的**读+写组合操作**都要包在
with lock:里，比如“先查再改”这种逻辑 - 不要在锁里做耗时操作（如 HTTP 请求、文件读写），否则整个进程池会被堵住
- 用
manager.Lock()而不是multiprocessing.Lock()，后者无法跨进程生效
Windows 下 spawn 启动方式带来的坑
Windows 默认用 spawn 方式启动子进程（macOS/Linux 默认是 fork），这意味着子进程不会继承父进程的内存状态，所有模块重载、全局变量初始化、甚至 logging 配置都得重新走一遍。很多“本地跑得好，上线就崩”的问题根源在这。
比如你在主脚本顶部写了 logging.basicConfig(level=logging.INFO)，子进程里调用 logging.info() 却没输出 —— 因为 spawn 下子进程没执行那行配置。
- 所有子进程依赖的代码（函数定义、配置初始化、第三方库 setup）必须能被单独 import 执行，不能依赖主模块的执行上下文
- 避免在 if
__name__ == '__main__'外写带副作用的语句；把共享逻辑抽成独立函数，确保可被多次导入 - 调试时加一句
print(f'PID: {os.getpid()}, __name__: {__name__}')，能快速判断是不是 spawn 导致的模块重复加载
最麻烦的不是锁怎么写，而是你以为锁住了，其实连共享资源都没真正连上——尤其是跨平台部署时，spawn 和 Manager 的初始化时机稍有偏差，数据就静默丢失了。
