Scale Game 是一种以极端尺度检验方案的思维方式，核心原则是：极端条件会暴露在正常规模下被隐藏的根本真理。
用途 它用于在早期验证架构或方案是否具备根本性的健壮性，帮助识别系统真正的极限所在，避免仅凭“开发环境能跑”就推断生产环境可行。
主要能力 方法围绕若干可极端变化的维度展开测试，每个维度对应不同的揭示内容：
- 数据量：1 条 vs 10 亿条，揭示算法复杂度上限。
- 速度：即时 vs 一年，揭示异步需求与缓存需求。
- 用户数：1 个用户 vs 10 亿用户，揭示并发问题与资源限制。
- 持续时间：毫秒 vs 数年，揭示内存泄漏与状态增长。
- 失败率：从不失败 vs 始终失败，揭示错误处理是否充分。
使用方式 执行过程分为五步：
- 选定维度：找出哪些因素可能发生极端变化。
- 测试最小值：如果它缩小、变快或变少 1000 倍会怎样？
- 测试最大值：如果它放大、变慢或变多 1000 倍会怎样？
- 记录何处崩溃：极限在哪里出现？
- 记录何处存活：哪些部分在根本上依然稳固？
文档给出的示例：
- 错误处理：正常规模下“出错时处理”可用；到 10 亿规模，错误量会淹没日志并导致系统崩溃，揭示需要让错误不可能发生（类型系统）或预期其发生（混沌工程）。
- 同步 API：正常规模下直接函数调用可用；全球规模下网络延迟使同步调用不可用，揭示异步与消息传递从优化项变为生存必需。
- 内存状态：正常时长下可运行数小时或数天；到数年时长内存无界增长并最终崩溃，揭示需要持久化或定期清理，不能依赖内存。
适用场景 当出现以下信号时适合使用：只验证过开发环境、不清楚系统极限在哪里、未加测试就断言“应该能扩展”、以及被生产环境行为意外到。
限制 资料未提供该方法的具体工具实现、自动化支持、定价或平台要求，相关事实暂未提供。使用时应记住：极端条件揭示根本；在一种规模下可行的方案在另一种规模下可能失败；要同时测试两个方向（更大与更小）；并将所得洞见用于尽早验证架构。