Proto.Actor 是 Go 的第三方 Actor 框架，需手动安装新版本 github.com/ProtoBuf-Kit/protoactor-go@v1.4.0；必须全局唯一 actor.NewActorSystem() 初始化；交互须通过 PID 的 Tell()/Request() 异步进行；消息 struct 字段须导出；避免 stateful actor 内存泄漏；Local/Remote 错误难以区分，需结合日志与端口验证。
Proto.Actor 在 Go 里不是标准库，得手动装
Go 没有内置 Actor 模型支持，protoactor-go 是第三方实现，和 Erlang 的 OTP 风格接近但简化了。它不依赖 gRPC 或 Protocol Buffers 运行时（哪怕名字带 proto），只是用了 protobuf 的序列化能力做消息编码——你不用写 .proto 文件也能用纯 Go struct 当消息。
常见错误是直接 go get github.com/AsynkronIT/protoactor-go 就跑，结果发现版本混乱、接口不兼容。官方已把主仓库迁到 github.com/ProtoBuf-Kit/protoactor-go（2023 年后维护分支），旧版 AsynkronIT 域名下代码已归档。
- 装新版本：运行
go get github.com/ProtoBuf-Kit/protoactor-go@v1.4.0（注意指定 tag，别用@latest） - 初始化 actor 系统必须调一次
actor.NewActorSystem()，全局只应有一个实例，别在每个 handler 里重复创建 - 如果你用
go mod tidy后提示找不到protoactor-go/actor，大概率是模块路径没对上，检查go.sum里是否混进了旧域名的 hash
Actor 启动后不能直接调方法，得发消息
新手常把 actor 当成普通对象，写 myActor.Receive(...) 或 myActor.Ping()，这会 panic：actor 行为只能通过邮箱（mailbox）异步触发。所有交互必须走 pid.Tell() 或 pid.Request()，PID（Process ID）才是访问 actor 的唯一合法句柄。
典型场景：HTTP handler 中触发后台任务，不能 new 一个 actor 实例然后调它的函数，而要先 system.Root.Spawn(...) 得到 PID，再 pid.Tell() 发结构体消息。
立即学习“go语言免费学习笔记（深入）”；
-
Tell()是“发完就忘”，无返回，适合日志、通知类操作 -
Request()带context.Context和超时控制，返回Future，需显式future.Result()获取响应；若 actor 挂了，future.Result()会返回ErrRemoteActorNotFound - 消息 struct 字段必须导出（首字母大写），否则序列化为空对象——这是最常被忽略的坑
Stateful actor 容易内存泄漏，别存大对象或闭包
Actor 实例默认长期存活，Receive() 方法里定义的局部变量不会自动释放，尤其当你在 handler 中缓存 map、slice 或注册回调函数时，引用链可能意外延长生命周期。
比如用 actor 维护用户连接状态，把 *http.ResponseWriter 存进 struct 字段，会导致整个 HTTP response 缓冲区锁住，GC 清不掉。
- 避免在 actor struct 里存任何非 POD 类型（如
*sql.DB、http.Client、大 slice） - 需要共享资源（如 DB 连接池）应作为依赖注入到
Props，而非存在 actor 实例字段中 - 用
actor.WithMailboxSize(1024)显式限制邮箱长度，防止突发消息积压撑爆内存
Local vs Remote actor 的错误信息长得一模一样
当 pid.Request() 失败时，无论目标 actor 是崩溃了、网络不通、还是根本没启动，错误都可能是 "failed to deliver message: context deadline exceeded"。单靠日志无法区分是本地调度失败还是远程调用超时。
真实调试场景：你在本地启了一个 actor，另一个服务通过 remote.NewRemote() 连它，但忘记调 remote.Start()，或者防火墙拦了端口，错误表现和 actor 内部 panic 完全一致。
- 加日志前先确认：
remote.Start()是否在actor.NewActorSystem()之后调用 - 用
netstat -an | grep :8080（假设 remote 监听 8080）验证端口是否真在 LISTEN - 测试阶段优先用
actor.SpawnNamed()启 local actor，确认逻辑正确后再切 remote
Actor 模型真正难的不是怎么写接收逻辑，而是怎么让消息流可观察、可中断、可回溯。PID 不是地址，是契约；超时不是配置项，是边界声明。这些细节不写进日志，就永远藏在 future.Result() 的 nil 里。
