核心用法
food-order 是一款命令行驱动的 Foodora 订餐自动化工具，通过 ordercli 实现三大核心能力：历史订单复购、订单状态追踪、以及多账户配置管理。
复购流程：用户先通过 ordercli foodora history 查看近期订单，使用 reorder <orderCode> 进行预览（仅展示购物车内容，不扣款），经用户明确口头确认（"yes"/"confirm"/"place the order"）后，方可追加 --confirm 参数完成下单。多地址场景需用户指定 --address-id。
实时追踪：ordercli foodora orders --watch 提供持续刷新的 ETA 与配送状态，适合等待外卖时的监控需求。
登录方案：支持密码直输（--password-stdin）或推荐更安全的浏览器 Cookie 复用（--url + --profile），后者避免凭证硬编码。
显著优点
- 操作原子化：预览与确认分离，降低误操作风险
- 无头自动化：适合定时脚本或快捷指令集成
- 多国家/多账户：通过
--config切换配置，支持跨国使用
潜在缺点与局限性
- CLI 门槛：需 Go 环境及命令行基础，非技术用户友好度低
- 地区锁定：依赖 Foodora 覆盖范围（欧洲、亚太部分城市），北美用户无法使用
- 确认语义依赖：规则要求用户说出特定确认词，识别容错性未明
- 支付隐蔽性：最终扣款发生在 Foodora 服务端，CLI 仅提交请求，失败场景（余额不足、餐厅歇业）需二次排查
适合人群
- 高频复购固定餐品的技术用户
- 需批量管理多个 Foodora 账户的运维场景
- 追求「语音/快捷指令→自动下单」效率的进阶玩家
常规风险
- 资金安全：确认词误触发或语义识别错误可能导致非预期下单；建议搭配
--config /tmp/...沙盒测试 - 隐私泄露：浏览器 Cookie 复用方案若配置不当，可能暴露会话凭证
- 服务依赖：Foodora API 变更可能导致 CLI 失效，维护者为个人开发者（
steipete），长期支持存疑 - 地址误选：多地址场景若用户误判
--address-id，餐品可能送至错误地点且无法撤回