翻译是在服务端执行的，所以扩展规模这件事，主要交给引擎，而不是你来操心。lingo push负责提交任务，引擎负责处理——你不需要配置 worker 池或并发参数。你真正要控制的，是一次推送多少内容，以及出现问题时如何恢复。
只推送变更内容#
默认情况下，lingo push会基于lockfile对每条源文案计算哈希，只提交发生变化的内容。对于大型仓库来说，这是成本最低的路径——如果语料没有变化，就不会有任何操作，也不会产生与服务端的往返请求。让增量去完成这部分工作；避免直接对所有内容一把推--force。
为大范围变更划定范围#
确实需要重新翻译时，请把范围限定在某个子树，而不是整个项目：
bash
lingo push 'content/en/marketing/**/*.md' --force这样能让大规模运行始终有边界、可预期。参见重新翻译。
大规模运行前先估算#
正式提交前，先为一次大规模运行估个价：
bash
lingo push --backfill-missing --estimate会输出预估成本并直接退出。在首次全量翻译，或需要跨多种语言环境切换模型之前，这一点尤其有用。
别被运行过程卡住#
面对大规模运行，你不用一直守着命令。push会把这次运行记录到run state中，因此你可以稍后再收集结果，或者直接在 CI 中获取：
bash
# kick it off
lingo push --backfill-missing
# later, or in CI
lingo pull恢复，而不是重来#
如果一次大规模运行中途失败，不要把全部内容重新推送一遍——lingo resume会重新输出缓存结果，无需再次花费，然后由--backfill-missing补齐剩余缺口。
把它自动化#
如果你希望大型项目始终保持最新，可以让 CI 在合并时自动执行翻译，并基于结果创建 PR。参见CI/CD。
你是从旧版 CLI 迁移过来的吗？
旧版 CLI 因为是在本地机器上执行翻译，所以提供了客户端并发控制（worker 池、并行标志等）。现在的 CLI 在服务端完成翻译，因此这些调节项已经不存在了——规模扩展由系统替你处理。现在真正需要掌握的杠杆，是范围限定、回填和恢复。
