scrollleft同步失效主因是监听/操作对象错误及未防抖。应监听实际可滚动容器（如code-container），禁用body/window；双向同步需加requestanimationframe延迟与scrollleft比对，移动端需用scrollto或translatex模拟。
scrollLeft 同步失效的典型表现
代码编辑器切换到“代码视图”后，预览区横向滚动时代码区不动，或反向拖动代码区时预览区卡住——这通常不是 scrollLeft 没生效，而是同步时机或目标元素选错。最常见的是监听了 window 而非实际可滚动容器，或者没处理 overflow: hidden 导致滚动条被裁剪、事件无法触发。
必须监听和设置 scrollLeft 的具体 DOM 元素
不要对 document.body 或 window 直接操作 scrollLeft，它们在现代浏览器中大多只读。真正可写、可监听的，是设置了 overflow-x: auto（或 scroll）且内容溢出的容器元素，比如：
- 代码块外层的
<div class="code-container"> <li>预览区的 <code><div id="preview-pane"> <li>编辑器主区域的 <code><pre class="brush:php;toolbar:false;"></pre>或<code>父容器 - 用
requestAnimationFrame延迟赋值，避免连续高频写入 - 增加
if (target.scrollLeft !== source.scrollLeft)判断，跳过无意义同步 - 为两个容器分别绑定独立事件处理器，不共用同一函数
确认方式：打开 DevTools，选中该元素 → Elements 面板右键 → “Scroll into view”，看是否触发横向滚动；再手动拖动滚动条，检查 console.log(element.scrollLeft) 是否变化。
双向同步时 scrollLeft 赋值要加防抖和条件判断
直接在 scroll 事件里互相赋值 target.scrollLeft = source.scrollLeft 极易引发循环触发，尤其在 Safari 或旧版 Chrome 中可能卡死。必须加两层防护：
示例片段（假设两个容器变量为 codeEl 和 previewEl）：
codeEl.addEventListener('scroll', () => {
if (previewEl.scrollLeft !== codeEl.scrollLeft) {
requestAnimationFrame(() => {
previewEl.scrollLeft = codeEl.scrollLeft;
});
}
});
previewEl.addEventListener('scroll', () => {
if (codeEl.scrollLeft !== previewEl.scrollLeft) {
requestAnimationFrame(() => {
codeEl.scrollLeft = previewEl.scrollLeft;
});
}
});
移动端 touchmove 下 scrollLeft 同步容易失灵
iOS Safari 和部分安卓 WebView 在 touchmove 过程中不会实时更新 scrollLeft，直到手指抬起才触发一次 scroll 事件。这意味着拖动过程中预览区看起来“不同步”。解决办法只有两个：
- 改用
getBoundingClientRect()+transform: translateX()模拟滚动（适合只读预览区） - 监听
touchmove并手动计算偏移量，再用element.scrollTo({ left: x })强制更新（注意兼容性：iOS 13+ 支持scrollTo的对象参数）
如果必须保真原生滚动行为，就接受这个限制：移动端横向同步只能做到“松散一致”，即手指松开后立刻对齐，而非拖动中像素级跟随。
真正难的不是读写 scrollLeft，而是判断哪个元素在滚动、哪个在响应、以及什么时候不该响应。
