在本站中

本站是开源的 dioxus 全栈应用（yuxuetr/rustineverything），跑在 tokio 的多线程运行时上，没有用 embassy，也没有嵌入式的部分。和 embassy 最接近的是两个后台定时循环：tokio::spawn 加 tokio::time::interval，一个刷新搜索索引，一个做支付对账。这一部分把它们的结构搬到 embassy 的 std 执行器上，工作换成可控的桩，和 tokio 版本并排跑。实验只读本站代码，在本地跑。

1. 本站的定时循环搬到 embassy：骨架十来行就能搬，但 Ticker 的第一个 tick 在一个周期之后，和 interval 相反；一轮拖过周期时 Ticker 和默认的 Burst 一样连补，Delay / Skip 要用 reset* 自己写；工作阻塞线程时 tokio 多线程只少一个 worker，一个 embassy 执行器整个停下 350 ms；tokio 每次 spawn 一次 256 字节的堆分配，embassy 不分配，pool_size 满了返回 Busy；HTTP、数据库、网关查单都离不开 tokio 的 I/O 驱动。结论是本站继续用 tokio，embassy 的边界是没有操作系统的设备。

flowchart TB
  loops["两个后台循环"] --> skel["骨架 Ticker"]
  loops --> body["循环体 I/O"]
  skel --> ok["能搬"]
  body --> no["离不开 tokio"]
  ok --> cmp["并排比较"]
  cmp --> keep["继续用 tokio"]
  no --> keep

tokio 一侧这两个循环本身（spawn 落在哪个队列、第一次 tick、默认 Burst）见 tokio 卷的在本站中；Ticker 的源码和补 tick 的机制见Timer、Ticker 与超时，interval 的三种补法见 tokio 卷的 Sleep 的一生。本部分的数字都是 macOS（M2 Max）上测的。