EXT.js 4.0 的 Store 组件中,findRecord 方法在特定场景下会返回错误结果,这是一个容易被忽视的陷阱。如果您曾用它精确匹配某个 ID 却发现返回了另一条记录,很可能就是这里出了问题。下面将整个调用链拆解分析,问题出在哪个环节其实很清晰。
findRecord 在其内部实现中直接调用了 find 方法:
findRecord: function() {
var me = this,
index = me.find.apply(me, arguments);
return index !== -1 ? me.getAt(index) : null;
}而 find 又调用了 createFilterFn 生成过滤函数,并将结果交给 data.findIndexBy 进行遍历:
find: function(property, value, start, anyMatch, caseSensitive, exactMatch) {
var fn = this.createFilterFn(property, value, anyMatch, caseSensitive, exactMatch);
return fn ? this.data.findIndexBy(fn, null, start) : -1;
}
createFilterFn: function(property, value, anyMatch, caseSensitive, exactMatch) {
if (Ext.isEmpty(value)) {
return false;
}
value = this.data.createValueMatcher(value, anyMatch, caseSensitive, exactMatch);
return function(r) {
return value.test(r.data[property]);
};
}
findIndexBy : function(fn, scope, start){
var me = this,
keys = me.keys,
items = me.items,
i = start || 0,
len = items.length;
for (; i < len; i++) {
if (fn.call(scope || me, items[i], keys[i])) {
return i;
}
}
return -1;
}关键点在于最后一行:value.test(r.data[property])——这正是 BUG 的根源。当 value 通过 createValueMatcher 被编译为正则表达式对象后,test() 方法执行的是**子串匹配**,而非精确的字符串相等。
假设我们希望查找 ID 等于 1 的记录,createValueMatcher 会将值 "1" 编译成正则表达式 /1/。当遍历到 ID 为 "15" 的记录时,value.test('15') 会返回 true,因为正则表达式成功匹配到了子串 "1"。于是 findRecord 错误地返回了 ID=15 的记录,而非预期的 ID=1。
换言之,在默认参数下,findRecord 执行的是**模糊匹配**,而非严格的相等比较。这显然违背了开发者对 findRecord 的预期——通常我们希望它能按照主键进行精确查找。
解决方式其实很简单:调用 findRecord 时,将 exactMatch 参数设置为 true,或者直接使用 getById、findRecord 的其他重载形式。如果一直使用默认参数,遇到这个问题的可能性非常高。
该 BUG 在 Ext.js 4.0.x 的早期版本中始终存在,后续小版本是否已修复?官方文档并未明确提及。但从源码逻辑判断,只要 createValueMatcher 的实现方式不变,默认情况下 findRecord 始终执行部分匹配。因此,编写代码时请牢记:使用 findRecord 进行精确查找时,务必传入第五个参数 true,否则返回结果很可能与预期不符。
这类细节问题往往在项目后期才暴露——当数据量增长、ID 值出现类似前缀时,如果测试用例未能覆盖该场景,生产环境中就会悄无声息地返回错误的记录行。排查难度也较大,因为从上层接口调用来看,并未抛出任何异常。
总结:findRecord 方法默认采用正则子串匹配,而非严格相等。如果需要进行精确查找,请明确设置 exactMatch: true。
