合成队列
一个玩家在一个工作站拥有一条队列。队列是串行单线的：只有队首在推进，后面的条目排队等待。
条目状态
| 状态 | 是否占用队列长度 | 说明 |
|---|---|---|
WAITING | 是 | 已提交，排在队列中等待。 |
RUNNING | 是 | 队首，正在推进耗时。 |
PENDING_CLAIM | 否 | 已完成但产物没能投递，等待玩家领取。 |
PENDING_CLAIM 刻意不占用队列长度：否则仓库和背包同时满的玩家会被自己未投递的产物锁死队列，什么都排不进去。待领取条目由 limits.max_pending_claim 单独限制，默认 100。
队列长度的三个来源
| 来源 | 与基础长度的关系 | 配置位置 |
|---|---|---|
| 基础长度 | 起点 | config.yml 的 queue.base_length，工作站可覆盖。 |
| 权限档 | 取代 | emakistation.queue.<n>，需 queue.permission_tiers: true。 |
| 付费购买 | 叠加 | 队列页购买，见 付费队列位。 |
权限档取数字最大的一档生效，没有任何该前缀权限时保持基础长度。付费额度叠加在生效档之上，最终统一被 queue.max_length 截断。
权限档是「取代」而付费是「叠加」，这样管理员事后给某个玩家发权限档，不会把他花钱买的额度吞掉。
推进方式
queue.progress_mode 决定队首如何计时：
| 值 | 行为 |
|---|---|
offline | 按真实时间推进，玩家离线期间继续走时。 |
online | 仅在玩家在线时累计。 |
offline 只表示「计时继续」，不表示「离线发货」。EmakiStorage 拒绝对离线玩家做任何写操作，所以离线期间到点的条目只是「已到期」，真正结算发生在玩家下次上线时。
队列推进任务全服只有一个定时器，间隔由 queue.tick_interval 控制，默认 20 tick，不是每条队列一个定时器。
耗时
单次耗时来自配方的 duration_seconds，再乘工作站或全局的 speed_multiplier。duration_seconds 为 0 或省略时立即完成，不进队列。
取消与退还
/emakistation cancel <工作站> <序号>命令与界面里的序号从 1 开始（API 的 index 参数从 0 开始）。
退还比例来自工作站的 queue.cancel_refund_rate，材料与已付货币按同一比例折算。退还总是回到材料原本来自的通道，与工作站的产物路由无关。
退还不按进度折算。串行单线队列里只有队首有进度，为一个几乎不存在的情况引入逐条目进度记账不值得，这是有意的简化。
部分退还仍然报告成功，缺口作为 Partial 原因键携带。
PENDING_CLAIM 状态的条目不能取消，会被拒绝并返回 station.cancel_pending_claim。
领取产物
/emakistation claim一次领取该玩家在所有工作站的全部可投递待领取产物。仍然投递不了的条目保持待领取而不是让整个调用失败，所以这个命令可以无条件执行。
管理员操作
/emakistation admin queue <...>需要 emakistation.admin。