Elasticsearch Painless脚本无法匹配大于3的整数字符串问题求助

• 核心问题出在脚本的正则校验规则上：原有使用的 /[0-9]+\.[0-9]+/ 模式强制要求字符串必须包含小数点，且小数点前后至少有1位数字，这类规则仅能匹配带小数部分的格式（如"10.00"、"14.30"），完全不匹配无小数点的纯整数字符串（如"6"、"8"）。
• 整数字符串在正则校验环节就无法通过判断，直接进入else分支返回false，因此永远无法被检索命中。
• 潜在优化点：原有正则未添加首尾匹配锚点，虽然Painless调用matcher().matches()时默认校验全字符串匹配，但显式添加锚点可以避免后续维护时出现匹配范围歧义。

将正则规则调整为同时支持匹配纯整数、带小数的两类合法数字字符串即可，修改后的完整Painless脚本如下：

def product = doc['value.keyword'].value;
if (Objects.isNull(product)) return false;
// 规则：纯数字开头，小数点+小数段为可选匹配，全串校验
if (params.mustNumber == 1 && /^[0-9]+(\.[0-9]+)?$/.matcher(product).matches()){
  return Double.parseDouble(product) > 3
} else {
  return false
}

• 新规则可以同时覆盖两类数值格式：
  • 纯整数字符串："6"、"8"、"10"、"20" 可正常通过校验，转成Double后执行大于3的判断逻辑，符合预期的文档会被正常检索
  • 原有可正常检索的带小数字符串："10.00"、"14.30" 等格式不受影响，匹配逻辑和原有行为完全一致
• 脚本健壮性提升：因为正则要求全串必须以至少1位数字开头，非数字内容、空字符串、带特殊符号的非合法数字字符串都会被正则拦截，不会触发Double.parseDouble()的类型转换异常，执行稳定性更好
• 适配提示：如果业务场景存在带负号的数值（如"-5"、"-3.2"），可以把正则调整为 /^-?[0-9]+(\.[0-9]+)?$/，增加对前置负号的可选匹配，避免负数值被错误拦截。

内容的提问来源于stack exchange，提问作者fansie