安全生产下fetch需作为受控通信组件：显式超时（AbortController）、分级时限、鉴权前置（自动注入+401全局登出）、敏感操作校验JWT时效、非幂等请求带X-Request-ID防刷。
在安全生产环境下，fetch 不能只当“原生工具”用，而要作为受控、可审计、有兜底的通信组件来设计。核心不是功能多不多，而是每个环节是否具备明确的责任边界和失败应对逻辑。
超时必须显式控制，禁用无限制等待
浏览器默认不设超时，生产环境必须强制约束：
- 统一使用
AbortController设置硬性超时（如 8s），避免请求长期挂起拖垮 UI 线程或内存 - 对不同接口分级：查询类 ≤5s，上传/导出类 ≤30s，超时后主动 abort 并标记为“不可达”
- 禁止仅靠
Promise.race+ 定时器模拟超时——它无法中断底层网络连接，存在资源泄漏风险
鉴权必须前置且不可绕过
Token 不是“加在 header 里就行”，而要嵌入请求生命周期：
- 所有请求自动注入
Authorization: Bearer xxx，由封装层统一读取 localStorage / memory 中的有效凭证 - 401 响应必须触发全局登出流程（清 token、跳转登录页），不得交由业务组件自行处理
- 敏感操作（如删除、支付）额外校验 JWT 的
exp和nbf，拒绝已过期或未生效的令牌
防刷依赖服务端协同，前端只做轻量拦截
前端无法彻底防刷，但可增加攻击成本并快速识别异常：
- 非幂等请求（POST/PUT/DELETE）强制携带客户端生成的
X-Request-ID（UUIDv4），便于后端去重与追踪 - 连续 3 次请求间隔
- 关键路径（如登录、短信发送）调用前检查
navigator.webdriver、userAgent异常特征，命中即阻断并上报
重试只针对瞬态故障，且必须带退避与熔断
重试不是“多发几次”，而是有策略的恢复机制：
- 仅对网络中断、5xx 错误、AbortError 重试；4xx（含 401/403）一律不重试
- 采用指数退避：
100ms → 300ms → 900ms，避免雪崩式重压 - 单个域名 60 秒内累计失败 ≥5 次，触发本地熔断（后续请求直接 reject，不发网），30 秒后自动恢复探测
不复杂但容易忽略：这些规范真正落地的关键，在于把它们写进请求封装函数的骨架里，而不是靠每个开发人员“自觉补充”。
