computed 是响应式计算的核心机制，过滤器仅是模板层纯函数格式化工具；两者维度不同不可替代，错误选用会导致页面不更新、跨端失效或逻辑失控。
computed 是响应式计算的核心机制，过滤器只是模板层的纯函数格式化工具；两者根本不在一个维度上，不能互相替代，选错会导致页面不更新、跨端失效或逻辑失控。
computed 能监听数组内部变化，过滤器完全做不到
购物车总价、搜索列表、状态映射这类需要「数据一变，界面立刻重算」的场景，必须用 computed。因为 computed 会自动追踪 cartItems 中每个 item.num 和 item.price 的变化；而过滤器只接收整个数组作为参数，它根本不知道你改了第 2 个 item 的数量——哪怕你写了 {{ cartItems | totalPrice }}，界面也卡在旧值不动。
- 常见错误：把
totalPrice写成全局过滤器，在微信小程序里真机调试时数字始终不变 - Vue 3 的 Composition API 项目中，
filters配置项已被移除，setup()里压根没法注册 - uni-app 小程序平台编译时直接忽略
|管道语法，不是报错，是静默失效
过滤器只在 {{ }} 和 v-bind 中生效，v-if 里用不了
想根据后端返回的状态码 status: 1 控制按钮显隐？别写 v-if="item.status | statusText === '待审核'"——这语法非法，编译直接报错。过滤器只在插值和属性绑定中起作用，v-if 解析的是纯 JavaScript 表达式，根本不走 Vue 的过滤器管道。
- 正确做法：用
computed提前算出布尔值，比如isPending() { return this.item.status === 1 }，再写v-if="isPending" - 如果映射关系复杂（如多语言），应在
i18n字典里查，而不是在过滤器里硬编码this.$t——上下文不可靠，H5 可能行，小程序必崩 - 模板里写
{{ item.info?.status | statusText }}时，item.info为undefined会直接报错；Vue 2 不支持可选链，得提前判空
跨端一致性只能靠 computed 或纯函数，不能依赖 Vue.filter
Vue.filter 在 H5 端可能工作，但在微信/支付宝小程序、App 端基本无效——不是你代码有 bug，是 uni-app 编译机制决定的：小程序用 JSON 数据驱动渲染，| 语法压根不解析。你 main.js 里注册了 formatDate，H5 正常，真机上却显示 NaN-NaN-NaN，就是这个原因。
- 真正跨端可用的方案：在
@/utils/filters.js里导出纯函数，如export const formatDate = (date) => { ... } - 模板中要用？封装进
computed：const displayDate = computed(() => formatDate(props.time)) - 金额类场景更推荐
Intl.NumberFormat，它在主流小程序基础库中均已稳定支持，比手写正则靠谱得多
最易被忽略的一点：很多人以为“过滤器能简化模板”，结果把所有字段兜底逻辑都塞进去，最后发现小程序白屏、H5 正常、App 报错——问题不在写法，而在误判了它的能力边界。过滤器只做格式化，不参与响应式依赖追踪；该由 computed 承担的派生计算，交给它才是唯一可靠路径。
