连不上是网络或配置问题，非SDK故障；需确认Server运行、显式指定地址（如WSL2用主机IP）、检查防火墙；workflow卡住多因activity未注册或异常；禁用time.sleep()，改用workflow.sleep()；worker崩溃不丢状态，但需多实例与幂等设计。
temporalio SDK 连不上本地 Temporal Server 怎么办
连不上基本是网络或配置错位，不是 SDK 本身问题。Temporal Python SDK 默认走 localhost:7233，但很多用户跑在 Docker 或 WSL 里，localhost 指向的不是 Server 所在网络栈。
- 确认 Server 确实在运行：
docker ps看有没有temporalio/auto-setup容器，端口映射是否含7233->7233 - Python 代码里显式指定地址，别依赖默认：
client = await Client.connect("127.0.0.1:7233")（Docker for Mac/Windows 可用；WSL2 则要用 Windows 主机 IP，比如192.168.42.1:7233） - 防火墙或 antivirus 有时会拦截 7233，临时关掉试试；Mac 上还可能被
pfctl规则阻断
workflow.execute() 卡住不返回，也没报错
这是最常被误判为“SDK hang”的场景——实际是 workflow 逻辑里调用了没注册的 activity，或 activity 函数抛了未捕获异常，导致 worker 无法完成任务。
- 检查 worker 是否已启动且监听了对应 task queue：
worker = Worker(client, task_queue="your-queue", workflows=[YourWorkflow], activities=[your_activity]) - activity 函数必须是顶层函数或类方法，不能是闭包或 lambda；且参数类型需能被
dataclasses或pydantic.BaseModel序列化 - 加日志：在 activity 开头打
print("activity start")，如果没输出，说明根本没调度到 worker；如果输出了但没返回，大概率是 activity 内部阻塞（比如同步 HTTP 请求、死循环）
为什么 workflow 中不能用 time.sleep()，该用什么替代
time.sleep() 是线程阻塞，会卡住整个 workflow 线程，违反 Temporal 的“确定性重放”机制——重放时 sleep 时间不准，会导致 checksum 不一致，任务失败。
- 必须用
await asyncio.sleep(5)（异步等待），或更推荐await workflow.sleep(5)——后者由 SDK 控制，支持精确重放和跳过（测试时可加速） - 自定义定时逻辑（如“30 秒后发通知”）不要自己 while + sleep，改用
workflow.wait_condition()或 schedule + timer，让 server 管理超时 - 已有同步库（如 requests）要换成异步版（
aiohttp），否则必须包在workflow.run_sync()里，但会损失可观测性和重放能力
production 环境下 worker 崩溃后 workflow 状态丢失吗
不会。Workflow 状态全存在 Temporal Server 的数据库里，worker 只是执行单元。worker 进程挂了，server 会在几秒内把 pending tasks 重新 dispatch 给其他存活 worker。
立即学习“Python免费学习笔记（深入）”；
- 关键是要避免“单点 worker”：多个 worker 实例必须用相同
task_queue，且确保它们能并发处理同一类 activity（activity 函数得是幂等的） - worker 启动时建议加 health check 和 graceful shutdown：收到 SIGTERM 后调用
worker.stop()，等正在执行的 activity 完成再退出 - 监控重点不是 worker 进程存活，而是
task_queue_pending_task_count指标突增——说明 worker 处理不过来，或 activity 执行太慢
真正难调试的是 workflow 自身的非确定性：比如用了 random.random()、datetime.now()、或读了外部文件。这些在重放时值不同，会导致历史事件校验失败，Server 直接终止 workflow。这类问题不会报错，只会静默失败，得靠 workflow execution history 查 “DeterminismViolation” 事件。
