在 Next.js App Router 的日常开发中，有一个令人颇为困扰的异常现象——当服务端执行 `redirect()` 跳转后，目标页面竟然无法正常滚动。没错，页面已经渲染完成，内容也完整显示，但垂直滚动条仿佛凭空消失。这个问题在 Next.js 13.5.4 版本中尤为突出。 先给出结论：该问题的根本原因在于，Next.js 为了优化页面过渡动画的效果，在服务端跳转过程中，会临时将页面 `` 的 `overflow` 属性设置为 `hidden`，以避免页面切换时出现滚动条抖动。但关键在于，**这个状态并未被正确恢复**，导致目标页面渲染完成后，`document.body.style.overflow` 始终卡在 `'hidden'`，只有手动刷新页面才能恢复正常。这显然是一个状态残留的 Bug。 那么，如何在不改动业务逻辑的前提下，安全地修复此问题？核心思路非常简单：在目标页面的客户端组件中，利用 `useEffect` 主动将滚动能力“抢回”，并确保组件卸载时做好善后处理。 来看具体的代码实现： ```typescript 'use client'; import { useEffect } from 'react'; export default function ScrollFixPage() { useEffect(() => { // 保存原始 overflow 值（兼容内联样式与 CSS reset） const originalOverflow = document.body.style.overflow; // 强制启用滚动 document.body.style.overflow = 'auto'; // 清理函数：组件卸载时恢复原始值（避免影响其他路由或全局状态） return () => { document.body.style.overflow = originalOverflow; }; }, []); return (

滚动已恢复

{[...Array(50)].map((_, i) => (

第 {i + 1} 行内容 — 现在可以正常滚动查看全部内容

))}

); } ``` 这里的逻辑其实相当巧妙：先保存当前 `overflow` 的值，哪怕它只是从父级 CSS 继承来的空字符串，也要原封不动地记录下来。随后直接覆盖为 `'auto'`，强制开启滚动。当组件卸载时，再恢复成原先的“空”值。这样一来，既解决了跳转后的滚动失灵问题，又不会干扰其他需要禁用滚动的场景，比如模态框、抽屉组件等。 有几个关键点需要特别注意： 第一，**这个逻辑一定要放在 Client Component 里**，顶部别忘了加 `'use client';`。服务端组件根本拿不到 `document` 对象，写了也白搭。 第二，**不要图省事，直接在全局布局（如 _app.tsx）中覆盖 body 的 overflow**。这会把模态框、弹窗等需要临时禁用滚动的逻辑全部破坏，属于典型的“为了修一个 Bug，引入十个 Bug”。 第三，如果项目里使用了 `@next/font` 或自定义了 body 样式，最好顺手检查一下是否有 CSS 规则意外覆盖了 `overflow`。不过根据当前问题的现象（刷新后正常，滚动失灵只在跳转后出现），这个问题与 CSS 无关，完全是 Next.js 内部逻辑的锅。 最后，Next.js 官方其实已经在后续版本（≥14.2）中优化了这个行为，**升级版本是最推荐的长期解决方案**。但如果你像大多数人一样，项目暂时卡在 13.4 到 14.1 之间，上面这个 `useEffect` 方案是经过验证、稳定可靠的“补丁”。通过精准地控制副作用生命周期，它既即时修复了滚动异常，又保障了页面切换和组件复用时的样式一致性，是生产环境里值得推荐的标准做法。