HTML本身没有函数，所谓“HTML函数在多用户远程桌面卡顿”实为远程桌面链路中网络传输、本地解码或远程渲染任一环节失衡所致，根源在于高频DOM更新、未硬件加速的CSS动画、后台requestAnimationFrame未暂停、强制同步布局及WebGL/canvas支持不足等问题。
HTML 本身没有函数，所谓“HTML 函数在多用户远程桌面卡顿”，实际是远程桌面链路中某环被压垮了——不是 HTML 写法问题，而是网络传输、本地解码、远程渲染三者协同失衡导致的响应粘滞。
远程桌面里卡顿，真凶往往藏在 Chrome DevTools 的 Network 和 Rendering 面板里
远程桌面（如 Windows RDP、AnyDesk、ToDesk）本质是把远端画面编码→网络传输→本地解码→合成显示。一旦页面里有高频 DOM 更新（比如 setInterval 每 50ms 改一次 textContent）、或 CSS 动画未用 transform/opacity 触发硬件加速，远端浏览器就会持续提交新帧，而远程桌面服务端来不及编码，本地又解码不过来，结果就是“鼠标点了没反应”“滚动掉帧”。
- 打开 DevTools →
Rendering面板 → 勾选Paint flashing，看是否大面积频繁闪烁（说明重绘太猛） - 切到
Network面板，禁用缓存后刷新，观察document和关键 JS 资源的Finish时间是否突增（可能远端带宽被其他用户挤占） - 若用 RDP，确认远端 Windows 已关闭“视觉效果”：系统属性 → 高级 → 性能设置 → 仅勾选“平滑屏幕字体”
requestAnimationFrame 在远程桌面下必须配合 visibilitychange 使用
远程桌面常把后台标签页当“不可见”处理，但默认的 requestAnimationFrame 不会自动暂停——它仍向远端浏览器请求新帧，徒增编码压力。不加控制的话，10 个用户同时开着同一页面，远端 CPU 就在空转。
- 必须监听
document.addEventListener('visibilitychange', () => { ... })，在document.hidden === true时主动cancelAnimationFrame - 避免用
setTimeout或setInterval驱动 UI 更新，它们在后台标签页会被节流，但节流策略各浏览器不一，RDP 下更不可靠 - 动画逻辑里别读取
offsetHeight、getBoundingClientRect()等触发强制同步布局的 API，远程桌面下 layout 计算延迟可能达 200ms+
远程桌面协议对 canvas 和 WebGL 的支持差异极大
如果你的“HTML 函数工具”依赖 <canvas> 绘图或 WebGLRenderingContext，卡顿几乎必然发生——RDP 默认禁用 GPU 加速，AnyDesk 对 WebGL 帧率做硬限制，ToDesk 则可能把 canvas 当静态图截屏传输。
立即学习“前端免费学习笔记（深入）”；
- 测试前先在远端浏览器地址栏输入
chrome://gpu，确认Canvas和WebGL状态为Hardware accelerated - 若为
Software only，在远程桌面设置里启用“GPU 加速”（RDP 需勾选“使用硬件图形适配器”） - 对非关键图表，改用 SVG 或 CSS
clip-path+transform实现，绕过 canvas 渲染管线 - WebGL 场景务必加兜底：
if (!gl) { fallbackToCanvas2D(); }，否则远端黑屏还报错
最容易被忽略的是：远程桌面下，mousemove 事件的 clientX/clientY 坐标精度被大幅降低，导致基于坐标的拖拽、缩放逻辑反复抖动重算——这不是卡，是误判。得用 pointermove + getCoalescedEvents() 拿原始轨迹点，再降噪处理。
