根本原因是各端对button和input[type="number"]默认渲染逻辑不同：h5用原生控件，微信小程序用button模拟，ios app额外加内边距和圆角；统一用view+text构建视觉层并模拟交互，配合rpx单位与flex居中方案（父容器align-items: stretch，子元素均设display: flex; align-items: center; justify-content: center），禁用type="number"改用type="text"校验，可实现三端像素级对齐。
uni-app自定义步进器（stepper）为什么在小程序里按钮错位
根本原因不是样式写得不够多，而是各端对button和input[type="number"]的默认渲染逻辑不同：H5用原生表单控件，微信小程序用button模拟，App端（尤其是iOS）还会额外加内边距和圆角。直接套用一套CSS，必然出现按钮高度不一致、文字垂直偏移、点击热区错位等问题。
真正有效的做法是放弃依赖原生控件外观，统一用view + text构建视觉层，再用touchstart/touchend模拟长按递增/递减行为——这样所有平台渲染的都是你写的view，可控性拉满。
- 禁用
input的type="number"，改用type="text"并监听input事件做数字校验 - 两个操作按钮必须用
view包裹text，避免小程序把button渲染成带阴影的原生按钮 - 所有高度、行高、内边距统一用
rpx，但line-height值必须显式等于容器高度，否则H5和小程序文字基线不一致
怎么让+/-按钮和中间输入框在三端都水平居中对齐
常见错误是给父容器设display: flex后只调align-items: center，结果H5对齐了，小程序里text下沉2px，App上又浮起1px。本质是各端text的vertical-align默认值不同，且flex子项的基线对齐行为不统一。
可靠解法是强制所有子元素脱离文本流基线约束：
- 父容器设
display: flex; align-items: stretch;（不要用center） - 每个子元素（+、输入框、-）都设
display: flex; align-items: center; justify-content: center; - 输入框区域额外包一层
view，内部用text显示数值，避免input自身内边距干扰 - 所有子元素高度统一设为
64rpx，line-height也设为64rpx，字体大小用28rpx
这样三端都走flex交叉轴居中逻辑，绕开了文本基线差异。
如何处理不同平台的点击反馈和长按连续触发
H5支持mousedown+setInterval实现长按连加，但小程序和App不触发mousedown，且touchstart后若不及时touchend，会触发系统级长按菜单。硬套H5逻辑会导致小程序点一下就跳两次、App上长按没反应。
跨端兼容方案必须分平台处理：
- H5：监听
mousedown启动计时器，mouseup/mouseleave清除；单击直接触发一次 - 小程序/App：只响应
touchstart和touchend；touchstart后立即触发一次，然后延时300ms启动重复触发，touchend立刻清除定时器 - 用
uni.getSystemInfoSync().platform判断当前平台，动态绑定对应事件处理器
别试图用@longpress，它在H5无效，在部分安卓App上响应延迟严重。
rem/vw单位在步进器里为什么反而加剧对齐问题
因为postcss-px-to-viewport这类插件转换时，会把64rpx转成vw，而各端WebView对vw的解析精度不同：H5四舍五入到小数点后3位，微信小程序截断到整数像素，App端甚至可能因缩放因子导致1px偏差。看似用了响应式单位，实则放大了渲染误差。
步进器这种需要像素级对齐的组件，必须回归rpx：
- 确保项目根节点
font-size为100rpx（即750设计稿下1rem=75px），这是uni-app默认基准 - 禁用
postcss-px-to-viewport对.stepper类名下的所有规则生效（在vite.config.ts中exclude添加/stepper/） - 所有涉及对齐的尺寸（高度、内边距、字体大小）只用
rpx，不用px或vw
最易被忽略的是：哪怕你写了height: 64rpx，如果父容器用了flex: 1且未设明确高度，某些小程序引擎会把rpx按屏幕宽度而非容器宽度计算——所以务必给步进器外层容器设固定高度或min-height。
