修改配置并确认生效

域名、联邦白名单、上传限额、TTL、搜索预算和关停等待都属于实例运行配置。它们以 PostgreSQL 为唯一权威，通过 Dashboard、tb config 或 system/config 修改。

保存与生效是两步

读取当前 revision → 校验完整设置 → 保存 desired → apply → 核对 effective

保存只记录期望配置。apply 成功重建运行资源后，才发布已应用 revision；失败时保留上次成功状态并返回脱敏错误。

使用 Dashboard

打开实例管理中的配置页，查看当前设置、desired / effective 与 revision。修改表单、保存后显式应用，再确认 appliedRevision 与期望一致。页面保存成功不能代替应用成功。

使用 CLI

tb config schema
tb config get
tb config status

以 get 返回的完整 settings 为基础编辑 settings.json；不要把整个响应包装直接当 settings，也不要只提交一个字段并意外采用其他字段默认值。

tb config validate --file ./settings.json
tb config update --revision <current-revision> --file ./settings.json
tb config apply --revision <saved-revision>
tb config status

将占位 revision 替换为实际响应值。revision 冲突表示有人先修改了配置，重新读取和合并，不要直接覆盖。

哪些设置去哪里改

你要修改	正确入口
公开 origin、白名单、限额、TTL、清理和排空	tb config / 配置页
S3 endpoint、bucket、活动后端或访问凭证	tb storage
数据库、Redis、数据库凭证	tb maintenance
加密根、签名根与备份	tb keys
镜像、published 端口和受限目录	tb deployment 与本机执行器

这些管理动作需要对应 system/* 路径的 admin。普通节点 write 不授予实例管理权。

应用之后验证

检查 status 的应用结果，再验证受影响能力：改 origin 后核对 OAuth/对象读取，改限额后用边界内输入验证，改联邦白名单后读取目标 remote。

每次请求使用一个不可变配置快照。在途请求自然完成，已发上传授权不会被事后扩大；pending 配置也不会影响关停等待。多副本各自报告应用状态，不能只看保存响应就判定所有副本已生效。