降级依据实测能力而非设备型号
别名: 能力探测 · UA 嗅探 · device model · hardwareConcurrency · saveData
概念解释
要不要降级，问的是此刻这台机器能不能撑住当前任务，不是它出厂时贴的型号。名单（某代手机、某 GPU、某系统版本）是营销标签；同型号机器因后台进程、省电模式、温度墙、同时打开的标签，能力可以差一截。能力探测（capability detection）读的是可观察量：当前帧率、内存、逻辑核数、网络类型、saveData、prefers-reduced-motion。UA 字符串和营销名不在观测里。
它处理的是降级开关的输入从哪来，不是先砍什么，也不是功能能不能砍。动画只是可探测的一维，不是整张能力图。
机制
型号把出厂规格压成一个名字，规格是上限，不是当前可用预算。省电会锁频，过热会降频，浏览器里别的标签在抢内存，低端芯片的上限本来就贴着这条任务。探测直接量预算：连续若干帧的实际帧时长、navigator.hardwareConcurrency、deviceMemory、Network Information 的 downlink / saveData、一次解码或一次布局的耗时。量到不够，再关特效。UA 嗅探把「名字 → 曾经的规格」当成当前预算，名单滞后、伪造、被新机型打穿，而且对同一名字的热机和冷机给出同一答案。
能力还会在会话中变。开始时帧率够，三分钟后过热，开关应当能在中途再读一次，而不是开机时查一次型号就锁死。用户声明（减少动态、节省流量）是能力的一部分：它们不是硬件测量，但是对「这台设备此刻愿付多少」的直接观测，比型号更准。
边界
能力 API 本身会撒谎或缺失：deviceMemory 分档粗、被指纹对抗四舍五入，Safari 上部分网络信息不暴露。缺失时要有保守默认，不能因为读不到就按旗舰跑。型号名单在崩溃统计、驱动黑名单这类「这颗芯片有已知缺陷」的场景仍有用，那是缺陷，不是性能预算。机器人、预渲染、无头浏览器的探测值不代表用户。第一次绘制之前还没有帧率样本，首屏降级只能用静态信号（核数、内存、saveData、用户声明），帧率用来管后续持续成本。纯阅读的静态页几乎测不到「撑不住」，不要为探测而探测。
怎么落地
- 用核数、内存、
saveData、减少动态、以及运行中的帧时长作为开关；不要维护「iPhone 某代 / 某 Android 系列」名单。 - 把探测做成可在会话中重读：过热或切到省电之后允许再降一档，而不是只在启动时判一次。
- API 读不到时走保守档，而不是走最高档。
- 验证：同一型号分别在插电高性能、省电、打满后台的条件下打开同一页，降级档位应能分开；换一台同档但不同名字的机器，档位应跟能力走而不是跟名字走。再伪造一个 UA 成旗舰，确认不会因此打开付不起的特效。