硬件适配关键在html属性与js调用：cpu弱时禁用queryselectorall，改用getelementbyid；内存≤2gb时禁用内联模板字符串，用textcontent填充；高ppi屏须按devicepixelratio设置canvas宽高并缩放；触控设备需设inputmode、事件委托及最小48px点击区。
硬件档次决定的是「能跑什么」，而不是「该用什么」——HTML模板函数工具本身不消耗GPU或大量内存，真正卡顿的根源往往在浏览器渲染策略、DOM操作方式和资源加载路径上。选错工具不会让页面变慢，但用错函数会。
CPU弱（i3-8100以下 / ARM Cortex-A72）时禁用querySelectorAll类批量操作
这类设备常见于旧款Chromebook、入门级Windows平板或树莓派桌面环境，主线程响应延迟明显，querySelectorAll + forEach 遍历50+节点就可能触发16ms掉帧。
- 改用
getElementById或带ID前缀的getElementsByClassName，避免CSS选择器解析开销 - 模板中所有动态区域必须预设唯一
id，例如<div id="template-report-body">，而非靠类名匹配 <li>若需条件渲染，用 <code>dataset标记状态：<div data-status="draft">，再用 <code>querySelector('[data-status="draft"]') - 禁止在循环中调用
offsetHeight或getComputedStyle，每次触发强制同步布局 - 模板内容统一存为纯JSON配置，通过
textContent和setAttribute填充，绕过HTML解析器 - 完全规避
eval()、new Function()、setTimeout('...')等动态执行入口 - 使用
document.createElement+appendChild构建节点树，比字符串拼接内存峰值低40%以上 - 若必须支持用户自定义模板，只允许
<template></template>标签内嵌，且限制最大字符数（如512B），超出则截断并报错ERR_TEMPLATE_TOO_LARGE - 初始化时必须读取
window.devicePixelRatio，并同步设置canvas.width和canvas.height（非style） - 绘图前必调
ctx.scale(dpr, dpr)，否则所有坐标需手动乘dpr，极易漏算 - 监听
resize和orientationchange，iOS旋转后DPR不变但视口重排，缓冲区需重置 - 禁用
image-rendering: pixelated作补救——它只影响缩放显示，不修复原始缓冲区失真 - 所有表单输入框必须设
inputmode="text"/"numeric"/"decimal"，否则安卓部分输入法默认弹全键盘 - 禁用
click绑定，改用事件委托 +event.target.matches('.btn-save')，避免iOS 300ms点击延迟 - 滚动容器加
touch-action: pan-y，防止横向滑动时触发页面缩放 - 模板中所有可点击区域最小尺寸设为
48px × 48px（CSS像素），低于此值触控误判率陡增
内存小（≤2GB）时拒绝内联模板字符串与eval式渲染
低内存设备无法承受V8引擎反复编译模板字符串产生的临时上下文，innerHTML += '<div>' + data.title + '</div>' 类写法极易引发OOM崩溃。
高PPI屏（MacBook Pro / Surface Laptop）必须校验Canvas缓冲区尺寸
模板若含图表、签名板或拖拽预览等Canvas功能，未适配DPR会导致渲染模糊——这不是CSS问题，是绘图缓冲区没对齐物理像素。
触控设备（Android平板 / iPad）优先启用inputmode与事件委托
软键盘唤起逻辑、触摸目标尺寸、滚动穿透等问题，90%源于HTML层未声明交互意图，而非JS逻辑缺陷。
真正容易被忽略的是：模板函数工具本身没有“硬件适配模式”，所有适配动作都落在你写的那几行document.getElementById、canvas.width和inputmode上。工具只是容器，行为逻辑永远由你注入的HTML属性和JS调用决定。
