ActorSystem启动异步且不阻塞主线程，程序退出导致Actor无响应；须用Console.ReadLine()等保持存活，Props需正确传参，禁用Ask滥用，状态须通过消息而非共享内存维护。
为什么直接用 ActorSystem 创建 Actor 会失败
新手常在 Main 方法里写 ActorSystem.Create("mySys").ActorOf<code> 就报错，根本原因是 <code>ActorSystem 启动是异步的，且默认不阻塞主线程——程序执行完就退出，Actor 根本没机会响应消息。必须显式保持系统存活，否则看到的只是“没报错但什么都没发生”。
- 正确做法：用
Console.ReadLine()或Task.Delay(-1)持有主线程（开发调试用） - 生产环境应配合
IHost或BackgroundService管理生命周期 - 别在
static void Main里直接调用await，C# 7.1+ 才支持async Main，否则需用.GetAwaiter().GetResult()
Props 和 ActorOf 的参数陷阱
创建 Actor 时传错参数类型是最常见的崩溃点：ActorOf<tactor>()</tactor> 要求 TActor 是具体类，且必须有无参构造函数；若 Actor 需要依赖注入（如 ILogger），不能直接 new，得用 Props.Create(() => new MyActor(logger))。
-
Props.Create<myactor>()</myactor>→ 仅适用于无依赖的 Actor -
Props.Create(() => new MyActor(dep))→ 依赖需在创建时已就绪，不能传this或未初始化对象 - 避免在
Props.Create的 lambda 里做耗时操作（如 DB 连接），Actor 初始化应轻量 - 传入的参数会被捕获闭包，注意引用生命周期 —— 若
dep是短期作用域对象，Actor 运行时可能访问已释放资源
发消息用 Tell，取结果别用 Ask 盲等
Ask 看似方便，但本质是封装了超时 + TaskCompletionSource，容易引发线程阻塞、超时异常或内存泄漏。它只适合明确需要返回值的短时交互（如查缓存），绝不能用于 Actor 内部互相 Ask，否则极易死锁。
- 90% 场景用
actorRef.Tell(message)—— 火焰传递，无返回，符合 Actor 原则 - 必须用
Ask时，务必设合理超时：await actorRef.Ask<response>(new Request(), TimeSpan.FromSeconds(3))</response> -
Ask返回的Task可能因 Actor 崩溃、超时、消息丢失而失败，必须try/catch或用.ContinueWith处理异常状态 - 不要在
Receive方法里对同个 Actor 频繁Ask，改用Forward或事件驱动通知
Actor 内部状态为何不能直接共享
很多人试图在 Actor 类里定义 static List<int> 或给字段加 lock，这是反模式。Actor 的核心约束是：所有状态变更必须串行化在单个收件箱内处理，靠 Receive 方法顺序执行保证线程安全 —— 不是靠锁，也不是靠 static。
- Actor 实例本身是单线程上下文，其字段天然线程安全，无需
lock或ConcurrentQueue -
static字段跨 Actor 实例共享，破坏隔离性，会导致不可预测的竞态 - 若需共享状态，应提取为另一个 Actor，通过消息通信，而非共用内存
- Actor 重启（如失败后监督策略触发）会丢失字段值，持久化状态要用
EventSourcing或Persistence扩展
Akka.NET 的复杂点不在语法，而在思维切换：你不再控制线程，而是设计消息流与失败恢复路径。最容易被忽略的是 Actor 生命周期与宿主进程的绑定方式，以及把“同步等待响应”惯性带进异步消息模型里。
