微信小程序原生组件层级难题：如何让Canvas在长列表滚动中“听话”

1. 问题根源：为什么Canvas在滚动列表里“不听话”？

很多刚开始做微信小程序的朋友，尤其是想实现那种类似淘宝商品详情页效果的朋友，都会遇到一个让人头疼的问题：你精心设计了一个长页面，里面包含了商品图、评价、详情，顶部还有个吸顶的导航栏，点击就能快速跳转到对应区域。为了实现滚动，你很自然地用上了 scroll-view 组件。但当你兴冲冲地把图表、签名板或者游戏画面（这些通常用 Canvas 画布实现）放进列表里时，诡异的事情发生了——页面在滚动，但 Canvas 就像被胶水粘在了屏幕上一样，一动不动，或者出现奇怪的闪烁、遮挡。

我第一次遇到这个问题时，也折腾了好久，以为是自己的样式写错了，或者 z-index 没设对。后来才明白，这根本不是咱们代码的“锅”，而是微信小程序底层架构的一个特性。简单来说，Canvas、Video、Live-Player 等组件，属于“原生组件”。它们是由微信客户端直接创建和渲染的，而不是像普通的 view、text 那样，由小程序框架（WebView）来渲染。

你可以把小程序页面想象成一个两层结构：底层是 WebView 层，负责渲染我们写的绝大部分视图（HTML 结构）；顶层是原生组件层，像一个透明的玻璃板盖在上面，上面绘制着 Canvas 等内容。这个“玻璃板”的层级是最高的，它会始终浮在 WebView 层之上。这就导致了几个核心矛盾：

1. 无法被普通视图覆盖：你想在 Canvas 上放一个弹窗、一个提示框？除非这个弹窗也是原生组件（比如 cover-view），否则它会被 Canvas 压在下面，根本显示不出来。
2. 无法跟随 scroll-view 正常滚动：scroll-view 的滚动，是 WebView 层内部的滚动。而浮在上层的原生组件 Canvas，它的位置是相对于整个屏幕窗口（viewport）来定位的，它不参与 WebView 内部的布局流。所以当 scroll-view 的内容滚动时，Canvas 不会跟着动，看起来就像 position: fixed 固定在了屏幕上。
3. CSS 样式支持有限：很多我们熟悉的 CSS 动画、overflow: hidden、box-shadow 等效果，在原生组件上可能无效或表现异常。

微信官方文档其实明确指出了这一点：原生组件不能嵌套在 scroll-view、swiper、picker-view、movable-view 这些可滚动或可移动的组件中。所以，当你发现 Canvas 不跟随滚动时，首先应该意识到，你当前的实现方案从根上就与小程序的设计机制冲突了。网上流传的一些方法，比如在 scroll-view 上设置 disable-scroll="true"，或者给 Canvas 加一些特定的属性，其实都是治标不治本，甚至完全无效，因为它们没有触及“原生组件层级最高且独立于滚动容器”这个本质。

那么，需求摆在眼前：我们既需要长列表滚动的流畅体验，又需要在列表的某个部分展示 Canvas 图表或图形，并且还要实现精准的锚点跳转（就像点顶部导航跳到“评价”区域）。这条路被 scroll-view 堵死了，我们该怎么办？答案是：换一条路走，放弃 scroll-view，拥抱页面的全局滚动。

2. 核心思路：弃用Scroll-View，拥抱页面级滚动

既然 scroll-view 是问题的根源，那最直接的解决方案就是不用它。听起来好像有点因噎废食，但仔细想想，我们真的非用 scroll-view 不可吗？scroll-view 的核心作用是提供一个局部的、可控的滚动区域。但像商品详情页这种需要全屏滚动的长列表，微信小程序的页面本身（Page）就自带滚动能力啊！

没错，微信小程序的页面默认就是可以滚动的，只要内容高度超过了屏幕高度。这种滚动是页面级的，是整个 WebView 的滚动。而原生组件 Canvas 在页面级滚动中，表现是正常的！因为它虽然层级最高，但它的定位基准是整个页面容器。当页面整体滚动时，Canvas 会跟随其父容器在页面中的位置一起移动。

所以，我们的战略转移非常明确：

1. 拆除 scroll-view：将长列表的所有内容（包括 Canvas 部分）直接放在页面的根节点下，或者一个普通的 view