企业官网建设流程全解析

做UniApp开发的人，早晚都会和scroll-view碰面。这个组件看起来人畜无害，不过是在页面上划出一块区域，让它能上下滑动。可真要在项目里用它，你会发现高度怎么设都不对、滚着滚着事件疯狂触发、列表稍微长一点帧率掉得厉害，这些问题我在电商列表、客服聊天、评论楼中楼、目录导航这些场景里全部踩过。这篇就把我实际用过的一套UniApp scroll-view上下滑动方案完整整理出来，从最基础的高度设置讲到长列表性能优化，再聊高频踩坑点和几个进阶玩法，争取让后来的人少走几条弯路。

1. 先想清楚：整页滚动和scroll-view滚动到底该选谁

很多新手上来就写scroll-view，理由很简单：“列表要滚动”。可页面本身就能滚动，为什么不直接渲染？我在带新人的时候发现，这是第一个容易搞混的地方。

1.1 两种滚动方式的核心差异

页面滚动是天然的，内容超过屏幕，page自己就会滚。而scroll-view是固定一个容器高度，让容器里的内容滚动，容器本身不动。最直观的区别是：页面滚动时，页面的标题、导航、底部tab可以一起滚走；而scroll-view滚动时，容器外的东西固定不动。

了解这个差异，后面的坑基本能避开一半。scroll-view解决的是“局部滚动”问题，不是“页面滚动”问题，搞清楚归属，才不会在一开始把架构做歪。

1.2 什么样的业务场景必须用scroll-view

我归纳了五个必用scroll-view的高频场景：

• 上下分栏页面：顶部是筛选栏、搜索框，下方是长列表，筛选栏需要固定不滚走。
• tab切换加内容区滚动：左侧是分类导航，右侧是商品/文章列表，两侧分别滚动并联动。
• 聊天消息列表：需要精确滚到某一条，或者新消息自动定位到底部。
• 需要监听滚动距离做联动：比如滚动超过一定高度显示“回到顶部”按钮，或者侧边字母导航实时高亮。
• 表单长页：提交按钮固定在底部，中间输入区域独立滚动，避免键盘和按钮打架。

这些场景共同点都是“局部滚动+外部固定”，用页面滚动实现会很别扭。反过来说，如果页面就是单纯一长条内容从上滚到下，那直接用页面滚动就行，硬套scroll-view反而增加复杂度。

2. 基础玩法：先把一个能滚动的scroll-view跑起来

基础部分看着简单，但我在写基础组件的教学代码时，收到的反馈里频率最高的就是“我写了scroll-view但就是滚不动”。所以这一章不只要给代码，更重要的是把滚动的前提条件讲明白。

2.1 最小可用写法

下面这个结构就是最简的上下滚动容器：

<view class="page"> <scroll-view class="list-scroll" scroll-y> <view class="item" v-for="item in list" :key="item.id"> <!-- 列表内容 --> </view> </scroll-view> </view>

.page { height: 100vh; overflow: hidden; } .list-scroll { height: 100vh; }

scroll-y这个属性表示允许纵向滚动，还有一个scroll-x表示横向滚动。这里有个细节：scroll-y和scroll-x同时写成true时，两个方向都能滚，但很多情况下会影响手势判断，建议一个scroll-view只负责一个方向，除非你有明确的二维滑动需求。

scroll-view的滚动本质是靠自身overflow: scroll实现的。内容超出容器高度，才会产生滚动。所以有一个硬前提：scroll-view容器必须有确定的高度，而且内部内容高度必须超过容器高度。这两个条件缺一个，它都不可能滚起来。

2.2 高度是最大的坑：三种可靠的高度方案

我自己踩过最深的一个坑就是高度。一开始写业务代码，习惯性给scroll-view一个width，然后发现它纹丝不动。后来才意识到，没有高度就相当于这个容器被内容撑开，内容多高它多高，overflow根本不会生效。所以给scroll-view设置高度是第一步，也是排查滚动失效问题的第一顺位。

方案一：固定px或rpx高度。适合内容量可控、页面结构固定的场景，比如聊天弹窗里的消息列表，就给一个height: 600rpx。简单直接，缺点是屏幕适配差一点，不同手机上可视区域大小不一样。

方案二：calc计算高度。顶部和底部区域高度固定时，可以用：

.list-scroll { height: calc(100vh - 50px - 60px); }

这个50px是顶部标题栏，60px是底部操作栏，中间剩下的部分全部给滚动容器。小程序的导航栏和tabbar高度在不同机型上不一致，calc里的数值最好通过uni.getSystemInfoSync拿到实际高度再动态设置。

方案三：flex布局撑满。这是我最推荐的方式，适配性最好：

<view class="page"> <view class="header">固定头部</view> <scroll-view class="list-scroll" scroll-y> <view v-for="item in list" :key="item.id">{{ item.name }}</view> </scroll-view> <view class="footer">固定底部</view> </view>

.page { display: flex; flex-direction: column; height: 100vh; overflow: hidden; } .list-scroll { flex: 1; overflow: hidden; }

父容器flex列布局，header和footer高度自适应，scroll-view用flex: 1填充剩余空间。注意一个细节：部分安卓webview里，flex: 1的子元素scroll-view可能计算不出高度，这时候给它加一个min-height: 0能解决大多数情况。

提示：在App端、小程序端和H5端，height: 100%这样的写法表现不完全一致，父级没有明确高度时100%会失效。如果你发现H5上滚得好好的，真机上不滚，先检查父容器高度。

2.3 滚动事件与加载状态管理

scroll-view提供了三个最常用事件：

• @scroll：滚动过程中持续触发，返回event.detail.scrollTop等位置信息。
• @scrolltolower：滚动到底部时触发，可以配合lower-threshold设置触发距离。
• @scrolltoupper：滚动到顶部时触发，对应upper-threshold。

触底加载更多是长列表最基础的需求，标准写法可以这样搭：

<scroll-view scroll-y class="list-scroll" @scrolltolower="loadMore" lower-threshold="80" > <view class="item" v-for="item in list" :key="item.id">{{ item.name }}</view> <view class="list-footer"> {{ loading ? '加载中...' : (hasMore ? '上拉加载更多' : '已经到底啦') }} </view> </scroll-view>

data() { return { list: [], page: 1, pageSize: 20, loading: false, hasMore: true }; }, methods: { async loadMore() { if (this.loading || !this.hasMore) return; this.loading = true; try { const res = await getList({ page: this.page, pageSize: this.pageSize }); if (res.list.length < this.pageSize) this.hasMore = false; this.list = this.list.concat(res.list); this.page += 1; } finally { this.loading = false; } } }

这里有两个我反复强调的点：一是loading标志必须要，防止scrolltolower在触底停留时重复触发；二是loading状态要在finally里复位，否则接口报错后所有加载都卡死。

关于scroll-top和scroll-into-view，这两个属性是用来控制滚动位置的。用的时候会踩到一个复位问题：假如你设置scroll-top为100，页面滚上去之后，想再用scroll-top=100滚一次，因为值没变，视图可能不会重新执行。正确做法是先把scroll-top改为0，再在nextTick里把目标值赋进去，或者用一个随机的小差值做“激活”。我在App端测试时，这个复位操作比小程序更敏感，建议统一按“先置0再赋值”处理。

3. 长列表性能：scroll-view流畅滚动的关键

基础能滚了，接下来就是长列表。很多人做完基础功能，一上真机数据量一大就卡，然后就跑来问“scroll-view是不是不行”。其实scroll-view本身只是一个容器，性能问题主要出在数据渲染和事件处理上。

3.1 卡顿的根源先说透

长列表卡顿几乎都逃不开这三个原因：

第一，DOM节点数量失控。以一条商品数据为例，图片、标题、价格、标签加起来可能有二十多个节点，100条数据就是两千多个节点。小程序的渲染架构里，这些节点越多，首次渲染和后续更新的耗时越长。

第二，滚动事件里频繁setData。很多人喜欢在@scroll里实时更新某个状态，比如“已滚动高度XXpx”。要知道@scroll是高频事件，每滚动一帧都可能触发，你在里面做setData就等于每一帧都触发一次视图刷新，不卡才怪。

第三，图片资源太重。列表里的图片如果不做懒加载、不做尺寸裁切，低端机上滚动时图片解码会抢占大量资源。

我常用一个类比：长列表就好比一个快递站，货架上堆了全城的包裹，分拣员每次搬一个包裹还要顺便清点整面货架，工作量当然大。优化思路无非是减少货架上的货（分页/虚拟列表），以及减少分拣员的重复劳动（节流/避免频繁setData）。

3.2 分页加载标准方案

分页加载是最直接的优化手段，核心思路是“控制同时渲染的数据量”。不要一次性把所有数据全塞进列表，而是每页加载20到30条，滚动到底部再请求下一页。

前面2.3里已经给了基础代码，这里补充两个经验：

一是pageSize不要贪大。20条对大多数场景都合适，图片较多的场景可以降到10条。一次性塞50条上去，真机上滑动依然会有肉眼可见的掉帧。

二是在列表底部放一个状态footer。这个footer既能让用户看到加载状态，也能填充底部空间，避免最后一屏内容不足时scrolltolower被疯狂触发。

3.3 数据量太大时的进阶选择：虚拟列表

分页能解决大多数问题，但有一种场景分页不好使：聊天记录、长文档目录、几百条消息要一次性展示。这时候就得考虑虚拟列表。

虚拟列表的原理一句话概括：只渲染可视区域内的节点，外加一点缓冲区域，滚出视口的节点直接销毁。它和分页的区别是，分页是数据层面的分批加载，虚拟列表是渲染层面的按需渲染。

UniApp生态里可以直接用uitable-view这类社区方案，也可以自己用scroll事件计算startIndex和endIndex。自己实现时核心是算法：根据scrollTop除以每条item高度算出起始下标，再根据可视高度算出结束下标，然后只渲染这一段数据。注意每条item高度必须一致，或者用预估高度加补偿，否则滚动到后半段会错位。

补充一句，如果你的项目是nvue或者最新的UniApp X，App端有更好的原生list组件可选，滚动性能比webview里的scroll-view好不少，适合对性能要求极高的场景。但考虑到跨端一致性，大量项目仍然以scroll-view为主，所以掌握好这套优化手段是通用的基本功。

3.4 给小程序减负：从2MB分包说起

有一个很真实的热门报错：source size 2612kb exceed max limit 2mb。做长列表页面时特别容易踩到，因为这个页面通常会绑一堆组件、工具函数和依赖库。

解决思路是分包。小程序主包建议只留tabBar页面和公共基础代码，复杂的长列表模块放进分包，按需加载。manifest.json所在的src目录下，在app.json的subPackages里配置：

{ "subPackages": [ { "root": "pagesList", "pages": [ { "path": "list", "style": { "navigationBarTitleText": "长列表" } } ] } ] }

分包之后，访问pagesList/list这个路径时才会加载对应代码，主包体积压力一下就小很多。

另外，不要在列表页顶部import一个完整的UI框架或者巨型SDK。按需引用组件库里的单个组件，比整包引进来得稳。我见过一个项目，页面里只用了三个UI组件，却引入了整个组件库，最后超2MB，把UI库改成按需引入后直接降到900KB。这是长列表项目最容易忽视的“隐形体积杀手”。

3.5 图片渲染细节：别让图片拖垮滚动

列表里图片多的时候，有几个经验值得落地：

• image组件加上lazy-load属性，小程序里能实现图片进入视口附近才加载。
• 提前固定图片宽高比。图片没有固定尺寸时，加载完成后容器高度会跳变，导致滚动位置漂移，用户会感觉列表“一抖一抖的”。
• 图片地址尽量用服务端裁剪后的尺寸，比如列表宽度375px就传375宽，不要直接给原图。原图动辄几MB，滚动时解码卡顿非常明显。
• 在App端，图片缓存策略和webview的滚动性能相关，可以开启图片的缓存模式，某些平台还能用css的transform: translateZ(0)改善滚动时的合成层性能。

4. 避坑实录：这些高频问题我帮你踩过了

这一章全是实战中高频出现的问题。网上很多教程只讲API，出了问题还得自己排查，这里我直接按“现象+原因+解法”整理出来。

4.1 滚动不起来的排查顺序

收到“scroll-view滚不动”的反馈太多了，我现在排查都是按顺序来：

1. 容器有没有高度：没有高度是头号原因，尤其是把scroll-view放在普通view里没设任何高度。
2. 父级flex布局是否把高度压缩了：flex容器里如果不给scroll-view设flex: 1，它的高度可能只有内容高度。
3. scroll-y是否写对：写成scroll-x或者漏掉属性，纵向当然滚不了。
4. 内容高度是否真的超过容器：内容还没容器高是滚不起来的，新手测试时先塞满几十条假数据。
5. 有没有样式冲突：比如外层view存在overflow: hidden且高度不足，把scroll-view裁剪掉了。

还有一个不太容易发现的问题：scroll-view内容超出后，page页面也被撑开，导致整个页面一起滚。这种情况基本可以断定是scroll-view高度没固定，内容把父级撑开了。解决办法是给外层view加固定高度和overflow: hidden，让高度控制在scroll-view自身。

4.2 嵌套滚动与手势冲突

滚动嵌套是个大坑，我踩过两种典型情况。

第一种是scroll-view内部再放一个scroll-view，常见于商品卡片里包含横向滚动标签。手势识别容易出问题：竖向滑动时页面应该竖向滚，但手指稍微偏一点，内层横向scroll-view就开始抢手势。处理方式：内层横向滚动用swiper组件替代，swiper对横向滑动的处理更成熟；如果一定要用嵌套scroll-view，给内层加catchtouchmove阻止冒泡，但别一上来就catch，会连带把竖向滚动手势也禁掉。

第二种是page滚动和scroll-view滚动同时发生。页面高度100%可以滚动，scroll-view又设置了高度，这时候在scroll-view区域内滑动，效果可能正常，但区域外也就是页面底部残留内容也能滚，体验很割裂。我的习惯是：一个页面只保留一条滚动链。要么整页交给page滚动，要么把整页结构都放进scroll-view，不要混着用。

4.3 scroll-into-view定位的坑

scroll-into-view的语法不难，但它有三个很隐蔽的坑。

第一，传入的值是子元素的id，不带#号。很多人写惯了CSS选择器，下意识传“#item-1”，结果滚不动。

第二，id必须是字母开头，不能用纯数字。这是标签id的标准约束，但业务上我们经常用数字id，需要拼一个字符串前缀。

第三，动态渲染时节点还没创建。比如左侧分类点击后，右侧列表数据还在请求，你立刻设置scroll-into-view，此时目标节点还没存在，指令自然失效。稳妥做法是数据渲染完成后，用setTimeout延迟几十毫秒再赋值。

一个典型场景：地址选择列表右侧有字母导航，点击字母滚动到对应区域：

<scroll-view scroll-y class="list-scroll" :scroll-into-view="scrollIntoId" scroll-with-animation > <view class="section" :id="'section-' + item.key" v-for="item in sections" :key="item.key" > {{ item.title }} </view> </scroll-view>

methods: { scrollToSection(key) { this.scrollIntoId = ''; this.$nextTick(() => { this.scrollIntoId = 'section-' + key; }); } }

先置空再赋值，是一个可靠的小技巧。如果直接赋值，第二次点击同一个字母时会因为值相同而不生效。

4.4 iOS安全区、tabbar与键盘顶起

iPhone X等机型底部有home条，如果scroll-view的高度一直延伸到底部，列表最后一条内容会被遮挡。适配方式是在滚动容器内部加安全区padding：

.list-scroll { padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom); }

对应已下线的旧iOS版本用constant，新版本用env，两个一起写兼容性最好。

再说一个很常见的现象：页面底部有tabbar，scroll-view里放了input输入框，键盘弹起时整个页面被顶起，tabbar被推到键盘上方，看起来非常奇怪。这是小程序里“tabbar输入法顶起”类问题的常见表现。

处理思路有几个：

• 给input或textarea设置adjust-position为false，禁止页面自动上推。
• 手动监听键盘高度变化，动态调整scroll-view底部padding，给键盘留出空间。
• 把输入框放回页面非滚动区域，避免和滚动容器抢地盘。

另外，iOS上点击状态栏回到顶部这个能力是自带的行为，scroll-view如果想支持，需要设置enable-back-to-top属性，同时页面不能在自定义导航模式下。这个细节很多人在调试时不注意，点状态栏没有反应才过来查。

5. 进阶实战：滚动场景的几个高性价比玩法

基础性能和避坑都到位之后，滚动场景还能玩出很多花样。这里挑几个我做项目时反复用到的方案，代码量不大，但对体验提升非常明显。

5.1 回到顶部按钮

滚动距离超过一定阈值时显示“回到顶部”按钮，点击平滑滚回顶部。这个需求的难点不是按钮本身，而是滚动监听的高频处理。

data() { return { showTopBtn: false, scrollTop: 0 }; }, methods: { onScroll(e) { const top = e.detail.scrollTop; // 节流，只在跨过阈值时更新状态 if (!this.showTopBtn && top > 500) { this.showTopBtn = true; } else if (this.showTopBtn && top <= 500) { this.showTopBtn = false; } }, backToTop() { this.scrollTop = 0; } }

注意这里我没有在每次滚动时都setData，只在跨越500px阈值时更新一次，这样性能开销非常小。如果直接每次滚动都setData，真机上滚动会明显变卡。

5.2 侧边导航与列表滚动联动

电商分类页很经典：左侧是一级分类，右侧是商品列表。右侧滚到哪个区域，左侧高亮对应项；点击左侧，右侧滚动到对应区域。

实现思路有两套。

第一套：监听右侧scroll-view的@scroll，通过scrollTop和各区块累计高度判断当前区域，更新左侧高亮索引。这里要注意，各区块高度需要实时计算，图片未加载完时高度会变，判断会有误差，比较稳妥的方式是给每个区块显式的高度或者等待图片加载完成后再计算。

第二套：反方向，不监听滚动，只在点击左侧时用scroll-into-view定位右侧。这套实现简单，但缺少“滚动时高亮联动”，体验不够完整。

我常用的组合是：右侧滚动监听判断高亮，左侧点击用scroll-into-view反向定位。两者互补，能实现双向联动。注意联动状态要加锁，避免用户手动滚动时点击左侧，两侧数据互相纠正导致抖动。

5.3 聊天消息列表：保持底部与历史定位

聊天列表和普通商品列表最大的区别是：新消息进来要自动滚到底部，但用户往上翻历史消息时又不能强制拉回底部。

我常用的方案如下：

scrollToBottom() { this.$nextTick(() => { this.scrollTop = this.messageList.length * 200; }); }, onScroll(e) { // 记录用户是否主动上滑 this.isUserScrollingUp = e.detail.scrollTop < this.lastScrollTop; this.lastScrollTop = e.detail.scrollTop; }

新消息到达时，如果isUserScrollingUp为false，说明用户在底部附近，就调用scrollToBottom；如果用户正在上翻，先不打断，等用户滚到底部附近再自动吸底。这个交互细节做好之后，聊天体验会顺滑很多，很多初版聊天功能就是没注意这一点，新消息一到就把用户视角抢走了。

消息列表的scroll-top值没有固定上限，只要足够大就能滚到底。不同平台对超大scroll-top值的处理不一样，我习惯用列表条数乘以一个预估行高来计算，虽然不能精确到底，但用户看到最后一条消息附近就够了。

5.4 长列表里的图片预览

长列表里点击图片放大预览，这个需求非常高频。UniApp有现成的uni.previewImage，不需要自己写弹层：

previewImage(currentIndex) { const urls = this.imageList.map((item) => item.url); uni.previewImage({ current: currentIndex, urls }); }

在scroll-view里用这个API要注意一点：如果列表很长，图片很多，一次性传入全部urls在部分低端机上预览会卡。稳妥做法是只传当前页的图片地址，预览器本身支持左右滑动切换当前列表里的图片，跨页预览的场景极少用到，可以不做。

5.5 把列表项抽成组件

最后一个是工程层面的建议。在长列表场景里，不要把所有节点全写在页面里，至少把列表项抽成一个独立组件。组件化带来的好处至少有两个：一是页面结构清爽，改item样式不用在几百行模板里找；二是小程序的分包和渲染优化对组件化更友好，局部更新时组件级别的diff成本低于整页大模板。

组件里注意数据传递方式，尽量用单向数据流，复杂列表项通过props传入数据对象，内部事件通过emit抛给父级，避免在组件内直接修改列表源数据。这个习惯养成之后，滚动列表和后续的排序筛选需求都会好维护很多。

最后的一点实在话

我个人的体会是，scroll-view本身并不复杂，真正麻烦的是它背后的“滚动场景管理”。高度有没有给够、数据有没有分页、滚动事件有没有节流、定位指令有没有复位、键盘和安全区有没有适配，这些细节在真实项目里往往是同时出现的，不会等你一个个慢慢试。踩过几次坑之后，我现在接手任何滚动需求都会先按上面这套框架自查一遍：先定滚动边界，再控制数据量，最后才写事件逻辑。按这个顺序来，大部分滚动问题都能提前消灭在开发阶段，而不是等测试拿着真机来找你。