HTML本身没有函数概念且不参与硬件资源分配，真正决定资源调度的是浏览器进程模型、Web API环境及后端架构；DOM操作阻塞渲染但不抢占服务器资源，fetch并发需前后端协同限流，Wasm仍受浏览器内存与线程约束。
HTML 本身没有“函数”概念，更不参与硬件资源分配——这是常见误解的根源。真正涉及资源调度的是浏览器进程模型、Web API 运行时环境，以及后端服务架构。
为什么 document.getElementById 不会抢 CPU 或内存
前端 JavaScript 执行在单线程的渲染进程中（每个标签页通常对应一个独立进程），getElementById、fetch、setTimeout 等只是触发浏览器内部 C++ 实现的底层操作，它们不直接申请内存页或调度 CPU 核心。资源分配由操作系统和浏览器进程管理器完成，JS 代码只能间接影响（比如创建大量对象会触发 V8 垃圾回收，导致短暂停顿）。
- 所有 DOM 操作都在主线程同步执行，高频率调用
innerHTML或反复appendChild会阻塞渲染，但不会跨用户抢占服务器资源 - Web Workers 可以启用多线程 JS，但每个 Worker 仍受限于浏览器分配的内存配额（通常几百 MB），且无法访问 DOM
- 所谓“多用户共享 HTML”，实际是多个用户各自加载相同静态资源（HTML/CSS/JS 文件），这些文件由 Web 服务器（如 Nginx）通过文件系统缓存或内存映射提供，不因用户数增加而线性消耗 CPU
fetch 并发过多时后端连接被打满怎么办
前端 fetch 请求最终落地为 TCP 连接，大量用户同时发起请求，会压垮后端服务（如 Node.js 的 http.Server 默认最大连接数约 5000，但活跃连接过多会导致 Event Loop 阻塞）。这不是 HTML 或 JS 的问题，而是客户端节流 + 后端限流配合缺失。
- 前端可用
Promise.allSettled包裹带节流的请求队列，例如用async-pool控制并发数 ≤ 6（避免浏览器对同一域名的 HTTP/1.1 连接限制） - 后端需配置反向代理层限流：Nginx 中用
limit_req限制每秒请求数，或使用 Redis 计数器实现用户级 QPS 控制 - 避免前端轮询（
setInterval(() => fetch(...), 1000)），改用 Server-Sent Events 或 WebSocket 持久连接，减少连接建立开销
WebAssembly 模块是否能绕过浏览器资源限制
Wasm 确实运行在沙箱内更接近机器码的环境中，但它仍被约束在浏览器分配的线性内存（WebAssembly.Memory）里，默认上限 4GB（实际受制于 Chrome 的 per-process 内存策略），且无法直接调用系统 API 分配物理内存或绑定 CPU 核心。
立即学习“前端免费学习笔记（深入）”；
- Wasm 函数调用不比优化后的 JS 快多少，除非是计算密集型场景（如图像处理、加密），否则收益有限
- 多个用户同时加载同一 Wasm 模块（如
foo.wasm），浏览器会复用已编译的实例，但每个页面实例仍独占一份内存副本 - 若用
WebWorker + Wasm把重任务移出主线程，必须手动传递 ArrayBuffer，避免结构化克隆开销；否则大数组复制反而拖慢性能
真正决定多用户系统资源水位的，从来不是某个 HTML 标签或 JS 方法，而是服务端连接模型（长连接 vs 短连接）、静态资源缓存策略（CDN 缓存头是否设 Cache-Control: public, max-age=31536000）、以及前端是否无意中触发了高频重绘（requestAnimationFrame 里反复修改 style.transform 却没用 will-change 提示合成器）——这些细节比纠结“HTML 函数”重要得多。
