微信小程序position暗藏玄机：fixed定位用不好页面崩了

好，咱们今天就聊聊微信小程序里的position这个话题。说实话，这玩意儿刚出来那会儿，我第一反应是：不就是个定位属性嘛，CSS里早就有static、relative、absolute、fixed这些了，有什么好大惊小怪的？但真上手写了几个小程序之后，才发现这里头的水比想象中深。小程序那套渲染机制跟普通网页不一样，它用的是双线程架构，逻辑层和视图层分开跑，再加上那些自定义组件、原生组件，position一用不好，页面直接崩给你看。我有个朋友，第一次做小程序，贪图方便，给一个弹窗用了fixed定位，结果在安卓低端机上，弹窗直接跑偏到屏幕外面去了，用户点都点不到，气得他差点摔手机。这事儿听着好笑，但背后其实暴露了一个问题：小程序的position，不能光靠网页那套老经验来套。

先说最基础的static和relative吧。在小程序里，static是默认值，意思是元素按文档流正常排布，不受top、left这些属性影响。这跟网页没区别，但有个坑：小程序的视图层渲染是基于WXML的虚拟DOM，如果父容器没给明确的宽高，子元素用了relative，再配合margin或者padding，很容易出现高度塌陷。我见过一个案例，一个列表页，每项都用relative微调位置，结果整个列表高度乱跳，滑动起来一顿一顿的。后来排查半天，发现是relative的偏移量没算进父容器尺寸，导致虚拟DOM计算布局时出了偏差。解决办法？要么给父容器固定宽高，要么用flex布局代替relative微调。记住，在小程序里，relative更像一个“微操工具”，不是布局主力，能不用就别用，省得给自己挖坑。

再说absolute，这个在小程序里是个双刃剑。它脱离文档流，靠最近的非static父元素定位，听起来跟网页一样，但问题出在小程序的层级管理上。小程序里，自定义组件和原生组件（比如map、video、canvas）有独立的渲染层级，如果你给一个组件用了absolute，它的z-index很可能跟原生组件打架。举个例子，你在地图上覆盖一个绝对定位的弹窗，弹窗明明设置了z-index:999，但地图还是牢牢盖在上面。为啥？因为原生组件是独立渲染的，z-index对它无效。解决办法？要么用cover-view来覆盖原生组件，要么干脆别在原生组件上玩absolute，改用position:fixed加层级调整。我有个做活动小程序的客户，就因为这个bug，活动页面的弹窗死活显示不出来，用户以为没反应，转化率直接掉了30%。后来换成cover-view，才搞定。所以，用absolute前，先问自己：这附近有没有原生组件？有的话，换个思路。

fixed定位在小程序里更是重灾区。网页上的fixed是相对于视口固定的，滚动时纹丝不动。但在小程序里，fixed的参照物是“页面容器”，也就是那个可滚动的视图区域。如果你在一个scroll-view里用fixed，它不会固定在整个屏幕上，而是固定在scroll-view内部。这导致什么结果？很多开发者想做个底部导航栏，用fixed定位到底部，结果在scroll-view里一滚动，导航栏跟着跑了。更坑的是，不同手机的系统导航栏高度不一样，比如iPhone X那种刘海屏，底部还有安全区域，fixed定位如果不手动加padding-bottom，导航栏会被系统手势条挡住。我见过一个医疗小程序，预约按钮固定在底部，但安卓机没问题，iPhone上按钮直接被挡住一半，用户点都点不到。后来加了env(safe-area-inset-bottom)才解决。所以，用fixed前，一定先确认滚动容器是谁，再考虑安全区域。

sticky定位在小程序里算是个新朋友，微信从基础库2.4.0开始支持。它结合了relative和fixed的特点，在滚动到指定阈值前按正常流排布，超过阈值后固定在顶部或底部。这玩意儿在列表页的分组标题里特别好用，比如联系人列表的字母索引、电商页的分类导航。但有个问题：sticky在iOS和安卓上的表现不一致。我测过，iOS上sticky的阈值计算更灵敏，安卓有时候会延迟触发，导致标题粘性效果不连贯。还有一个性能坑：如果你在一个长列表里大量使用sticky，每次滚动都会触发重排，低端机直接卡成PPT。我有个做新闻资讯的朋友，用sticky做文章目录导航，结果在红米手机上滚动时，页面掉帧掉到怀疑人生。后来他们改成虚拟列表，才把性能救回来。所以，sticky是好用，但要控制数量，别滥用，否则用户体验会打折扣。

接下来聊聊position在小程序里的那些“潜规则”。比如，小程序里不支持position:inherit和position:initial，写了也没用，默认当static处理。还有，如果你用rpx做单位，配合position的top、left，要注意不同屏幕尺寸的适配。rpx是微信的响应式单位，但position的偏移量是基于父容器的，如果父容器用了百分比或固定px，rpx可能会算偏。我见过一个案例，一个弹窗用position:absolute，top和left用rpx，在iPhone 6上完美居中，但换成iPad mini上就偏到右边去了。后来改成用transform:translate(-50%, -50%)结合百分比，才解决问题。所以，用position时，单位选择要谨慎，别一股脑全用rpx，得看父容器的尺寸类型。

我想说，position在小程序里不是不能用，而是要用对场景。大多数时候，flex布局和grid布局能解决80%的定位问题，没必要非得用absolute或fixed去硬顶。比如，弹窗居中，用flex的justify-content和align-items就能轻松搞定，何必用absolute算半天偏移量？底部导航栏，用flex布局配合fixed定位，或者直接用tabBar组件，比手动写fixed安全得多。小程序的设计哲学是“轻量、高效”，position用得太重，反而违背了这个初衷。我身边那些做得好的小程序开发者，基本都遵循一个原则：能用布局解决的问题，绝不用定位；必须用定位时，一定先测试不同设备和场景。毕竟，用户不会管你用了什么技术，他们只关心页面稳不稳、顺不顺。