## 问题：HTTP3 降级策略 先锁证据

HTTP3 降级策略 这类问题不要先改大段架构，先把现场证据固定下来。本文只处理一个窄场景：http3 的状态在边界条件下失真，导致线上表现不稳定。排查时先记录触发入口、设备版本、复现概率和最近一次变更，再决定是否进入代码修复。这样做的好处是避免把 HTTP3 降级策略 写成泛泛教程，后续每一步都能用命令或日志复核。

adb shell getprop ro.build.version.release
adb logcat -c
adb logcat -v time | grep -i "http3|quic|fallback"

## 方案：把入口、状态和兜底拆开

处理 HTTP3 降级策略 时，我会先建一张小表：入口是否重复、状态是否可恢复、兜底是否会扩大影响。入口层只做去重，状态层只做原子更新，兜底层只做降级，不把三件事混在一个回调里。对团队协作来说，这比写一个万能工具类更稳，因为每个失败点都有独立日志。

data class ProbeState(
 val scene: String,
 val step: String,
 val stable: Boolean,
 val note: String
)

fun markHttp3(step: String, ok: Boolean): ProbeState {
 return ProbeState("HTTP3 降级策略", step, ok, if (ok) "pass" else "need-check")
}

## 示例代码：最小可插入实现

下面的代码故意保持很小，方便直接塞进 demo 或灰度分支。重点不是覆盖所有业务，而是让 HTTP3 降级策略 的关键路径有可观测输出。上线前可以把 println 换成团队日志库，字段名保持不变，便于和旧版本对比。

class Http3Guard {
 private val seen = linkedSetOf()

 fun enter(key: String): Boolean {
  if (key in seen) return false
  seen += key
  return true
 }

 fun clear(key: String) {
  seen.remove(key)
 }
}

fun verifyQuic(expected: String, actual: String): String {
 return if (expected == actual) "matched:$actual" else "mismatch:$expected/$actual"
}

## 注意点：别让修复引入新回归

第一，日志字段要短，但必须能区分设备、入口和状态版本。第二，兜底分支不能吞掉错误，否则下一次只会看到成功假象。第三，如果 HTTP3 降级策略 出现在启动、播放、支付或存档链路里，灰度比例要更小，先跑一组固定设备。第四，代码评审时只问三件事：是否可复现、是否可回滚、是否有反证命令。

{
 "scene": "HTTP3 降级策略",
 "entry": "http3",
 "state": "quic",
 "fallback": "fallback",
 "rollback": true
}

## 报错与排查

1. 复现不稳定

如果同一台设备偶发通过，先固定输入和时间窗口，不要马上怀疑系统版本。把 http3 的前后日志取出来，再比较 quic 是否被二次写入。

adb shell date
adb logcat -d | grep -i "http3" | tail -50
adb shell dumpsys activity processes | head -40

2. 修复后性能下降

如果补了保护后出现卡顿，通常是锁范围过大或日志过密。把关键区缩短，只保留必要字段，再用简单计数确认没有重复进入。

fun shouldTraceFallback(count: Int, costMs: Long): Boolean {
 return count < 3 || costMs > 120
}

## 可运行片段

最后保留一个能直接跑的片段，用来确认 HTTP3 降级策略 的入口去重和状态输出没有坏。只要这个最小样例能稳定，再把同样字段迁移到真实工程里。

fun main() {
 val guard = Http3Guard()
 println(guard.enter("case-1"))
 println(guard.enter("case-1"))
 println(verifyQuic("ready", "ready"))
}