Proto.Actor 的 Go 实现是基于 goroutine 和 channel 的轻量级消息驱动并发模型，要求 Actor 类型实现 actor.Receiver 接口（含 Receive(ctx actor.Context) 方法），强调显式类型断言、避免阻塞、命名 PID 便于调试，并推荐统一使用 proto.Message 保障序列化与类型安全。
Proto.Actor 的 Go 实现本质是消息驱动的轻量级并发模型
Proto.Actor 不是传统意义上的“Actor 系统实现”，而是对 Actor 模式在 Go 中的务实封装：它不模拟 Erlang 风格的进程调度，而是用 goroutine + channel 做消息收发，靠 ActorSystem 统一管理生命周期和错误传播。你写一个 Actor 类型，只要实现 Receive 方法，就能被 Proto.Actor 启动、发消息、重启——但别指望它自动帮你做位置透明或跨节点迁移。
定义 Actor 类型必须满足 actor.Receiver 接口
Go 里没有继承，Proto.Actor 用接口约束行为。你的结构体要能接收消息，就得实现 Receive 方法，签名固定为 func(ctx actor.Context)。常见错误是漏传 ctx、或者把 ctx.Message() 类型断言写错，导致 panic：
-
ctx.Message()返回interface{}，必须显式断言，比如v, ok := ctx.Message().(*MyCommand) - 不要在
Receive里直接启动 goroutine 处理耗时逻辑——这会让消息处理失去顺序性；该用ctx.SendSelf()或ctx.Respond()转成异步消息 - 如果想让 Actor 初始化时加载状态，得在
actor.WithProps构建时传入初始化函数，而不是在结构体字段里直接 new
actor.Spawn 和 actor.SpawnNamed 的区别直接影响调试体验
没名字的 Actor（actor.Spawn）在日志、监控、调试时几乎无法定位；而 actor.SpawnNamed 生成的 PID 带可读路径（如 /user/myworker），配合 actor.WithMailbox 或自定义 actor.Logger 才能看清谁在收什么消息。容易踩的坑：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 重复用相同名字
SpawnNamed会覆盖前一个 Actor，且不报错——旧 Actor 的 goroutine 可能还在跑，造成资源泄漏 - 名字路径不能含空格或特殊字符，否则
PID.String()输出异常，下游工具（如 Prometheus metrics）解析失败 - 测试时建议统一用
actor.NewLocalActorSystem()，避免默认系统残留状态影响并行测试
消息不是任意 struct，需注意序列化与类型安全边界
Proto.Actor 默认不强制序列化，但一旦开启远程或集群功能（actor.WithRemote），所有消息必须是 protobuf 定义的 proto.Message 类型，否则 runtime panic 报 "message is not proto.Message"。本地开发常忽略这点，直到加了 remote 才暴露问题：
立即学习“go语言免费学习笔记（深入）”；
- 本地单机模式下，用普通 struct 发消息没问题，但别依赖它——代码风格应保持一致，推荐始终用
proto.Message - 同一个消息类型，如果在不同包里重复定义（哪怕字段完全一样），Go 视为不同类型，
ctx.Message()断言失败 - 避免在消息里嵌套指针或闭包——序列化会丢数据，且 Go 的
gob或 protobuf 都不支持
Actor 模型的复杂点不在启动，而在消息边界的控制：什么时候该响应、什么时候该转发、什么时候该拒绝、以及拒绝后要不要通知发送方——这些逻辑全压在 Receive 里，没标准答案，只能靠消息协议设计和上下文判断。
