性能与规模 是做什么的？
概述
性能是一项有预算的特性。请测量它、限制它，并认识到今天的行为会成为明天的契约。系统很少在你设计时的吞吐量下崩溃——它们往往崩溃在你未建索引的查询和未分页的列表上。
原则
- 设定预算并对照测量。 延迟目标（关联
observability-and-slos的 SLO）和客户端预算（例如包体积）。回归超出预算即为缺陷。 - 先测量，再优化。 在修改代码前，通过数据（Profile、查询计划、追踪）找到真正的瓶颈。杜绝推测性优化。
- 默认分页。 任何可能增长的列表都应分页，并设置分页大小上限。无界的结果集是延迟和拒绝服务攻击的隐患。
- 警惕 N+1 访问模式。 在循环中获取数据是最常见的可扩展性故障；应改用批处理或连接查询。（在此技术栈上：使用 GraphQL 层的 Look-ahead/DataLoader 而非逐行解析。）
- 海勒姆定律是真实的：接口的每个可观察行为一旦有足够多的消费者，就会成为某人依赖的契约——包括你从未意图的行为（顺序、可空性、错误形态、时序）。请将公共接口（尤其是 API/模式）视为契约：添加并弃用，勿静默修改。
graphql-contract-testing的契约测试固定了你选择的行为；自律保护了你未选择的行为。
快速参考
| 问题现象 | 修复方法 |
|---|---|
| 循环内的查询 | 批处理或连接查询；使用 Look-ahead |
| 无限制的列表端点 | 添加分页上限 |
| “让我优化这个”但未测量 | 先 Profile，找到真正的瓶颈 |
| 修改字段的类型/可空性/顺序 | 这是契约变更——新增字段，弃用旧字段 |
| 无延迟或包体积目标 | 设定预算；将回归视为缺陷 |
执行机制： 预算在 CI 中进行可机械化检查（包体积限制、查询成本限制）；分页和 N+1 避免由评审人员根据负载测试和查询计划审查做出判断。
完整理由：宪法第 XI 条，附在 engineering-constitution/references/engineering-constitution.md。