一个做环保工程的客户反馈了个玄学问题：他们官网在iPhone上打开，首屏底部的查看产品按钮时有时无——有时完整显示，往下滑一点再回来，按钮就剩半个，好像网站在跟他捉迷藏。开发查了两天没头绪，最后发现是视口高度的老坑：页面按满屏视口高度定首屏，而手机浏览器的视口高度本身是变化的。
地址栏是个不稳定因素
手机浏览器的地址栏会收起和展开，视口高度随之上下浮动几十到一百像素。代码里用满视口高度这类写法时，拿到的值在不同时刻不一样：地址栏展开时算出来的高度小，收起后变大，页面内容就跟着跳。做响应式网站设计，电脑上永远遇不到这个问题，因为没有地址栏收放这回事，所以它成了专门坑移动端的老演员。老演员的戏码年年上演，因为每年都有新团队第一次做移动端。
哪些布局容易中招
- 满屏首屏：首屏高度定成视口高度，底部按钮和文案的位置就随地址栏漂移；
- 弹窗内滚动：弹层高度按视口算，内容多的时候底部按钮被地址栏盖住，点不到提交；
- 固定背景区块：高度跟着视口变，滚动时区块之间出现缝隙或重叠。
稳妥的做法是换更可靠的参照：用最小可用高度代替精确满屏，或者用现代CSS提供的动态视口单位，让浏览器在地址栏变化时给一个稳定的值。再配合一个兜底思路——首屏重要按钮别钉死在屏幕最底边，往上留一段缓冲，地址栏怎么动都不影响它可见。几行代码的事，但得有人想到。想到的前提是踩过，没踩过的团队连这个坑的存在都不知道。
验证方法很简单
用苹果手机打开网站，从页面顶部往下滑再收回来，反复几次，观察首屏元素有没有跳动、底部按钮是否始终可见；再用Safari打开一个内容较长的弹窗，看提交按钮能不能点到。要是按钮会随地址栏跳动，问题就坐实了。两分钟测完。安卓的Chrome也有类似机制，顺手一起测。发现问题的，让技术改用动态视口单位，一般半小时的活。
建议把Safari滚动测试写进验收动作，苹果用户在海外客户里占比高，这关不能省。测试时用Safari，别用套壳浏览器替身，测不准。需求沟通时可以直接点破这个坑，看对方接不接得住，接得住的团队才让人放心。比格网络做响应式网站设计，这类高度陷阱都有标准写法规避——经验的价值就在于，客户还没踩到，坑已经填平了。这种填坑的能力，只能靠项目数量的积累，选团队时值得多问一句。
