uni-app 无内置过滤规则，“默认过滤”实为代码主动添加：包括v-for中v-if/filter()、第三方插件searchfilter配置、uni-forms rules隐藏逻辑；需通过断点查数据源、搜索filter关键词、查阅插件文档定位并关闭对应开关。
uni-app 里没有“组件内置过滤规则”这回事——所谓“默认过滤”，基本都是你或第三方代码主动加的逻辑，得反向定位、手动剥离。
为什么你看到的“默认过滤”其实不是默认的
uni-app 的所有内置组件（如 uni-list、uni-search-bar、uni-grid）本身不带任何数据过滤逻辑。你遇到的“自动过滤”现象，通常来自以下三处：
- 你在
v-for中写了v-if或filter()方法，但没意识到它在每次渲染时都执行 - 第三方 UI 库（比如某些封装了搜索 + 列表联动的
uni-data-table插件）自带 searchFilter 配置项，默认开启 - 你用了
uni-forms并设置了rules，误把校验触发的隐藏/显隐当成了“过滤”
怎么快速定位是哪一层在过滤
打开控制台，在列表渲染前打个断点，检查原始数据源是否已被修改：
- 查
data或props初始值：如果原始数组长度就变少了，说明请求回来后就被处理过（比如后端返回时已筛过，或你在onLoad里调了.filter()） - 查
computed或methods：搜关键词filter(、.filter、searchFilter、match，尤其注意uni-search-bar的@input回调里有没有重赋值逻辑 - 查插件文档：比如
uni-data-select有filterable和searchFilter两个开关，关掉它比改样式还容易
常见组件的“假过滤”清除路径
不同组件的“过滤感”来源不同，处理方式也得对症：
-
uni-search-bar：它自己不筛数据，但常被搭配uni-list使用；真正干活的是你写的onInput方法里那句this.filteredData = this.rawData.filter(...)—— 把这行删掉，或改成this.filteredData = [...this.rawData] -
uni-data-picker或uni-data-select：检查是否设了searchFilter属性（默认为true），改为false即可停用内置搜索匹配 -
uni-forms+uni-forms-item：如果你发现输入后某个字段突然消失，不是过滤，而是rules触发了hidden动态控制；删掉rules里的hidden字段，或确保它不依赖用户输入值
最容易被忽略的“隐形过滤”点
有些过滤根本不在模板或 JS 里，而在编译或平台层：
- 小程序端使用
uni.getStorageSync读缓存时，如果 key 写错或数据结构变化，可能读到空数组，你以为是“被过滤了”，其实是没读到 - H5 端用了
Object.freeze()冻结原始数据，后续.filter()返回新数组没问题，但如果你试图直接 push 或 splice 原数组，会静默失败，看起来像“数据消失了” - App 端真机调试时，某些 Android 厂商 WebView 对正则支持不全，导致你写的
/keyword/i.test(item.name)总返回false，结果整个列表为空——换成本地字符串includes()就正常了
