以下是对您提供的博文进行深度润色与结构重构后的技术博客正文。我已严格遵循您的全部要求：

• ✅彻底去除AI痕迹：语言自然、有节奏感，像一位实战经验丰富的前端工程师在分享踩坑心得；
• ✅摒弃模板化标题：无“引言/概述/总结”等程式化小节，全文以逻辑流驱动，层层递进；
• ✅内容有机融合：将规范原理、渲染机制、兼容策略、代码实践、调试经验交织叙述，不割裂；
• ✅强化人话表达与工程语感：加入设问、类比、经验判断（如“坦率说，这个值在真机上往往比文档写的高5px”）、真实场景痛点；
• ✅保留所有关键代码、表格、引用，并增强可读性与上下文解释；
• ✅结尾不写“总结”“展望”，而是在一个具象、有力的技术落点处自然收束，并轻量引导互动。

100vh为什么总在 iOS 上“抖一下”？——一位老前端的视口单位破壁手记

你有没有遇到过这样的场景：
刚上线一个全屏轮播页，设计师夸“沉浸感满分”，测试同学却发来一张截图——页面底部多出一根细长的滚动条，轻轻一滑，整个背景图“啪”地往上跳了一截；
又或者，在 iPhone 上打开弹窗遮罩层，手指还没松开，地址栏一缩，遮罩突然变矮，露出底下半截按钮……

这不是 bug，也不是 CSS 写错了。这是你在用100vh的那一刻，就悄悄签下的“与浏览器共担风险”的协议。

而这份协议的甲方，是 WebKit —— 它没告诉你，vh这个单位，其实根本不是“当前屏幕高度的 1%”，而是“当前 layout viewport 高度的 1%”。而这个 layout viewport，会随着用户手指滑动，自己偷偷长大、缩小。

你以为的vh，和浏览器算的vh，从来就不是一回事

我们习惯把“视口”想象成一块固定画布：手机竖着拿，就是 390×844；横着，就是 844×390。但浏览器不这么想。

它心里其实装着两套坐标系：

• Visual Viewport（可视视口）：你眼睛看到的那一块，随缩放、滚动实时变化，但高度相对稳定；
• Layout Viewport（布局视口）：CSS 盒模型计算用的“逻辑画布”，宽度常被设为 980px（为了兼容老站），而高度，会跟着地址栏一起呼吸。

📌 关键事实：100vh的数值，永远等于document.documentElement.