HTML本身没有函数，它是标记语言，只定义结构；onclick等属性和<script>中的代码实际是JavaScript，所谓“HTML函数”是开发者对事件处理函数或内联脚本的误称。
HTML 本身没有函数，浏览器运行的是 JavaScript，而 JavaScript 的执行对硬件有间接但真实的影响——不是“必须满足某配置才能跑”，而是性能、稳定性、兼容性会随硬件（尤其是 CPU、内存、GPU）明显变化。
为什么说“HTML函数”这个说法不成立
HTML 是标记语言，只定义结构，不包含可执行逻辑。onclick、onload 等属性里写的代码，实际是 JavaScript；<script> 标签里运行的也是 JavaScript。所谓“HTML函数”，99% 是开发者对事件处理函数（如 handleClick()）或内联脚本的误称。
浏览器渲染 HTML + 执行 JS + 绘制样式，整个流程由引擎（如 V8、SpiderMonkey）完成，这些引擎依赖 CPU 解释/编译代码、内存管理对象、GPU 加速合成图层——硬件能力直接决定卡不卡、崩不崩、动效流不流畅。
低端设备上常见的 JavaScript 执行问题
-
setTimeout和setInterval实际间隔严重漂移（CPU 拥塞时可能延迟数百毫秒） - 大量 DOM 操作（如循环创建 1000 个
<div>）触发重排（reflow），在 ARM Cortex-A7 或老旧 Intel Celeron 上可能卡顿 2 秒以上 -
JSON.parse()解析 5MB 以上数据，在 2GB 内存设备上容易触发内存警告甚至被系统 kill - 使用
WebGLRenderingContext或OffscreenCanvas时，无独立 GPU 的集成显卡（如 Intel HD Graphics 400）可能 fallback 到纯 CPU 渲染，帧率跌破 10fps
如何判断你的 JS 是否受硬件拖累
别猜，用工具实测：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools →
Performance面板录制操作，重点看Scripting和Rendering时间占比；若 Scripting 占比 > 60%，说明 JS 执行是瓶颈 - 监听
window.performance.memory（需开启 Chrome 的--enable-precise-memory-info启动参数），观察usedJSHeapSize是否持续逼近totalJSHeapSize - 在目标设备（如 Android Go 手机、Windows 10 S 模式平板）上打开
about:memory（Firefox）或chrome://memory-internals，对比空页与运行你页面后的内存增长
注意：requestIdleCallback() 在低配设备上可能极少触发——不是 bug，是系统真没空闲时间片。
写 JS 时必须考虑硬件差异的几个点
不是“写得炫酷就行”，而是让代码在树莓派 4B 和 iPhone 15 Pro 上都别崩：
- 避免长任务：单次 JS 执行超过 50ms 就可能掉帧；用
queueMicrotask()或setTimeout(..., 0)拆分循环 - DOM 批量操作优先用
DocumentFragment，而不是反复appendChild() - 大数组处理改用
for而非forEach()（V8 对前者优化更激进，低端 CPU 差异可达 3 倍） - 图片/视频资源加
decoding="async"和loading="lazy"，防止解析阻塞主线程 - 谨慎使用
IntersectionObserver的threshold数组——某些低端安卓 WebView 会因计算开销直接忽略
最常被忽略的一点：Intl.DateTimeFormat 和 Intl.NumberFormat 在旧版 Samsung Internet 或 KaiOS 浏览器中可能抛 RangeError，不是硬件问题，但和硬件绑定的系统 WebView 版本强相关——得兜底用字符串拼接。
