1. 从一个“按钮点下去没反应”的经典场景说起做前端开发的人几乎都遇到过这样一种情况用户点了一个按钮你希望先把某个区域隐藏起来等数据从服务端回来之后再显示新的内容。逻辑上看起来天衣无缝——先hide()再发请求请求回来show()。但实际跑起来用户看到的却是按钮点下去之后页面卡了一下然后内容直接变了中间那个“隐藏”的状态压根没出现过。这个问题我第一次遇到是在做一个筛选面板的时候。用户切换筛选条件我需要把旧的结果列表先隐藏然后发一个 ajax 请求拿新数据数据回来之后再渲染并显示。代码写得很直白$(#resultList).hide(); $.ajax({ url: /api/list, success: function(data) { render(data); $(#resultList).show(); } });结果就是用户根本看不到列表消失的过程感觉像是页面“顿”了一下然后内容就换了。当时我以为是hide()没生效加了一堆console.log去验证发现hide()确实执行了但浏览器压根没来得及把这次 DOM 变化画到屏幕上就被后面的同步 ajax 逻辑或者紧接着的渲染逻辑给“盖”过去了。这个现象的本质是浏览器的渲染时机和JavaScript 单线程执行模型之间的配合问题。要真正解决它不能只靠“把 hide 写在 ajax 前面”这种表面功夫而是要理解浏览器什么时候才会把 DOM 的变化真正呈现给用户。这篇文章就围绕这个核心问题展开把 ajax 请求中 hide 和 show 的时序控制讲透包括为什么会出问题、几种主流解决方案的取舍、以及我在实际项目里踩过的坑和总结出的稳定写法。适合有一定 jQuery 或原生 JS 基础、正在做数据异步加载交互的开发者参考。2. 浏览器什么时候才肯把 DOM 变化画出来2.1 渲染不是实时的而是“攒一批再画”很多人对 DOM 操作有一个误解觉得element.style.display none这行代码执行完屏幕上立刻就会少一块。实际上浏览器的工作方式是JavaScript 引擎执行你的代码DOM 树被修改但这些修改只是记录在内存里。真正把这些修改画到屏幕上是渲染引擎在合适的时机做的一次“批量提交”。浏览器为什么要攒着因为重排和重绘的代价很高。如果每次改一个样式就立刻重画一次页面性能会惨不忍睹。所以浏览器会把一段时间内的 DOM 修改合并起来在一次渲染帧里统一处理。这个“合适的时机”通常是在当前 JavaScript 执行栈清空之后浏览器才有机会去做样式计算、布局和绘制。这就解释了我们开头看到的现象hide()修改了 DOM但紧接着的 ajax 同步逻辑或者 success 回调里的渲染逻辑还在同一个执行栈里跑浏览器没机会插入一次渲染。等整个栈清空了DOM 的最终状态已经是“显示新内容”了中间那个“隐藏”状态被跳过了。2.2 同步 ajax 是罪魁祸首之一在早期的 jQuery 代码里很多人习惯用async: false来发请求觉得这样代码写起来顺——请求发出去代码停在那里等结果回来继续往下走。但这种写法对渲染的伤害是致命的。同步 ajax 会阻塞整个 JavaScript 线程浏览器在这期间完全无法做渲染。也就是说从hide()到请求返回、show()执行完整个过程浏览器一次渲染机会都没有。用户看到的就是页面冻结然后内容突变。即便你把hide()写在最前面也毫无意义。提示现代浏览器已经明确不推荐在主线程使用同步 ajax控制台会给出警告。除非极特殊的场景否则一律使用异步请求。2.3 异步请求下hide 为什么还是可能“看不见”有人会说那我用异步请求不就行了hide()执行完ajax 发出去JavaScript 执行栈清空浏览器渲染用户看到列表消失然后请求回来再show()。理论上没问题但实际中还是经常看不到隐藏效果。原因通常有两个。第一个是请求太快。如果服务端响应在几十毫秒内就返回了而浏览器的渲染帧间隔大约是 16.7 毫秒60fps那么从hide()到show()之间的时间窗口可能只有一两帧用户视觉上几乎感知不到。第二个是hide 和 ajax 之间还有同步的重活。比如你在hide()之后、发请求之前还做了一大堆 DOM 操作或者复杂计算这些同步代码把执行栈占满了浏览器依然没机会渲染。所以问题的关键不在于“hide 写没写在前面”而在于你是否给浏览器留出了渲染的机会。这个“留出机会”的动作就是接下来要讲的几种方案的核心。3. 让 hide 真正生效的四种时序控制方案3.1 方案一用 setTimeout 把 ajax 推到下一个事件循环最直观的思路是先执行hide()然后用setTimeout(fn, 0)把发请求的逻辑推迟到下一个事件循环。这样当前执行栈清空浏览器有机会渲染然后定时器回调执行发请求。$(#resultList).hide(); setTimeout(function() { $.ajax({ url: /api/list, success: function(data) { render(data); $(#resultList).show(); } }); }, 0);这个方案的好处是简单、兼容性好几乎所有浏览器都支持。setTimeout(fn, 0)并不是真的 0 毫秒后执行而是把回调放到宏任务队列里等当前同步代码跑完、渲染有机会发生之后再执行。但它有个明显的短板渲染时机不可控。setTimeout的回调可能在浏览器渲染之前就执行了尤其是在一些高刷新率设备或者浏览器调度策略不同的情况下。也就是说你给了浏览器机会但浏览器不一定用。实测下来在大多数桌面浏览器上这个方案能work但在移动端或者低性能设备上偶尔还是会出现隐藏效果一闪而过甚至看不到的情况。3.2 方案二requestAnimationFrame 精确对齐渲染帧requestAnimationFrame简称 rAF是浏览器专门为动画提供的 API。它的回调会在下一次重绘之前执行。这意味着如果你在hide()之后用 rAF 来发请求浏览器会先完成这次隐藏的渲染然后在下一帧开始前执行你的回调。$(#resultList).hide(); requestAnimationFrame(function() { $.ajax({ url: /api/list, success: function(data) { render(data); $(#resultList).show(); } }); });这个方案比setTimeout更精确因为它直接和浏览器的渲染节奏对齐。rAF 的回调执行时机是在样式计算和布局之后、绘制之前所以hide()的效果一定会被画到屏幕上。不过 rAF 也有需要注意的地方。第一它在后台标签页里会被暂停如果你的页面可能被切到后台要考虑这个因素。第二rAF 的兼容性虽然现在很好但在一些非常老的浏览器上需要加前缀或者降级处理。第三如果你在 rAF 回调里又做了大量同步操作依然可能影响后续渲染所以回调里最好只做发请求这一件事。3.3 方案三强制重排reflow逼浏览器立即计算样式这是一个“暴力”但有效的技巧。在hide()之后读取一个会触发重排的属性比如offsetHeight、offsetWidth或者getComputedStyle。浏览器为了返回正确的值不得不立即完成样式计算和布局。$(#resultList).hide(); // 强制重排逼浏览器立即应用 hide 的效果 $(#resultList)[0].offsetHeight; $.ajax({ url: /api/list, success: function(data) { render(data); $(#resultList).show(); } });这行offsetHeight的读取看起来毫无意义但它触发了浏览器的强制同步布局。浏览器会立刻把之前积攒的 DOM 修改包括hide()应用掉计算出正确的布局信息。这样即使后面的 ajax 是同步的隐藏效果也已经被“落实”了。这个方案的优点是不依赖异步调度在同步 ajax 场景下也能让 hide 生效。缺点是强制重排本身有性能代价如果频繁调用会导致页面卡顿。所以它适合用在“确实需要立即看到效果”的关键节点而不是到处滥用。3.4 方案四CSS 过渡 类名切换把控制权交给样式层前面三种方案都是在 JavaScript 层面做时序控制。还有一种思路是把显示和隐藏的过渡交给 CSSJS 只负责切换类名。这样即使 JS 执行很快CSS 过渡也会按照自己的节奏播放用户能看到平滑的隐藏和显示过程。.result-list { transition: opacity 0.2s ease; opacity: 1; } .result-list.is-hidden { opacity: 0; pointer-events: none; }$(#resultList).addClass(is-hidden); $.ajax({ url: /api/list, success: function(data) { render(data); $(#resultList).removeClass(is-hidden); } });这个方案的好处是视觉体验最好而且不依赖 JS 的时序控制。CSS 过渡是由合成线程处理的即使 JS 线程繁忙过渡动画也能流畅播放。但它的前提是你接受“淡出淡入”这种过渡效果而不是瞬间的 display 切换。如果产品要求必须是瞬间隐藏那这个方案就不适用。另外要注意opacity: 0的元素仍然占据布局空间如果希望隐藏后不占位还需要配合visibility或者height的过渡复杂度会上升。所以这个方案更适合对视觉体验有要求、且能接受过渡动画的场景。4. 四种方案的横向对比与选型建议4.1 对比表格从五个维度看差异方案渲染保证性能开销兼容性适用场景代码复杂度setTimeout中等低极好一般异步请求低requestAnimationFrame高低好对时序要求高的场景低强制重排高中高极好同步请求或必须立即生效低CSS 过渡高低好允许过渡动画的场景中从表格可以看出没有哪个方案是万能的。setTimeout胜在简单但渲染保证不够强rAF 在渲染保证和性能之间取得了很好的平衡强制重排最可靠但有性能代价CSS 过渡视觉最好但改变了交互形态。4.2 我的选型逻辑先看请求是否同步再看交互要求在实际项目里我的选型顺序是这样的。首先确认请求是不是异步的。如果是异步的优先考虑 rAF因为它和渲染帧对齐可靠性最高性能也好。如果项目需要兼容非常老的浏览器或者团队对 rAF 不熟悉那就用setTimeout兜底。如果因为历史原因必须用同步请求比如某些老系统的接口设计那就只能用强制重排。但我会在代码里加注释说明原因并且尽量把强制重排的范围控制到最小只读取一个属性不做多余操作。如果产品经理说“我要一个淡出的效果”那就直接上 CSS 过渡JS 只切类名。这种情况下根本不需要纠结 JS 时序因为过渡动画本身就把时间拉长了用户自然能看到隐藏过程。4.3 一个容易被忽略的点show 的时机同样重要大家讨论 hide 比较多但 show 的时机也有讲究。如果数据回来之后你先把数据渲染到 DOM然后立刻show()这个顺序是对的。但如果你先show()再渲染用户会看到一瞬间的空白或者旧内容然后才变成新内容体验很差。// 推荐先渲染再显示 success: function(data) { render(data); $(#resultList).show(); } // 不推荐先显示再渲染 success: function(data) { $(#resultList).show(); render(data); }另外如果渲染本身很耗时比如要创建几百个 DOM 节点可以考虑用documentFragment先在内存里拼好再一次性插入减少重排次数。这样show()的时候内容已经是完整的不会出现闪烁。5. 实战中踩过的坑与排查思路5.1 坑一hide 之后立刻读取了某个属性导致强制重排提前发生有一次我写了一段代码hide()之后想确认一下元素是不是真的隐藏了就顺手写了个console.log($(#resultList).is(:visible))。结果这个is(:visible)内部会读取元素的尺寸信息触发了强制重排。虽然 hide 生效了但这次重排发生在我发请求之前等于白白多了一次布局计算。更糟的是如果这段代码在循环里性能会急剧下降。排查这类问题的方法是用浏览器的 Performance 面板录制一段操作看看有没有意外的 “Layout” 或 “Recalculate Style” 事件。如果发现 hide 之后、请求之前有不必要的重排就去检查是不是有读取尺寸、位置、计算样式的代码。5.2 坑二在 success 回调里做了太多同步操作导致 show 延迟数据回来之后success 回调里往往要做很多事情解析数据、创建 DOM、绑定事件、更新其他关联组件。如果这些操作都是同步的而且量很大那么从show()被调用到浏览器真正渲染出内容中间会有一个明显的延迟。用户感觉就是“点了按钮之后卡了半天才出来”。我的做法是把渲染逻辑尽量拆分能异步的异步能分批的分批。比如先用一个简单的 loading 占位然后分帧渲染数据。如果数据量确实很大可以考虑虚拟滚动或者分页而不是一次性全渲染。5.3 坑三多个 ajax 请求并发时hide 和 show 的配对错乱在一个筛选面板里用户可能快速切换多个筛选条件触发多个 ajax 请求。如果每个请求的 success 回调里都无条件地show()就会出现“后发的请求先回来先 show 了然后先发的请求回来又 show 一次”的情况导致显示的内容和当前筛选条件不匹配。解决这个问题的标准做法是请求标记。每次发请求前生成一个递增的 tokensuccess 回调里检查这个 token 是不是最新的不是就直接丢弃。var requestToken 0; function loadList(filter) { var currentToken requestToken; $(#resultList).hide(); requestAnimationFrame(function() { $.ajax({ url: /api/list, data: filter, success: function(data) { if (currentToken ! requestToken) return; // 丢弃过期响应 render(data); $(#resultList).show(); } }); }); }这个模式在实际项目里非常有用尤其是搜索框输入联想、筛选条件快速切换这类场景。不加 token 校验的话用户会看到内容“跳来跳去”体验极差。5.4 坑四rAF 在后台标签页被暂停导致请求一直不发前面提到过rAF 在页面不可见时会被暂停。如果你的业务逻辑依赖 rAF 来发请求而用户切到了其他标签页那么请求就会一直不发直到用户切回来。这在某些场景下是致命的比如一个需要定时刷新数据的看板页面。解决办法是加一个降级如果document.hidden为 true就直接用setTimeout或者立即发请求不走 rAF。function scheduleRequest(fn) { if (document.hidden) { setTimeout(fn, 0); } else { requestAnimationFrame(fn); } }这个封装在我后来的项目里成了标配既保证了前台页面的渲染时序又避免了后台页面请求被卡住。6. 一套可以直接抄作业的稳定写法6.1 封装一个通用的异步加载控制器把前面讲的要点整合起来我通常会封装一个小的工具函数处理“隐藏-请求-渲染-显示”这个完整流程。它内部自动处理时序、token 校验和后台降级。function createLoader(options) { var $container $(options.container); var requestToken 0; function schedule(fn) { if (document.hidden) { setTimeout(fn, 0); } else { requestAnimationFrame(fn); } } return { load: function(params) { var currentToken requestToken; $container.hide(); schedule(function() { $.ajax({ url: options.url, data: params, success: function(data) { if (currentToken ! requestToken) return; options.render($container, data); $container.show(); }, error: function() { if (currentToken ! requestToken) return; options.onError options.onError(); $container.show(); } }); }); } }; }用的时候只需要传入容器、接口地址和渲染函数var loader createLoader({ container: #resultList, url: /api/list, render: function($el, data) { $el.html(buildHtml(data)); } }); $(#filterBtn).on(click, function() { loader.load({ type: new }); });这套写法在我多个项目里跑下来很稳既保证了 hide 的视觉效果又避免了并发请求的内容错乱还兼顾了后台标签页的请求发送。6.2 几个参数和细节的调整建议requestAnimationFrame的降级阈值可以根据实际体验调整。如果发现某些设备上 rAF 的延迟感明显可以改成setTimeout(fn, 16)大约对齐一帧的时间。token 校验的粒度可以更细。如果同一个容器可能被多个不同的数据源更新可以给每个数据源单独维护 token而不是全局一个。错误处理里也要记得show()否则请求失败后容器一直隐藏用户会以为页面坏了。可以在 error 回调里显示一个错误提示或者恢复显示旧内容。6.3 什么时候不需要这套复杂逻辑如果你的场景是“点击后弹出一个模态框模态框里异步加载内容”那其实不需要这套逻辑。因为模态框的显示本身就是由点击触发的用户能看到模态框出现的过程里面的内容加载慢一点也可以用 loading 占位。这套逻辑真正适用的场景是同一个容器需要在旧内容和新内容之间切换且切换过程需要让用户感知到“旧内容消失了新内容正在来”。比如筛选列表、搜索联想、分页切换、Tab 切换等。7. 从渲染原理反推为什么这些方案能work7.1 宏任务、微任务与渲染帧的关系要彻底理解这些方案需要知道浏览器的事件循环里渲染帧是在宏任务之间插入的。一次事件循环大概是这样的执行一个宏任务比如一段 script清空微任务队列然后浏览器判断是否需要渲染如果需要就执行渲染然后进入下一个宏任务。setTimeout的回调是一个新的宏任务所以它会在当前宏任务和渲染之后执行。rAF 的回调则是在渲染之前执行但它的执行时机被安排在样式计算之后、绘制之前。强制重排是在当前宏任务里同步触发的它逼浏览器立即完成样式计算和布局但不一定立即绘制。理解了这些就能明白为什么setTimeout的渲染保证不如 rAF——因为setTimeout只是把回调放到了下一个宏任务但浏览器是否在中间插入渲染取决于浏览器的调度策略。而 rAF 是明确告诉浏览器“我要在下一帧渲染前做一件事”浏览器会优先保证这个时序。7.2 合成层与 CSS 过渡为什么不受 JS 阻塞CSS 过渡和动画之所以能在 JS 繁忙时依然流畅是因为它们可能被提升到合成层由合成线程独立处理不占用主线程。当你切换一个触发过渡的类名时浏览器会创建一个动画任务在合成线程上按时间轴推进即使主线程在跑复杂的 JS动画也不会卡。这也是为什么我推荐在允许过渡动画的场景优先用 CSS 方案。它把时序控制从 JS 层转移到了样式层从根本上避开了 JS 执行时机的问题。7.3 一个反直觉的结论有时候“慢一点”反而更好很多人追求“请求越快越好”但在 hide/show 这个场景里请求太快反而可能导致隐藏效果看不见。如果你确实希望用户感知到“正在加载”的过程可以在 hide 之后人为加一个最小显示时间比如至少让 loading 状态显示 200 毫秒。var startTime Date.now(); $container.hide(); schedule(function() { $.ajax({ url: options.url, success: function(data) { var elapsed Date.now() - startTime; var delay Math.max(0, 200 - elapsed); setTimeout(function() { options.render($container, data); $container.show(); }, delay); } }); });这个技巧在用户体验上很有价值尤其是当接口响应很快时避免内容“闪一下”就变了让用户有时间感知到状态切换。8. 我在实际项目里总结的几条经验第一条经验是不要迷信任何一种方案要根据场景组合使用。我在一个项目里同时用了 rAF 和 CSS 过渡容器整体用 rAF 控制显示隐藏的时序内部的列表项用 CSS 过渡做淡入效果。两者配合既保证了时序正确又有不错的视觉体验。第二条经验是把时序控制的逻辑封装起来不要散落在业务代码里。早期我每个请求都手写一遍hidesetTimeoutajaxshow后来发现一旦要调整策略比如从 setTimeout 换成 rAF要改几十处。封装成 loader 之后改一处就够了。第三条经验是多用浏览器开发者工具的性能面板去验证。不要凭感觉判断 hide 有没有生效录一段 performance看看 Layout 和 Paint 事件发生在什么时间点和你的 ajax 请求时间戳对比一下一目了然。我很多次以为代码没问题一录性能面板就发现渲染时机完全不对。第四条经验是关注移动端的表现。桌面浏览器性能好很多时序问题不明显。但在中低端手机上JS 执行慢、渲染帧率不稳定同样的代码可能表现完全不同。我在移动端项目里会把 rAF 的降级阈值调大并且尽量减少 success 回调里的同步操作。最后一条写注释说明为什么这么写。时序控制代码在别人看来往往很“奇怪”——为什么 hide 之后要加一个空的 setTimeout为什么读一下 offsetHeight如果不写注释后人很可能觉得这是冗余代码给删掉然后问题就复现了。我现在的习惯是凡是涉及时序控制的代码都加一行注释说明意图比如“强制重排确保 hide 在请求前生效”。这些经验没有什么高深的理论都是从一次次“为什么隐藏没生效”“为什么内容闪了一下”“为什么快速点击会错乱”这样的实际问题里攒出来的。ajax 请求中的 hide 和 show 看似简单但要把时序控制做稳确实需要对浏览器的渲染机制有基本的理解再加上一点封装和验证的习惯。