Ray需显式用@ray.remote标注函数，返回ObjectRef须调用ray.get()获取结果；类方法需装饰整个类，Actor适用于有状态场景，本地调试应启用local_mode=True。
Ray 能真正把 Python 函数变成可远程调度的并行任务，但前提是必须显式标注 @ray.remote，且不能直接调用普通函数——这是绝大多数初学者卡住的第一步。
为什么 ray.get() 一直阻塞或返回 ObjectRef 而不是结果？
根本原因是：你调用了 @ray.remote 函数后没用 ray.get() 获取返回值，或者误把 ObjectRef 当成结果直接用了。
-
@ray.remote函数返回的是ObjectRef（类似“计算凭证”），不是实际值；必须传给ray.get()才能取回结果 - 如果多个任务并发提交，
ray.get()接收列表，会按顺序等待全部完成，不加timeout可能无限挂起 - 若函数内部抛异常，
ray.get()会重新抛出原始 traceback，但只在调用时才暴露——容易误判为“没报错却没结果”
示例：
@ray.remote
def heavy_task(x):
return x ** 2
<h1>❌ 错误：ref 是 ObjectRef，打印出来像 ObjectRef(01000000...)</h1><p>ref = heavy_task.remote(5)
print(ref) # 不是 25</p><h1>✅ 正确：显式 ray.get()</h1><p>result = ray.get(ref) # 这里才真正执行并取回 25
print(result)
</p>
如何让 Ray 正确序列化带类方法、闭包或全局状态的函数？
Ray 默认只支持顶层函数和简单数据结构；类实例方法、lambda、引用模块级变量等都会触发 CloudPickleError 或静默失败。
- 类方法需用
@ray.remote修饰整个类（ray.remote(MyClass)），再用.remote()实例化，不能直接装饰单个方法 - 避免在远程函数中读写全局变量（如
CONFIG）——每个 worker 有独立进程空间，改了也没用 - 闭包捕获的变量必须可 pickle；推荐把依赖显式作为参数传入，而不是靠外层作用域
- 第三方库（如 PyTorch 模型）需确保在 remote 函数内加载，或使用
ray.put()预存大对象并传 ref
Ray Actor 和 ray.remote 函数该选哪个？
核心区别在于状态是否需要跨任务共享：Actor 是有状态的长期存活对象，函数是无状态的一次性执行单元。
- 用
@ray.remote函数：适合 map-reduce 类任务，比如批量处理独立数据项（[f.remote(x) for x in data]） - 用 Actor：适合需要维护中间状态的场景，比如在线学习模型、连接池、计数器；注意 Actor 方法调用默认串行，加
concurrency_groups才能并发 - Actor 启动慢、内存开销大，别为了“看起来高级”而滥用；一个 Actor 实例无法被多个 driver 进程共享
常见误用：actor.method.remote() 返回 ObjectRef，仍需 ray.get()；但 actor 创建本身也返回 ref，别漏掉第一次 ray.get()。
本地调试时 ray.init() 报错或性能反而更差？
Ray 默认启动完整集群模式，本地开发应强制轻量模式，否则资源争抢严重甚至启动失败。
- 始终加
ray.init(local_mode=True)用于单进程调试（跳过序列化/网络/调度开销，纯逻辑验证） - 正式运行时用
ray.init(num_cpus=4)显式限制资源，避免抢占系统全部 CPU 导致本机卡死 - Windows 下需确保 Python 脚本入口有
if __name__ == "__main__":，否则子进程反复导入引发无限 fork - 日志太吵？设
logging_level=logging.ERROR；想看调度行为？开dashboard_host="127.0.0.1"并访问http://127.0.0.1:8265
最常被忽略的一点：Ray 的“分布式”不是魔法开关，它把任务分发出去的前提是——所有依赖代码和数据都得能被 worker 进程反序列化并重建。路径硬编码、动态生成函数、C 扩展模块未预装……这些细节崩掉时，错误信息往往藏在 worker 日志里，而不是主进程抛出的异常中。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
