过滤器函数需在入口统一用 if (value == null || value === '') 做空值防御，覆盖 null、undefined、空字符串等；时间类需 isnan(new date(value).gettime()) 判断；状态映射须转字符串查表；禁用 this 和 uni；模板兜底不可靠，必须内部防御。
过滤器函数里怎么安全判断入参是否有效
直接在过滤器函数第一行加 if (!value) 判断是最常用也最必要的做法，否则 new Date(null)、String(undefined) 这类操作会产出意外结果，上线后白屏都难定位。
-
value可能是null、undefined、空字符串''、数字0，甚至后端返回的"null"字符串——全得覆盖，不能只写if (!value)就完事 - 对时间类过滤器，必须加
isNaN(new Date(value).getTime())，因为new Date('')或new Date('invalid')返回的是一个“无效日期”对象，.getTime()为NaN，但不会报错 - 对状态码映射类过滤器（比如
statusText），别用map[value]直接取，先转成字符串再查：map[String(value)] || '未知'，避免后端传来数字1而 map key 是'1'导致匹配失败 - 别在过滤器里调用
this.xxx或uni.getSystemInfo—— 过滤器没组件实例上下文，this是undefined，uni也不自动注入
为什么不能只靠模板层做空值兜底
像 {{ item.time | formatDate || '--' }} 这种写法看似保险，其实危险：管道符 | 的优先级高于逻辑运算符 ||，实际执行的是 (item.time | formatDate) || '--'。一旦 formatDate 内部出错（比如抛了异常或返回 undefined），整个表达式就崩了，H5 可能白屏，小程序直接渲染为空。
- 模板里的
||是 JavaScript 表达式，不参与过滤器链路，它只作用于过滤器的返回值 - 如果过滤器本身没做防御，返回
undefined，那undefined || '--'确实能兜住；但若过滤器里new Date(null).getFullYear()报错，整个插值就中断，连||都没机会执行 - 真正可靠的兜底必须发生在过滤器内部，而不是模板里拼逻辑
跨平台时 null/undefined 的表现差异
小程序平台对空值更敏感：H5 端 new Date(undefined) 返回 Invalid Date，还能继续走 .getTime() 判断；但某些支付宝小程序基础库版本里，new Date(undefined) 会直接 throw，导致过滤器函数中断，模板渲染留空且无控制台报错。
- 所有过滤器函数入口必须统一用
if (value == null || value === '')，双等号能同时拦截null和undefined - 对数值型输入（如金额、ID），建议额外加
typeof value === 'number' && !isFinite(value)判断，防NaN、Infinity - 如果过滤器要处理后端返回的字符串型数字（如
"123"），先Number(value)再判isNaN，别直接parseInt(value)，它对"123abc"会返回123，造成静默错误
局部过滤器里怎么复用空值检查逻辑
局部过滤器定义在 filters: {} 里，没法像全局那样集中管理校验逻辑。想避免重复写 if (!value)，可以提前封装一个纯函数工具：
function safeFilter(fn) {
return function(value, ...args) {
if (value == null || value === '') return ''
return fn(value, ...args)
}
}
// 使用
filters: {
formatDate: safeFilter((date) => {
const d = new Date(date)
if (isNaN(d.getTime())) return ''
return `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}-${String(d.getDate()).padStart(2, '0')}`
})
}
注意这个 safeFilter 必须是纯函数，不依赖 this 或外部状态；它只是包装一层防御，不影响原逻辑执行路径。真正在意性能的场景（比如长列表中高频调用），还是建议把格式化提前到 computed 或请求后处理，别全压在模板层。
