供应商选路导读
默认负载均衡已经够用时，不要过度配置；需要显式选路时，也要先确认每个字段的影响。
provider selection 适合处理明确的业务约束。TheRouter 默认已经会做负载均衡和故障恢复， 只有当你确实有价格偏好、区域约束、BYOK 优先级、合规限制或供应商治理要求时，才值得显式加 `provider` 对象。
先确认是否真的需要显式选路
如果没有成本、合规、治理或稳定性方面的明确要求，先使用默认路由通常更合适。
最小可用形态
provider-fields.json
{
"provider": {
"order": ["openai", "anthropic"],
"allow_fallbacks": true,
"only": ["openai", "anthropic"],
"ignore": ["google"]
}
}这些字段分别意味着什么
优先顺序
order
强制 provider 尝试顺序
allow_fallbacks
当前顺序失败后，是否继续尝试其他 providerprovider 名称填品牌名，例如 openai、anthropic、google、deepseek； 一个品牌会匹配 TheRouter.ai 为该品牌提供的全部路由，匹配不到任何路由的名称会被忽略。
接受但不生效的字段
目前只有
order、only、ignore、allow_fallbacks 会影响路由。sort、quantizations、data_collection、max_price、require_parameters为兼容客户端而接受，但不会改变路由，不要依赖它们做价格上限或数据政策控制。什么时候值得显式配置
- 你要优先走 BYOK，再决定是否允许 shared fallback。
- 你所在区域、采购或合规要求限制了 provider 范围。
- 你要把特定高价值流量固定给某几家 provider。
最容易踩的坑
text
1. 一上来就写死 order，结果把默认负载均衡优势废掉
2. 配了 only 但忘了 allow_fallbacks，导致实际冗余很低
3. 把 provider selection 和 model fallback 混成一件事
4. 在没有真实业务约束时过度配置，最后自己都解释不清为什么这样选配置建议
如果你无法清楚说明为什么某类流量必须优先走特定 provider，通常不建议把 `order` 写死。 这样往往只会增加维护成本。