Elasticsearch 脚本报错要先判断阶段：请求还没解析成功，和脚本已开始运行却遇到类型错误，是两种不同问题。下面对应 ES 7.3 的两次使用记录。

file 参数无法解析：改用 source 或存储脚本 id

遇到：

[script] unknown field [file], parser not found

不能只换一个文件路径。ES 7.3 的脚本结构使用 source 提供内联代码，或使用 id 引用已经注册的存储脚本，变量通过 params 传入。ES 7.3 脚本用法

例如在隔离测试环境注册一个价格增量脚本：

POST /_scripts/example-add-price
{
  "script": {
    "lang": "painless",
    "source": "ctx._source.price += params.delta"
  }
}

再对已有测试文档调用：

POST /example_products/_update/1
{
  "script": {
    "id": "example-add-price",
    "params": { "delta": 22 }
  }
}

前提是 price 已存在且为合适的数值。注册脚本会修改集群状态，更新请求会改文档；不能拿生产数据试错。重复提交增量更新还会再次累加，应结合业务设计并发和重试规则。

列表追加：不要把字符串加到列表上

另一次文档中的 tags 是列表，写成下面的表达式时报类型转换错误：

ctx._source.tags += params.new_tag
Cannot cast java.lang.String to java.util.ArrayList

对于确实存在的列表，追加一个元素应使用 add：

POST /example_products/_update/1
{
  "script": {
    "lang": "painless",
    "source": "ctx._source.tags.add(params.tag)",
    "params": { "tag": "example" }
  }
}

add 不会自动去重；重复请求也可能重复添加。若字段缺失、为 null 或历史值是字符串，应先明确初始化或数据清理策略，不要在一个脚本里静默猜测数据含义。ES 7.3 Update API

先确认输入，再改表达式

读取目标文档的脱敏 _source，核对脚本实际看到的值。mapping 的字段类型并不等于所有文档的 JSON 容器形态一致，也不能代替检查历史数据。

把请求结构、字段类型和业务操作分开，才能判断应该改 API 写法、修复文档，还是改变更新逻辑。不应根据一条旧记录推断所有 5.x 与 7.x 版本的兼容行为。