应根据运行时可测能力选择HTML函数工具：用navigator.hardwareConcurrency决定DOM并发策略，CSS.supports检测GPU合成支持，监听devicePixelRatio变化响应DPI切换。
直接看硬件参数决定用哪个 HTML 函数工具，不现实——浏览器和 JavaScript 引擎已经做了大量抽象，你真正该盯的是「当前设备在运行时暴露出来的可测能力」，而不是 CPU 型号或显存大小。
查 navigator.hardwareConcurrency 判断是否能并行处理 DOM 批量操作
这个值反映可用逻辑处理器数量，直接影响 Web Workers、Promise.all 并发策略，以及是否适合用多线程做 DOM 预生成。
- 返回值 ≤ 2：避免用
requestIdleCallback做分片渲染，它可能极少触发；改用setTimeout+ 每帧控制 10–20 个节点插入 - 返回值 ≥ 4：可安全启用
DocumentFragment批量挂载，甚至把querySelectorAll结果切片后分发给 Worker 处理 - 注意：某些 Android Go 设备会返回
undefined或1，此时应 fallback 到单帧最大 5 个节点的保守策略
用 CSS.supports('transform', 'translateZ(0)') 测 GPU 合成层支持
不是所有标称“支持 CSS3D”的设备真能稳定启用硬件合成。这个检测比查 UA 或 GPU 型号更可靠，因为它走的是浏览器渲染管线的实际能力判断路径。
- 返回
true：可放心加style="will-change: transform;"或transform: translateZ(0)触发合成层，但仅限动画容器，别滥用在静态元素上 - 返回
false：禁用所有transform+opacity组合动画，改用top/left+position: relative（重排代价低，且不会意外触发软件渲染） - 特别注意：iOS Safari 在某些旧版本中对
CSS.supports返回false，但实际支持translateZ(0)，建议加一层typeof window.WebKitCSSMatrix !== 'undefined'补充判断
监听 window.devicePixelRatio 变化决定 Canvas 渲染精度
多显示器环境下，拖动窗口到不同 DPI 屏幕时，devicePixelRatio 会变。如果 Canvas 不重设 width/height 并调用 ctx.scale()，图像立刻模糊——这不是函数工具选错，而是没响应这个事件。
立即学习“前端免费学习笔记（深入）”；
- 必须监听
window.matchMedia('(resolution: 2dppx)').addEventListener('change', ...)，不能只靠resize - 初始化 Canvas 时，用
canvas.width = canvas.clientWidth * window.devicePixelRatio，而非固定值 - 在
requestAnimationFrame回调里检查window.devicePixelRatio是否变化，有变就重置缓冲区，否则副屏拖入后第一帧仍糊
真正容易被忽略的点是：硬件参数只是起点，关键在「运行时动态响应」。比如 navigator.hardwareConcurrency 是静态值，但内存压力会让它实际可用核心数归零；devicePixelRatio 能读到，但不监听 change 事件就等于没读。工具再好，不接这些钩子，照样在真实设备上翻车。
