当 CSS Grid 容器内元素被选中时，父容器虽设置了 max-height 和 overflow-y: auto，页面仍发生非预期的全局滚动，根源常在于 scrollIntoView 行为或 height/max-height 计算异常；本文提供稳定、语义清晰的修复方案。
当 css grid 容器内元素被选中时，父容器虽设置了 `max-height` 和 `overflow-y: auto`，页面仍发生非预期的全局滚动，根源常在于 `scrollintoview` 行为或 `height`/`max-height` 计算异常；本文提供稳定、语义清晰的修复方案。
在使用 CSS Grid 构建响应式网格（如 grid-template-columns: repeat(auto-fill, minmax(70px, 1fr)))）时，若其父容器设置了固定高度限制（如 max-height: 350px; overflow-y: auto;），常会遇到一个隐蔽但高频的问题：用户滚动至底部并交互（如点击选中）某个网格项后，整个页面突然向下滚动——即使该交互本应仅影响局部滚动容器。
这一现象的本质并非 Grid 布局本身缺陷，而是浏览器在处理焦点切换或 DOM 更新时，隐式触发了 element.scrollIntoView() 行为（尤其在可聚焦元素上），而由于父容器高度受限且未明确约束其视口定位上下文，浏览器会“向上追溯”至 <body> 或 <html>，最终导致整页滚动。
常见误解是归因于 minmax() 或 auto-fill 的计算逻辑，但实际调试（如您在 Heroku 示例中通过禁用 -webkit-fill-available 触发问题）表明：关键症结在于 <body> 元素未被明确设为定位上下文，导致滚动锚点失控。
✅ 推荐解决方案（稳定、跨浏览器、无副作用）：
立即学习“前端免费学习笔记（深入）”；
body {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
overflow: auto; /* 保持原有滚动能力 */
}⚠️ 注意事项：
- position: fixed 会使 <body> 脱离文档流，因此需显式设置 top: 0; left: 0; width: 100%; height: 100% 以覆盖视口；
- 原有页面滚动行为将由 <body> 承担（而非 <html>），确保 overflow: auto 保留主滚动条；
- 若页面中存在 transform、filter 等创建新层叠上下文的属性，需确认其不干扰 body 的定位层级；
- 避免与 scroll-behavior: smooth 冲突——如需平滑滚动，请统一在 <body> 上定义。
❌ 不推荐的临时方案：
- max-height: -webkit-fill-available：属 WebKit 私有值，无标准支持，嵌入 iframe 或跨平台时行为不可控；
- scroll-margin-top 或 focus-visible 伪类微调：仅缓解表象，无法根治滚动锚点溯源问题；
- 移除 tabindex 或禁用焦点：牺牲可访问性，违背 WCAG 原则。
? 进阶建议：
若项目已使用现代框架（React/Vue），可在交互逻辑中主动阻止默认滚动行为：
gridItem.addEventListener('click', (e) => {
e.preventDefault();
// 手动聚焦并抑制 scrollIntoView
item.focus({ preventScroll: true });
});综上，body { position: fixed } 并非“取巧”，而是通过确立明确的滚动容器边界，从根本上切断浏览器向上回溯滚动锚点的路径。它简洁、可靠、兼容性强，是解决 CSS Grid 引发全局滚动问题的工程级最佳实践。
