最清晰的http状态码处理方式是分层switch分支：先按2xx/4xx/5xx大类分层，再类内细化；用语义化常量替代魔法数字；每个case执行完整业务闭环；default必须有明确兜底策略并注释依据。

直接用 switch 对状态码做分支处理，是最清晰、最可控的标准化响应映射方式。关键不是“能不能用”，而是怎么组织逻辑才能兼顾可读性、可维护性和业务语义。

明确状态码分类边界，按语义分组处理

HTTP 状态码首位数字代表大类，先按 2xx / 4xx / 5xx 分层判断，再在每类中细化。避免把所有状态码平铺在同一个 switch 里，否则难以看出意图。

• 2xx：统一走“成功路径”，但 200、201、204 后续动作不同（如是否解析 body、是否跳转）
• 4xx：归为客户端问题，但 401（鉴权缺失）和 403（权限不足）应触发不同引导逻辑
• 5xx：视为服务异常，通常需降级或重试，但 503（临时不可用）比 500 更适合自动重试

用枚举或常量定义状态码，避免魔法数字

硬写 case 404: 容易出错且难检索。推荐预先定义语义化常量：

Switch Modes

动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。

下载

• C/Go：用 enum 或 const 声明 StatusCodeNotFound = 404
• JavaScript/TypeScript：导出对象 { NOT_FOUND: 404, UNAUTHORIZED: 401 }
• 这样 switch 中写 case StatusCode.NOT_FOUND:，既安全又自解释

每个 case 绑定明确的业务动作，而非仅打印日志

switch 的价值在于驱动行为。每个分支应完成一个完整闭环，例如：

• 200 → 解析 JSON、更新 UI 状态、清除加载提示
• 401 → 清除本地 token、跳转登录页、暂停后续请求队列
• 404 → 显示「页面不存在」toast、记录埋点、不重试
• 503 → 启动指数退避重试、显示「服务暂时繁忙」、启用本地缓存兜底

兜底 default 分支必须有明确策略

不能只写 default: log("unknown code")。要定义默认行为：

• 客户端：统一视为网络异常，触发通用错误页或重试入口
• 服务端：记录告警并返回 500，防止未知状态码穿透到前端
• 建议加一行注释说明兜底逻辑依据，例如 // 兜底：非标码按服务端错误处理