微信小程序星星评分组件：半颗星展示与交互全解析

1. 评分展示这件事，远比你想的要细

做微信小程序开发这些年，我接过不少看起来"简单"的需求，星星评分展示绝对算一个。产品经理拿着原型图过来，说"就一个五星评分，用户点一下打分，展示的时候支持半颗星"，听起来十分钟能搞定的事，实际动手才发现坑一个接一个。半颗星怎么渲染？用图片还是字体图标？用户点击时怎么判断点到了第几颗星、是整颗还是半颗？展示态和交互态怎么复用？评分数据从后端拿到的是4.3分，前端怎么把它拆成"四颗满星加一颗半星"？这些问题不提前想清楚，写出来的代码就是一堆硬编码的坐标判断，改一个需求要动全身。

这篇文章我想把"微信小程序星星评分展示、半颗星展示"这个主题彻底讲透。不管你是刚接触小程序的新手，还是做过几个项目但每次写评分都要重新查资料的老手，都能从这里拿到可以直接抄作业的方案。我会从整体设计思路讲起，把图片方案、字体图标方案、纯CSS方案各自的取舍说清楚，然后深入到半颗星的三种主流实现方式，再给出完整的交互逻辑和数据结构设计，最后把我踩过的坑和排查技巧整理成速查表。核心关键词就三个：微信小程序、星星评分、半颗星展示，全文围绕它们展开，不跑偏。

先说清楚这个功能到底解决什么问题。评分组件在电商、外卖、内容社区、服务评价里几乎无处不在，用户需要快速给出一个分数，同时也要能直观看到别人给出的平均分。整颗星好办，难的是半颗星——因为真实世界的平均分很少是整数，4.7分、3.2分这种才是常态。如果只支持整颗星，要么四舍五入丢失精度，要么显示得很难看。所以半颗星展示不是锦上添花，而是评分组件的刚需。适合阅读这篇文章的人包括：正在做小程序评价模块的开发者、想封装一个通用评分组件的前端、以及被半颗星渲染折磨过的同行。

2. 整体设计思路与方案选型拆解

2.1 先想清楚：展示态和交互态是两套逻辑

很多人一上来就写代码，结果写着写着发现展示和交互混在一起，越写越乱。我的经验是，动手前先把这两个状态彻底分开。

展示态指的是只读场景，比如商品详情页显示"4.6分"，这时候星星只是视觉呈现，用户不能点。它的核心诉求是：给定一个0到5之间的小数，准确渲染出满星、半星、空星的数量。交互态指的是用户打分场景，比如"请为本次服务评分"，用户点击星星时要能选中，而且通常只允许选整颗或半颗。它的核心诉求是：把用户的点击位置换算成分数，并实时反馈。

为什么一定要分开？因为两者的数据流方向相反。展示态是"分数→视觉"，交互态是"点击→分数→视觉"。如果用一个组件硬扛两种模式，props会变得极其复杂，维护成本飙升。我通常的做法是写一个基础渲染组件负责"分数→星星"，再包一层交互逻辑处理点击，通过一个readonly或mode属性切换。这样展示态复用时不用带任何点击逻辑，交互态也能独立测试。

提示：如果你的项目里评分出现在多个页面，强烈建议抽成自定义组件而不是复制粘贴。半颗星的渲染逻辑一旦要改，集中在一处改比满项目找要省心得多。

2.2 三种渲染方案，到底选哪个

半颗星的渲染方式直接决定了实现难度和视觉效果，主流有三种，我把它们的取舍列成表格，你对着自己的项目选。

方案	实现方式	优点	缺点	适用场景
图片方案	准备满星、半星、空星三张图，按数量拼接	视觉可控，兼容性最好	需要切图，改颜色要重新出图	对视觉要求高、有设计资源
字体图标方案	用iconfont的星形字体，通过叠加裁剪实现半星	矢量清晰，改色方便	半星需要额外处理，字体加载有成本	追求清晰度和灵活性
纯CSS方案	用两层星星叠加，上层用宽度百分比裁剪	无需图片字体，改色改尺寸都方便	需要理解裁剪原理，边界处理要细心	想零依赖、快速实现

我个人的偏好是纯CSS叠加裁剪方案，原因很实在：不用等设计出图，不用引入字体文件增加包体积，改颜色就是改一个CSS变量的事。它的核心原理其实很简单——底层铺一排空星，上层铺一排满星，然后给上层容器设置一个宽度百分比，超出的部分用overflow: hidden裁掉。比如4.6分，就是4.6除以5等于92%，上层容器宽度设为92%，自然就露出了4.6颗星的视觉效果。半颗星？那只是92%这个数字恰好落在半颗星位置而已，根本不需要单独处理"半颗"这个概念。

这个思路一旦想通，半颗星就不再是特殊case，而是连续百分比的自然结果。这也是我推荐它的根本原因：把离散的"半颗星"问题转化成连续的"宽度百分比"问题，逻辑一下子简单了。

2.3 数据结构设计：分数怎么存、怎么传

在动手写渲染之前，得先把数据约定好。我见过太多项目因为分数格式不统一，导致前端一会儿拿到"4.6"，一会儿拿到"4.6分"，一会儿拿到"46"（放大十倍），每次都要转换，容易出错。

我的约定是这样的：分数统一用0到5的浮点数表示，保留一位小数。后端返回score: 4.6，前端直接用。如果需要显示百分比或者十分制，在展示层转换，不要污染原始数据。为什么保留一位小数？因为半颗星对应0.5，一位小数足够表达所有半星场景，再多就是过度设计。如果业务需要更精细（比如0.1星），那说明你需要的不是半星而是十分之一星，方案要重新考虑，但绝大多数场景0.5的粒度就够了。

另外要区分两个概念：平均分和用户评分。平均分是展示态，可以是任意小数；用户评分是交互态，通常只允许0.5的整数倍。这两个值在组件里要分开管理，不要混用同一个变量，否则用户点了一下半星，平均分的精度就被破坏了。

3. 半颗星渲染的核心细节与实操要点

3.1 纯CSS叠加裁剪方案完整实现

这是我最推荐的方案，先把核心代码给出来，再逐行解释为什么这么写。

<!-- 组件结构 --> <view class="star-rating"> <!-- 底层：空星 --> <view class="star-layer star-empty"> <text wx:for="{{5}}" wx:key="index" class="star-icon">★</text> </view> <!-- 上层：满星，宽度由分数决定 --> <view class="star-layer star-full" style="width: {{percent}}%;"> <text wx:for="{{5}}" wx:key="index" class="star-icon">★</text> </view> </view>

.star-rating { position: relative; display: inline-block; font-size: 32rpx; line-height: 1; } .star-layer { display: flex; white-space: nowrap; } .star-empty { color: #d9d9d9; /* 空星颜色 */ } .star-full { position: absolute; top: 0; left: 0; overflow: hidden; /* 关键：裁掉超出宽度的部分 */ color: #ffb800; /* 满星颜色 */ } .star-icon { flex-shrink: 0; }

// 计算宽度百分比 Component({ properties: { score: { type: Number, value: 0, observer(newVal) { // 限制在0-5之间，防止脏数据 const safe = Math.max(0, Math.min(5, newVal)); this.setData({ percent: (safe / 5) * 100 }); } } }, data: { percent: 0 } });

这段代码的关键点有三个。第一，两层星星必须完全对齐，所以上层用position: absolute叠在底层上面，top和left都是0。第二，上层容器必须overflow: hidden，这是裁剪生效的前提，没有它满星会全部露出来。第三，星星图标要flex-shrink: 0，否则在flex布局里可能被压缩，导致两层星星宽度不一致，裁剪位置就错位了。

为什么用★这个字符而不是图片？因为它本身就是字体，改color就能改颜色，改font-size就能改大小，零成本。有人担心不同设备上这个字符渲染不一致，实测下来在主流机型上表现稳定，实在不放心可以用iconfont的星形图标替代，原理完全一样。

3.2 半颗星的边界处理：那些容易翻车的地方

百分比方案虽然优雅，但边界情况必须处理，否则会出现"看起来差一点点"的诡异效果。

第一个坑是分数超出范围。后端如果返回5.1或者-0.2，百分比就会超过100%或变成负数，星星显示就乱了。所以observer里一定要做Math.max(0, Math.min(5, newVal))的钳制。我见过线上事故就是因为后端某次返回了5.0001，前端没防，上层宽度100.002%，虽然视觉上看不出来，但配合某些动画就露馅了。

第二个坑是精度导致的半星偏移。比如4.5分，理论上是4颗半，但4.5/5*100 = 90%，如果星星总宽度是奇数像素，90%可能落在第4.5颗星偏左或偏右一两个像素的位置，看起来半星就不"正"。解决办法是给星星容器一个能被5整除的宽度，或者干脆接受这一两个像素的误差——用户根本看不出来。如果产品对精度极其苛刻，那就回到图片方案，用三张图精确拼接。

第三个坑是空星和满星的字符宽度不一致。理论上同一个字符宽度一样，但如果你的空星用了不同的字体或者加了字重，宽度就可能不同，导致裁剪错位。所以两层星星的字体设置必须完全一致，只改颜色不改其他。

注意：如果你的星星之间有间距（比如每颗星之间留4rpx），那么百分比计算要考虑间距。因为间距也占宽度，90%的宽度可能裁到间距上而不是星星上。这种情况建议把间距做进星星字符本身（用letter-spacing），或者干脆不留间距，靠字符自带的边距。

3.3 交互态：点击如何换算成半星

展示态搞定后，交互态是另一个重点。用户点击星星时，我们要判断他点的是第几颗、是整颗还是半颗。这里有两种常见交互设计，得先跟产品确认。

设计A：只允许整颗星。用户点第3颗就是3分，简单直接。设计B：允许半颗星。点某颗星的左半边是半星，右半边是整星。设计B更精细，但实现要复杂一些，需要拿到点击位置相对于星星的偏移。

我以设计B为例讲实现。核心是拿到点击事件的detail.x（相对于组件的横坐标），然后除以单颗星的宽度，得到"点到了第几颗星的什么位置"。

// 假设每颗星宽度为 starWidth（单位px，需与渲染一致） handleTap(e) { const x = e.detail.x; // 相对于组件左上角的横坐标 const starWidth = this.data.starWidth; // 计算点到了第几颗星（从0开始） const starIndex = Math.floor(x / starWidth); // 计算在这颗星内的偏移比例 const offsetInStar = (x % starWidth) / starWidth; // 左半边算半星，右半边算整星 let score; if (offsetInStar < 0.5) { score = starIndex + 0.5; } else { score = starIndex + 1; } // 钳制范围 score = Math.max(0.5, Math.min(5, score)); this.setData({ score }); this.triggerEvent('change', { score }); }

这里有个细节：e.detail.x是相对于触发元素的坐标，如果星星外面还包了一层容器，坐标原点可能不是你想要的。稳妥的做法是用e.currentTarget配合boundingClientRect拿到组件的位置，再和e.detail.x做换算。或者更简单，直接给每颗星单独绑定点击事件，用>