uni-app中v-for内不可靠使用filters，因小程序端完全忽略、Vue 3已移除该API；应改用setup中封装Intl.NumberFormat格式化函数或计算属性实现跨平台稳定千分位处理。

uni-app 的 v-for 里不能可靠使用过滤器（filters）

如果把 {{ price | toThousands }} 直接写进 v-for 模板里，十有八九是不会生效的。问题通常不在写法本身，而在 uni-app 的编译机制上：微信、支付宝、字节、鸿蒙等小程序端，会直接忽略通过 Vue.filter 注册的过滤器；至于 H5 端，也只是在 Vue 2 模式下（也就是 main.js 里调用 Vue.filter）还能勉强使用，而到了 Vue 3（即 setup + @vue/composition-api），这个 API 已经被彻底移除了。

替代方案：用计算属性或函数封装格式化逻辑

把格式化逻辑从模板层抽出来，在 setup 或 data 中预处理或实时调用，才是跨平台稳定的写法：

• 在 setup 中定义一个格式化函数，比如：

  const formatMoney = (value) => {
  if (value == null) return '0.00'
  const num = Number(value)
  return new Intl.NumberFormat('zh-CN', {
  minimumFractionDigits: 2,
  maximumFractionDigits: 2
  }).format(num)
  }

• 在 v-for 中直接调用：{{ formatMoney(item.price) }}
• 若数据量大、频繁渲染，可提前在 onLoad 或 watch 中批量格式化并存入响应式变量，避免每次渲染都执行格式化

为什么不用正则手写千分位？

手写正则（如 /(d)(?=(d{3})+.)/g）看似简单，但实际踩坑多：

• 不处理负数：-12345 → -12,345（漏掉负号就变成 12,345）
• 浮点精度问题：(0.1 + 0.2).toFixed(2) 得到 "0.30000000000000004"，必须先 Math.round(num * 100) / 100
• 小数点缺失时匹配失败：整数 12345 不含小数点，原正则不触发
• 小程序真机上低基础库版本（如微信 < 2.19.0）可能不支持 Intl 的 maximumFractionDigits，建议只设 minimumFractionDigits: 2，再手动截断

在 v-for 里频繁调用格式化函数会影响性能吗？

影响极小，但有优化空间：

• 每次调用 new Intl.NumberFormat() 会新建实例，开销虽小，但可复用：在 setup 外层定义一次 formatter 实例，再在函数中复用
• 不要在 computed 或 watch 里反复构造 formatter，它本身是轻量对象
• 如果列表项超过 100 条且滚动频繁，建议用 recycle-list 替代原生 v-for，配合预格式化字段（如 item.formattedPrice）进一步减少运行时计算

真正容易被忽略的是：格式化前没做 Number() 转换——传字符串进去，Intl.NumberFormat 可能返回 "Invalid" 或静默失败，尤其后端返回的是字符串型金额。