actorsystem 启动失败主因是 tcp 端口冲突（如协调器默认端口 1900 被占）或 ipv6 解析问题，解决方法包括杀残留进程、显式指定 adminport/hostaddr、禁用 ipv6 或改用 simplesystembase。
thespian 的 ActorSystem 启动失败常见原因
启动 ActorSystem 时卡住或抛出 TimeoutError，大概率是底层 TCP 绑定冲突或跨进程通信配置没对齐。thespian 默认用 "multiprocTCPBase"，会尝试绑定随机端口、并启动本地协调器（coordinator），如果已有其他 Python 进程占着协调器端口（默认 1900），它就等超时。
- 先确认没残留的
thespian进程：ps aux | grep "thespian"，必要时killall -9 python（仅开发机） - 显式指定协调器地址，避免端口争抢：
ActorSystem("multiprocTCPBase", {"AdminPort": 1901, "HostAddr": "127.0.0.1"}) - Windows 上禁用 IPv6 可能更稳——在配置里加
"IPv6": False，否则getaddrinfo可能返回 v6 地址导致连接失败 - 测试阶段建议换
"simpleSystemBase"：纯线程内调度，无网络开销，适合验证 actor 行为逻辑
pykka 的 ActorRef 调用阻塞 vs 非阻塞选择
ActorRef.ask() 和 ActorRef.tell() 看似只是“要结果”和“不等结果”的区别，但实际影响整个调用链的错误传播方式。pykka 默认所有方法调用都走 ask()（即发消息 + 等回复），如果你在 actor 内部又调用了另一个 actor 的 ask()，就容易形成嵌套等待，一旦下游 actor 挂了，上游会卡死在 Future.get(timeout=...) 上。
- 只在真正需要返回值时用
ask()；状态更新、日志记录、事件通知一律用tell() -
ask()必须设timeout，比如ref.ask({'cmd': 'fetch'}, timeout=2)，否则默认无限等待 - 别在
on_receive()里直接调ask()并同步处理结果——这会让 actor 线程阻塞，吞掉并发能力；改用Future.then()做链式回调 - 注意
ActorRef是线程安全的，但Future不是：不能把同一个Future对象传给多个线程调用get()
消息序列化兼容性：thespian 的 pickle vs pykka 的 JSON 限制
thespian 默认用 pickle 序列化消息，pykka 默认用 json。这意味着：传递自定义类实例时，thespian 只要类定义在收发两端一致就能跑通；pykka 则要求消息必须是 dict/list/str/int/float/bool/None 的组合，否则直接抛 TypeError: Object of type X is not JSON serializable。
- pykka 下想传复杂对象，得提前转成字典：
obj.__dict__或实现to_dict()方法，别依赖vars()（可能含不可序列化属性） - thespian 在跨语言或跨版本部署时有风险：Python 3.8 pickle 的对象在 3.11 可能反序列化失败；生产环境建议配
"pickleProtocol": 4并锁定运行时版本 - 两者都不支持传递函数、lambda、文件句柄、数据库连接等运行时资源——这不是 bug，是 actor 模型的设计约束
- 如果要用 msgpack 或 protobuf，thespian 允许替换序列化器（需重写
ActorSystemBase），pykka 则基本只能换框架
Actor 生命周期管理：stop() 调用时机与资源泄漏点
thespian 的 actorAddress 一旦创建就长期有效，stop() 只是发终止消息，actor 真正退出取决于它是否还在处理消息；pykka 的 ActorRef.stop() 更激进，会强制中断线程并清理资源，但前提是 actor 没卡在阻塞 IO（如 time.sleep()、requests.get()）里。
立即学习“Python免费学习笔记（深入）”；
- thespian 中，务必在
receiveMessage末尾检查self._shutdown_flag（需手动维护），或监听ActorExitRequest消息来主动清理 - pykka 下，在
on_start()里开的 socket、线程、数据库连接，必须在on_stop()或on_failure()里 close，否则stop()后资源还在 - 别在 actor 外部反复
create_actor()+stop()——thespian 的 actor 创建成本高（新进程），pykka 的线程创建也有开销；应复用 actor 实例 - 调试时加日志：thespian 用
self.send(self.myAddress, 'ping')测试存活；pykka 用ref.is_alive()，但要注意它只反映线程状态，不保证业务逻辑可用
actor 模型不是银弹，选 thespian 还是 pykka，关键看你要不要跨机器扩展、能不能接受 pickle、以及有没有现成的 JSON 化消息规范。多数单机场景下，pykka 的轻量和明确边界更省心；真要分布式且控制力强，thespian 的可配置性才有意义。两者都绕不开“消息不可变”和“状态隔离”这两条铁律，踩坑基本都是从这里开始的。
