老旧硬件能跑主流HTML函数工具，但必须避开IE8–10的querySelectorAll全量遍历、Android 4.3 WebView的innerHTML整树重建等引擎硬伤，降级DOM操作、缓存布局信息、限制批量插入节点数、调整Chrome堆内存参数是关键。
老旧硬件能不能跑主流 HTML 函数工具，不看“还能不能开机”，而看它是否能避开老浏览器引擎的硬伤——比如 IE8 的 querySelectorAll 退化成全量遍历、或 Android 4.3 WebView 对 innerHTML 赋值的整树重建。CPU 主频再高，也救不了没实现 CSS3 选择器解析的 Chakra 引擎。
IE8–10 机器：只认降级 DOM 操作，不认现代 API
这类设备（如 Core2 Duo + 2GB RAM + Windows 7）常见于企业旧终端，问题不在内存或 CPU，而在 DOM API 实现残缺：
-
getElementsByClassName在 IE8 中根本不存在，垫片实现常是getElementsByTagName("*")全量扫描 + 字符串匹配，1000 个节点就卡顿 200ms+ -
querySelectorAll(".item[data-id='1']")在 IE8 直接返回空数组或抛错，必须拆成getElementsByClassName("item")再手动过滤getAttribute("data-id") -
document.createDocumentFragment()虽支持，但插入 50+ 节点后仍会触发多次 layout，得控制单次批量不超过 20 个
Android 4.3 WebView 设备：JS 执行慢 + 渲染无合成层
典型如 Nexus 4、部分国产千元机，其 WebView 基于旧版 WebKit，V8 引擎未启用 TurboFan，且渲染管线不支持 GPU 合成：
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
-
offsetHeight或getBoundingClientRect()每调一次都强制同步 layout，连读两次就会掉帧；应缓存结果，避免在循环里反复读取 -
requestAnimationFrame存在但精度差，实际帧间隔波动达 ±8ms，动画类函数工具需改用setTimeout+ 时间戳校准 - CSS
transform: translateZ(0)无效，无法强制 GPU 合成，视频/Canvas 类工具必须降为 320×240 分辨率并关闭抗锯齿
二手笔记本（奔腾 N4200 / i3-4005U）：瓶颈常在内存与 Chrome 进程模型
这类设备（4GB RAM + eMMC 存储）跑 Chrome 最容易因 JS 堆溢出卡死，不是 CPU 不够，而是 V8 默认堆上限（2GB）和页面交换叠加：
立即学习“前端免费学习笔记（深入）”；
- Chrome 启动参数必须加
--max-old-space-size=4096，否则加载 Lodash 或 Moment 等库时 GC 频繁冻结主线程 - 禁用所有扩展后仍卡顿，检查
chrome://memory-internals是否存在多个 renderer 进程共用同一 JS 堆，此时应强制启用--process-per-site - eMMC 读写延迟高，HTML 工具若含大量
fetch()请求本地 JSON，应改用XMLHttpRequest+ 缓存响应头Cache-Control: max-age=3600减少磁盘寻道
最麻烦的点往往藏在“不报错但变慢”里：比如 IE11 对 typeof null === 'object' 的隐式类型转换开销比 Chrome 高 17 倍，一个简单表单验证循环里多一次判断，延迟就从 12ms 涨到 200ms。兼容性不是让代码跑起来，而是让老引擎少做一次它本不该做的隐式工作。
