HTML中不存在“HTML函数”，所有逻辑必须通过JavaScript在<script>标签或外部JS文件中实现，浏览器单线程执行JS，真并行需用Web Worker。
HTML 函数根本不存在，别被名字骗了
浏览器里没有 HTML 函数 这个东西。所谓“HTML 函数”，实际是开发者对 JavaScript 在 HTML 环境中执行逻辑的误称。HTML 本身是标记语言，不支持函数定义、调用或并行执行。所有“HTML 函数”的行为，本质都是 JS 引擎在解析 DOM 后运行的脚本。
常见错误现象：Uncaught ReferenceError: myHtmlFunction is not defined —— 其实是你把没声明的 JS 函数当 HTML 原生能力用了；或者以为加个 async 到 <script> 就能“并行跑 HTML”。
- 所有逻辑必须落在
<script>标签内，或外部.js文件中 -
<script src="..."></script>的加载顺序直接影响变量/函数可用性 - 浏览器单线程执行 JS，所谓“并行”只能靠
Web Worker、Promise、setTimeout或现代async/await模拟
想并行处理？得靠 Web Worker + 主线程通信
浏览器主线程被 DOM 渲染和 JS 执行共用，密集计算会卡 UI。真要并行，唯一标准方案是 Web Worker —— 它在独立线程运行 JS，不阻塞页面。
使用场景：图像处理、大数据排序、加密解密、实时音频分析等耗时操作。
立即学习“前端免费学习笔记（深入）”；
-
Worker不能访问document、window、localStorage等主线程专属 API - 通信必须用
postMessage()和onmessage，传参是结构化克隆（不支持函数、DOM 节点） - 每个
Worker实例独占一个线程，启动开销大，不适合短任务；频繁创建销毁反而拖慢性能 - 示例：启动一个简单计算 worker
// main.js
const worker = new Worker('calc-worker.js');
worker.postMessage({ data: [1, 2, 3, 4, 5] });
worker.onmessage = (e) => console.log('result:', e.data);
// calc-worker.js
self.onmessage = (e) => {
const sum = e.data.data.reduce((a, b) => a + b, 0);
self.postMessage(sum);
};
“核心数”不是你能配的，而是浏览器+系统决定的
你无法在 HTML 或 JS 中指定“用几个 CPU 核心”。Web Worker 的线程调度完全由浏览器和操作系统控制：Chrome 可能为每个 Worker 分配独立 OS 线程，但最多不超过硬件逻辑核心数；Safari 对 Worker 数量有更保守限制；移动端还可能因省电策略降频或挂起。
性能影响很实际：
- 开 8 个 Worker 不等于 8 倍速度——内存带宽、缓存争用、线程切换成本会抵消收益
- Node.js 有
cluster模块可显式 fork 进程，但浏览器没有等价机制 - 检查可用核心数？可以用
navigator.hardwareConcurrency，但它只是建议值，不保证可用，也不代表你能“分配”到
替代方案比硬上多线程更常用
90% 的前端“并行需求”，其实用非阻塞方式就能解决，根本不需要 Worker。
常见错误现象：用 for 循环同步处理几千条数据，导致页面冻结；或以为 Promise.all() 是“多线程并发”，其实它只是并发触发异步任务，执行仍在单线程排队。
- 大数据分片 +
setTimeout或requestIdleCallback让出主线程控制权 - 用
Promise.allSettled()并发请求多个 API，但注意浏览器默认有同域请求数限制（通常 6 个） - 渲染大量列表？用虚拟滚动（
IntersectionObserver+ 懒加载），而不是一次性生成 DOM - 避免在循环中反复读写
innerHTML或appendChild，批量操作用DocumentFragment
真正卡住的时候，先查是不是 DOM 操作太猛、重排重绘太多，而不是急着加 Worker。JS 引擎优化得很深，但 DOM 操作永远是最重的瓶颈。
