用极端规模测试暴露架构根本问题（1000 倍放大/缩小…

当不确定可扩展性、边界情况不清晰，或需要验证架构能否支撑生产规模时，用极端取值测试系统会先在哪里崩、什么又意外扛住。

适用场景

解决思路

1. 选取一个可能被极端拉伸的维度：哪些方面可能变化极大？
2. 测试最小极端：如果这个维度缩小/变快/变少 1000 倍会怎样？
3. 测试最大极端：如果这个维度放大/变慢/变多 1000 倍会怎样？
4. 记录哪里会崩：系统在哪些位置出现极限？
5. 记录什么能存活：哪些部分是根本可靠的？
6. 按维度逐一极端测试：数据量取 1 条 vs 10 亿条，考察算法复杂度上限；速度取瞬时 vs 一年，考察异步需求与缓存必要性；用户数取 1 个 vs 10 亿个，考察并发问题与资源上限；持续时间取毫秒 vs 数年，考察内存泄漏与状态增长；失败率取从不失败 vs 始终失败，考察错误处理是否足够。
7. 错误处理场景：正常规模下“出错时处理错误”可行；到 10 亿规模时错误量会淹没日志、拖垮系统，结论是要么用类型系统让错误不可能发生，要么用混沌工程主动预期错误。
8. 同步 API 场景：正常规模下直接函数调用可行；到全球规模时网络延迟让同步调用不可用，结论是异步/消息传递从优化项变成生存必需。
9. 内存状态场景：正常时长下运行数小时/数天可行；拉长到数年时内存无界增长并最终崩溃，结论是需要持久化或定期清理，不能依赖内存。
10. 留意需要此技能的红旗信号：“在我机器/dev 环境能跑”但能否撑住生产？完全不知道极限在哪；只说“应该能扩展”却没测试；被生产环境行为吓到。
11. 用得到的洞见尽早验证架构，并同时测试两个方向（放大 AND 缩小）。

适用边界 · 注意事项

• 已经明确知道系统规模固定、永远不会接近极端取值时，不必做极端规模测试。
• 只是要验证小规模下的功能正确性、与规模无关的普通单元测试场景。
• 缺乏可模拟极端规模的测试环境或手段，且无法通过推演/评审替代时，强行做可能得到误导性结论。