1. 从半颗星这个细节说起评分组件为什么值得单独拎出来做做小程序开发的人几乎都绕不开一个需求评分展示。电商要展示商品好评度内容社区要展示文章质量分本地生活要展示门店星级就连工具类小程序也常常需要让用户给个反馈。看起来简单——五颗星亮几颗暗几颗完事。但真正动手写过的人都知道这里面藏着一个特别容易被低估的细节半颗星怎么画。我见过太多项目在这上面翻车。有的用五张图片硬切结果不同机型上星星大小不一致有的用字体图标凑合半颗星直接四舍五入成整颗用户看到4.3分显示成4颗星觉得数据造假还有的用canvas画性能没问题但代码复杂到没人愿意维护。更常见的是产品经理说要支持半星开发随手写了个Math.round上线后被用户截图吐槽评分不准。这篇文章就是把这个看似微小的组件彻底讲透。我会从评分数据的本质讲起说清楚为什么半颗星不是四舍五入那么简单然后给出三种不同技术路线的完整实现包括纯CSS方案、图片精灵方案和SVG方案每种都附上可直接复制的代码接着重点拆解半颗星的精确渲染逻辑这是整个组件的核心难点最后分享一些我在实际项目中踩过的坑和优化技巧比如小数精度处理、动态评分交互、无障碍适配等。不管你是刚接触小程序开发的新手还是想找一个稳定评分组件的老手这篇内容都能让你直接抄作业。代码基于微信小程序原生语法不依赖任何第三方UI库复制到项目里就能跑。2. 评分数据的本质为什么半颗星不是简单的四舍五入2.1 评分值的两种来源与精度陷阱在动手写代码之前必须先搞清楚评分数据是怎么来的。这直接决定了你该怎么处理半颗星。第一种来源是后端直接返回的聚合评分比如商品详情页显示4.7分这个数字通常是所有用户评分的平均值。第二种来源是用户交互产生的实时评分比如用户点击第三颗星表示打了3分。这两种场景对精度的要求完全不同。聚合评分最大的坑在于浮点数精度。JavaScript里0.1 0.2 ! 0.3这个经典问题在评分计算中同样存在。假设后端返回的评分是4.35你想显示半颗星判断逻辑如果是score % 0.5 0.25那么4.35 % 0.5的结果可能是0.3499999999999996导致判断结果和你预期的不一样。我实测过某些评分在特定数值下会出现该亮半星却亮了整星的诡异现象。解决办法很简单先把评分转成整数运算。比如把评分乘以10再取整用整数来比较。Math.round(score * 10)得到44对应4.4分然后判断44 % 5的余数来决定半星。这样完全避开了浮点误差。// 不推荐直接对浮点数取模 const hasHalf (score % 0.5) 0.25; // 可能因精度出错 // 推荐转成整数再运算 const scoreInt Math.round(score * 10); // 4.35 - 44 (实际是43.5四舍五入) const remainder scoreInt % 5; // 44 % 5 4 const hasHalf remainder 3; // 余数3或4表示需要半星2.2 半星、整星与空星的判定边界很多人以为半颗星的逻辑是大于等于0.5就显示半星这其实不对。正确的判定应该基于四舍五入到最近的0.5。举个例子评分4.2分应该显示4颗星还是4颗半按四舍五入到0.5的规则4.2更接近4.0所以显示4颗整星。评分4.3分更接近4.5显示4颗半星。这个边界值0.25和0.75是关键分界线。具体规则可以总结成一张表评分小数部分显示效果判定逻辑0.00 - 0.24整星舍去小数0.25 - 0.74半星显示半颗0.75 - 0.99整星进位进一位用整数运算表达就是scoreInt % 10得到小数部分的十分位如果这个值在3到7之间对应0.3到0.7显示半星小于3舍去大于7进位。注意这里的边界值0.25和0.75是行业惯例但有些产品会要求只要有小数就显示半星比如4.1分也显示4颗半。这属于产品策略不是技术问题开发前一定要和产品确认清楚。2.3 为什么不用四舍五入到整星有人会问直接四舍五入到整星不行吗4.7显示5颗星4.3显示4颗星多简单。问题在于用户感知。评分4.7和5.0在用户眼里差距很大如果都显示5颗星用户会觉得评分系统不精确进而怀疑数据的真实性。半星的存在就是为了在视觉上更细腻地反映评分差异。4.5颗星和5颗星的区别用户一眼就能看出来这种颗粒度是评分组件专业度的体现。另外从数据展示的角度半星能让评分分布更平滑。如果只有整星4.1到4.9之间的所有评分在视觉上可能都差不多用户无法快速区分。加上半星后4.0、4.5、5.0三个档位清晰可见信息传达效率更高。3. 三种技术路线的完整实现与选型对比3.1 纯CSS方案用伪元素和overflow实现半星裁剪纯CSS方案的核心思路是底层放一排灰色的空星上层放一排金色的亮星通过控制上层容器的宽度来实现亮几颗的效果。半颗星就是宽度设为50%。这个方案最大的好处是不依赖任何图片资源星星用CSS绘制或者用字体图标体积小、加载快、任意缩放不模糊。缺点是星星形状受限于CSS能力做不出特别复杂的星形。先看星星怎么画。最简单的方式是用Unicode字符★和☆但这两个字符在不同设备上的渲染效果差异很大不推荐。更好的方式是用CSS的clip-path画五角星.star { width: 40rpx; height: 40rpx; background: #ddd; clip-path: polygon( 50% 0%, 61% 35%, 98% 35%, 68% 57%, 79% 91%, 50% 70%, 21% 91%, 32% 57%, 2% 35%, 39% 35% ); }clip-path的polygon坐标定义了一个标准五角星的十个顶点。这个写法在所有现代浏览器和小程序webview里都支持实测下来很稳。然后是半星裁剪。结构上需要两层view classstar-wrap view classstar-bg view classstar wx:for{{[1,2,3,4,5]}} wx:key*this/view /view view classstar-fg stylewidth: {{fgWidth}}% view classstar active wx:for{{[1,2,3,4,5]}} wx:key*this/view /view /view.star-bg是底层灰色星星.star-fg是上层金色星星通过width百分比控制显示宽度。fgWidth的计算逻辑是(亮星数 / 5) * 100%。比如4.5颗星宽度就是90%。这里有个细节.star-fg必须设置overflow: hidden和white-space: nowrap否则星星会换行。同时.star-fg里的星星要和.star-bg里的星星位置完全对齐所以两个容器的display和间距设置必须一致。.star-wrap { position: relative; display: inline-flex; } .star-bg, .star-fg { display: flex; gap: 8rpx; } .star-fg { position: absolute; top: 0; left: 0; overflow: hidden; white-space: nowrap; } .star.active { background: #ffb800; }这个方案的优点是渲染精确宽度设成90%就是精确的4.5颗星不存在四舍五入误差。缺点是如果星星之间有间距半星裁剪时会把间距也裁掉一半视觉上可能不太自然。解决办法是把间距做进星星内部用padding或者接受这个细微差异。3.2 图片精灵方案一张图搞定所有状态如果你的设计稿要求星星有渐变、阴影、立体感CSS画不出来那就得用图片。但千万别用五张独立的星星图片那样管理起来是噩梦。正确做法是图片精灵sprite把整星、半星、空星三种状态拼在一张图上用background-position切换。精灵图的布局通常是横向排列第一张是空星第二张是半星第三张是整星。每张星星的宽度固定比如60px。那么.star { width: 60rpx; height: 60rpx; background-image: url(/images/star-sprite.png); background-size: 180rpx 60rpx; /* 三张图总宽180 */ } .star.empty { background-position: 0 0; } .star.half { background-position: -60rpx 0; } .star.full { background-position: -120rpx 0; }渲染时根据评分计算出每颗星的状态生成一个数组比如[full, full, full, full, half]然后循环渲染。计算逻辑用整数运算function getStarStates(score) { const scoreInt Math.round(score * 10); // 转整数 const fullCount Math.floor(scoreInt / 10); // 整星数量 const remainder scoreInt % 10; // 小数部分 const states []; for (let i 0; i 5; i) { if (i fullCount) { states.push(full); } else if (i fullCount remainder 3 remainder 7) { states.push(half); } else if (i fullCount remainder 7) { states.push(full); // 进位 } else { states.push(empty); } } return states; }这个方案的好处是视觉表现力最强设计给什么图就显示什么效果。缺点是图片有体积而且换颜色需要重新出图。如果项目对包体积敏感可以用base64内联但要注意base64会让代码文件变大不利于维护。实操心得精灵图方案一定要让设计导出2x和3x两套图或者直接用一张足够大的图比如180x60px然后靠background-size缩放。我见过有人只导了1x的图在高清屏上星星边缘全是锯齿被测试提了bug。3.3 SVG方案矢量渲染与动态着色SVG是小程序里被低估的方案。它既能像CSS一样矢量渲染又能像图片一样有丰富的形状还能动态改颜色。对于评分组件来说SVG几乎是完美选择。思路是用SVG的defs定义一个星星的symbol然后用use引用。半星通过linearGradient实现——定义一个渐变前半段是金色后半段是灰色应用到星星上就是半星效果。svg width0 height0 defs symbol idstar viewBox0 0 24 24 path dM12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z/ /symbol linearGradient idhalfGrad stop offset50% stop-color#ffb800/ stop offset50% stop-color#ddd/ /linearGradient /defs /svg但小程序对SVG的支持有限不能直接在wxml里写svg标签。实际做法是把SVG转成base64作为背景图或者用image标签加载SVG文件。半星效果则通过CSS的background: linear-gradient叠加实现本质上和纯CSS方案类似只是星星形状来自SVG。更实用的做法是把SVG星星作为background-image然后用background-clip配合渐变来做半星。不过这个方案在小程序里兼容性一般我实测在部分安卓机型上background-clip: text不生效。综合来看纯CSS方案适合大多数场景体积小、可控性强图片精灵方案适合设计感要求高的场景SVG方案适合需要动态换色或复杂形状的场景。选型时优先考虑纯CSS实在满足不了再上图片。4. 半颗星的精确渲染从计算到显示的完整链路4.1 评分到星星状态的映射算法前面零散提到了计算逻辑这里把它完整梳理成一个可复用的函数。这个函数是整个组件的核心输入一个0到5的评分输出五颗星的状态数组。/** * 将评分转换为星星状态数组 * param {number} score - 评分0到5之间 * param {boolean} allowHalf - 是否允许半星 * returns {string[]} 长度为5的数组元素为full|half|empty */ function scoreToStars(score, allowHalf true) { // 边界处理 if (typeof score ! number || isNaN(score)) score 0; score Math.max(0, Math.min(5, score)); // 转整数避免浮点误差 const scoreInt Math.round(score * 10); const fullCount Math.floor(scoreInt / 10); const remainder scoreInt % 10; const stars []; for (let i 0; i 5; i) { if (i fullCount) { stars.push(full); } else if (i fullCount) { if (!allowHalf) { // 不允许半星时四舍五入到整星 stars.push(remainder 5 ? full : empty); } else if (remainder 3 remainder 7) { stars.push(half); } else if (remainder 7) { stars.push(full); } else { stars.push(empty); } } else { stars.push(empty); } } return stars; }这个函数有几个关键点值得说明。第一边界钳制。评分可能因为后端bug返回负数或大于5的值必须钳制到0到5之间否则渲染会出错。第二整数化处理。Math.round(score * 10)把4.35变成44把4.34变成43。这样后续所有判断都是整数比较完全避开浮点误差。第三半星判定区间。余数3到7对应小数0.3到0.7显示半星。余数小于3舍去大于7进位。这个区间是四舍五入到0.5的精确表达。第四allowHalf开关。有些场景不需要半星比如用户打分时只能点整星那么展示时也可以统一用整星通过这个参数控制。4.2 宽度百分比方案的具体计算如果用纯CSS的宽度裁剪方案需要把星星状态转成宽度百分比。计算方式是整星算1半星算0.5空星算0。function starsToWidth(stars) { let total 0; stars.forEach(s { if (s full) total 1; else if (s half) total 0.5; }); return (total / 5) * 100; // 返回百分比 }比如[full,full,full,full,half]total是4.5宽度就是90%。这个百分比直接绑定到.star-fg的stylewidth: {{width}}%上。这里有个精度问题90%在有些设备上可能渲染成89.98%导致半星边缘有细微的灰色露出。解决办法是给宽度加一个极小的补偿比如width: calc(90% 0.5rpx)。或者干脆用transform: scaleX来做但scaleX会拉伸星星形状不推荐。另一个细节是星星间距。如果五颗星之间有gap那么宽度百分比是基于整个容器宽度的gap也会被算进去。比如容器总宽200rpx五颗星各30rpxgap是12.5rpx那么4.5颗星的实际宽度不是90%而是(4.5*30 4*12.5) / 200 92.5%。这个计算很容易搞错我建议把gap做进星星内部用padding或者margin在星星元素上这样宽度百分比就只和星星数量有关简单可靠。4.3 动态评分交互点击与滑动展示型评分和交互型评分的实现差别很大。展示型只需要把评分渲染出来交互型还要处理用户的点击和滑动。点击交互相对简单给每颗星绑定bindtap点击第i颗星就把评分设为i。如果要支持半星点击需要判断点击位置在星星的左半边还是右半边。handleTap(e) { const index e.currentTarget.dataset.index; // 第几颗星从0开始 const { left, width } e.currentTarget; // 需要提前获取星星的位置信息 const tapX e.detail.x - left; const isLeftHalf tapX width / 2; const score index (isLeftHalf ? 0.5 : 1); this.setData({ score }); }但小程序里获取元素的left和width需要用到createSelectorQuery而且要在点击时实时获取性能不太好。更实用的做法是用触摸事件计算handleTouch(e) { const touch e.touches[0]; const query wx.createSelectorQuery().in(this); query.select(.star-wrap).boundingClientRect(rect { const x touch.clientX - rect.left; const starWidth rect.width / 5; const starIndex Math.floor(x / starWidth); const inStarX x - starIndex * starWidth; const isHalf inStarX starWidth / 2; const score starIndex (isHalf ? 0.5 : 1); this.setData({ score: Math.min(5, score) }); }).exec(); }滑动交互就是监听bindtouchmove每次移动都重新计算评分。这里要注意节流不然频繁的setData会导致卡顿。可以用一个时间戳判断间隔小于50ms就跳过。实操心得交互型评分一定要加catchtouchmove防止页面滚动否则用户在星星上滑动时页面会跟着滚体验很差。另外如果评分组件在弹窗或滚动列表里boundingClientRect获取的位置可能不准建议在onReady里提前获取并缓存。5. 那些文档不会告诉你的踩坑记录5.1 浮点数精度导致的半星闪烁这个坑我在两个项目里都遇到过。现象是评分4.5理论上应该显示4颗半星但实际渲染出来有时候是4颗半有时候是5颗整刷新几次结果还不一样。排查过程花了整整一个下午。最后定位到是后端返回的评分经过了多次计算4.5在传输过程中变成了4.499999999999999。前端用score % 0.5判断时4.499999999999999 % 0.5的结果是0.4999999999999991大于0.25判定为半星——这没问题。但如果评分是4.499999999999999Math.floor(score)得到4余数判断又可能因为精度问题走到进位分支显示成5颗整星。根治办法所有评分在进入渲染逻辑前统一用Math.round(score * 10) / 10处理一次把精度固定到一位小数。这样4.499999999999999会变成4.5后续计算就稳定了。function normalizeScore(score) { return Math.round(score * 10) / 10; }5.2 不同机型上星星大小不一致用rpx做单位理论上应该自适应但实际测试发现在某些折叠屏或平板设备上星星会被拉伸变形。原因是clip-path的polygon坐标是基于元素宽高的百分比如果元素宽高比不是1:1五角星就会变形。解决办法是强制星星宽高相等并且用aspect-ratio: 1锁定比例。如果小程序基础库版本不支持aspect-ratio就用padding-bottom: 100%的经典技巧。.star { width: 40rpx; height: 40rpx; /* 必须显式设置不能只设一个 */ flex-shrink: 0; /* 防止被flex压缩 */ }另外clip-path在部分低版本安卓webview上不支持需要做降级。降级方案是改用background-image加载一张星星PNG通过媒体查询或特性检测切换。5.3 评分组件的无障碍适配这个点很少有人提但如果你做的是面向公众的产品无障碍适配是绕不开的。评分组件对屏幕阅读器来说是一堆没有语义的view视障用户根本不知道这是评分。正确做法是给评分容器加上aria-label把评分值读出来view classstar-wrap aria-label评分{{score}}分满分5分 roleimg !-- 星星 -- /view如果是交互型评分每颗星还要加上rolebutton和对应的aria-label比如打1分、打2分。这样视障用户才能通过屏幕阅读器操作。小程序对ARIA的支持有限但aria-label在view上是生效的。我实测在iOS的VoiceOver下能正确朗读安卓的TalkBack也支持。5.4 评分动画的性能陷阱给星星加过渡动画能让体验更丝滑比如评分从3分变到4.5分时星星逐个点亮。但动画如果用setData逐帧更新性能会很差尤其是在长列表里。更好的做法是用CSS的transition只改变宽度或透明度让浏览器自己插值。比如纯CSS方案里.star-fg的width加一个transition: width 0.3s ease评分变化时宽度平滑过渡视觉上就是星星逐渐点亮的效果。.star-fg { transition: width 0.3s ease; }如果要做逐颗点亮的效果可以给每颗星单独加transition-delay第i颗星延迟i * 50ms。这样不需要任何JS动画纯CSS就能实现。注意transition在width上会触发重排如果评分组件很多可能会有性能问题。替代方案是用transform: scaleX但会拉伸星星。折中方案是用opacity做淡入性能最好但视觉效果稍弱。6. 组件封装与复用让它成为项目里的标准件6.1 属性设计与默认值一个可复用的评分组件对外暴露的属性应该尽量少而精。我设计的属性表如下属性名类型默认值说明scoreNumber0当前评分0到5allowHalfBooleantrue是否显示半星readonlyBooleantrue是否只读false时可点击sizeNumber40星星大小单位rpxactiveColorString#ffb800亮星颜色emptyColorString#dddddd空星颜色showScoreBooleanfalse是否在星星后显示数字评分属性设计的原则是覆盖常见场景但不做过度设计。比如有人会加max属性支持10颗星但实际项目中99%的评分都是5分制加这个属性只会增加复杂度。真需要10颗星改一下循环次数就行。readonly默认设为true是有意为之。大多数场景下评分组件是展示用的只有少数场景需要交互。默认只读能避免误触需要交互时显式传false。6.2 事件与数据回传交互型评分需要把用户的选择回传给父组件。用triggerEvent触发一个change事件handleSelect(score) { if (this.data.readonly) return; this.setData({ score }); this.triggerEvent(change, { score }); }父组件这样使用star-rating score{{score}} readonly{{false}} bindchangeonScoreChange /onScoreChange(e) { console.log(用户评分, e.detail.score); }这里有个细节内部setData和外部传入的score可能冲突。如果父组件在change事件里没有更新score组件内部的score会保持用户选择的值但下次父组件重新渲染时又会被覆盖。解决办法是组件内部维护一个innerScore优先使用innerScore同时监听score属性的变化来同步。observers: { score: function(val) { if (val ! this.data.innerScore) { this.setData({ innerScore: val }); } } }6.3 在列表中的性能优化评分组件经常出现在商品列表里一个页面可能有几十个。如果每个组件都独立计算、独立渲染性能会很吃紧。优化手段有几个。第一计算逻辑前置。在获取列表数据时就把星星状态数组算好直接传给组件组件只负责渲染不做计算。第二用wx:key优化列表渲染避免不必要的重渲染。第三避免在组件里使用createSelectorQuery这个API在列表里频繁调用会严重拖慢性能。如果列表特别长还可以考虑虚拟列表只渲染可视区域内的评分组件。不过这个复杂度较高一般项目用不上。6.4 主题色切换的实现有些产品需要根据评分高低显示不同颜色比如4分以上绿色3到4分黄色3分以下红色。这个需求用activeColor属性就能实现父组件根据评分计算颜色传进来。function getScoreColor(score) { if (score 4) return #52c41a; if (score 3) return #faad14; return #ff4d4f; }但要注意颜色切换时如果有过渡动画颜色会平滑变化视觉上可能不太自然。如果希望颜色瞬间切换就不要给background-color加transition。另外如果星星是用clip-path画的改颜色只需要改background很简单。但如果是图片精灵改颜色就得换图这时候建议用SVG方案通过fill属性动态改色。7. 从评分组件延伸出去的一些思考评分组件看起来是个很小的东西但把它做扎实能反映出很多工程上的习惯。比如边界处理——评分可能是0、可能是5、可能是负数、可能是null每种情况都要有合理的降级。比如精度意识——浮点数在JavaScript里是个永恒的坑任何涉及小数的计算都要多留个心眼。再比如性能敏感——列表里的组件和单页里的组件写法应该不一样。我在实际项目中还遇到过一些变体需求。有的要支持10分制显示10颗星这时候星星大小要相应缩小否则一行放不下。有的要支持动态星星数量根据后台配置显示3颗或5颗。还有的要支持评分分布展示比如5星80%4星15%3星5%这其实就是把评分组件和进度条结合起来。这些变体本质上都是同一个核心逻辑的延伸把数值映射到视觉状态。只要把半星的计算逻辑吃透了其他变体都是换汤不换药。最后分享一个我个人的习惯每次写完评分组件我都会用一组边界值跑一遍测试——0、0.1、0.24、0.25、0.5、0.74、0.75、1.0、4.99、5.0。这组值覆盖了所有舍入边界能快速发现逻辑漏洞。实测下来能扛住这组测试的评分组件上线后基本不会出问题。