MES中UEditor集成Excel数据验证：Web表格即时校验实战

1. 为什么MES要调用UEditor的Excel数据验证：一个真实的生产管理痛点

先聊个场景。我在产线信息化项目里做了七八年，几乎每个客户都会提一个看似不起眼的需求：工艺参数录入时，能不能别让操作工随便填？比如温度不能超过85度，速度必须是整数，料号长度固定是10位。在传统MES（制造执行系统）里，这个需求通常靠后端接口写校验逻辑实现，前端页面发请求，后端返回“数据不合法”，流程上没问题，但体验真的很差——操作工填慢了产线等，填错了整批报错返工，反馈还慢。

后来接触到一种思路：把Excel里那套“数据验证”（Data Validation）规则搬到Web端，直接在浏览器里限制用户输入。而百度WEB编辑器（也就是UEditor），在很多老牌MES项目里承担着工艺文档、作业指导书、异常记录这些富文本内容的编辑入口，天然就是“人机交互的最近一环”。问题来了：MES系统如何才能调用百度WEB编辑器，让它在编辑表格内容时具备Excel的数据验证能力？

先说我的结论：这不是一个“傻瓜式API调用”的问题，而是一个典型的“富文本编辑器 + 表格数据 + 校验规则”三层次集成问题。你要理解UEditor的渲染机制、理解Excel数据验证的底层模型，还要在两者之间架一座桥。这篇文章我会把这套方案的完整拆解写出，包括为什么要这么设计、核心代码怎么写、上线后容易踩的坑是什么，全程都是实战经验，不是理论空转。

在动笔前，我梳理一下这套方案的适用人群：如果你是MES开发工程师、智能制造项目实施顾问，或者你在做生产管理系统时被“Web端表格数据校验”折磨过，这篇内容应该对你有参考价值。即使你用的是其他富文本编辑器（比如CKEditor、wangEditor），底层思路同样通用。

2. UEditor和Excel数据验证的核心机制：先搞清楚两个“黑盒”各自能干吗

2.1 UEditor到底是怎么处理表格的

UEditor虽然是百度早年开源的老牌富文本编辑器，但它做表格的能力比很多人想象中强。它内置了table的插入、合并拆分单元格、设置宽高、背景色等操作，生成的是标准的HTML table结构。在MES场景里，工艺文档中嵌入表格用来填参数、排工序、列物料清单非常常见。

但问题也出在这：UEditor对表格内容的处理，走的是“内容可编辑（contenteditable）”路线，也就是说，用户在编辑器里看到的是一个可编辑的HTML文档，在编辑器内部，所有表格单元格都是<td>或<th>元素，它们的文本内容可以被任意修改，没有任何原生约束。

最直观的体验差异在哪里？在Excel里，如果你给A列设置了“整数，介于1到100”的数据验证，用户填入101，Excel立刻弹窗提示“此值与此单元格定义的数据验证限制不匹配”。但在UEditor里，你填入什么它都接受，因为编辑器不关心你的业务规则。

所以第一个关键认知是：我们要实现的目标，不是在UEditor外部套一层表单校验，而是要让编辑器内部的table，在用户编辑时就能感知Excel式的数据验证规则并在输入前或输入时拦截。

这里有个容易误入的歧途——很多开发者的第一反应是“给UEditor加一个beforeSubmit钩子，提交时校验”，但这对MES来说远远不够。生产录入的场景要求即时反馈：操作工填完一个格里温度90度，界面应该立刻就提示“超出上限85”，而不是等整篇文档保存时才报错。后面你会看到，这就是我们选择监听UEditor内部DOM事件的直接原因。

2.2 Excel数据验证的规则模型：本质是一组“区间+类型+公式”约束

Excel的数据验证（旧版本叫数据有效性）看起来只是几个下拉菜单和弹窗，但它背后其实是一个完整的规则模型。搞清楚这个模型，对我们在Web端设计JSON Schema非常有帮助。

拆开来看，Excel数据验证由三要素组成：

• 验证类型（Validation Type）：整数、小数、日期、时间、文本长度、自定义公式等。
• 条件运算符（Operator）：介于、不介于、等于、不等于、大于、小于、大于等于、小于等于。
• 公式或列表源（Formula/List Source）：直接值、单元格区域引用、命名区域、自定义公式（如=AND(A1>0, A1<100)）。

举个实际例子，如果我在Excel里设置某个单元格“允许=整数，数据=介于，最小值=1，最大值=100”，那么翻译成我们Web端要用的JSON就是：

json复制{
  "type": "integer",
  "operator": "between",
  "min": 1,
  "max": 100,
  "message": "请输入1到100之间的整数"
}

这里我把Excel的“介于”拆成min和max两个字段，是为了方便前端直接比较。你还可以扩展list类型，对应Excel的“序列”验证，比如指定只能选“待检、合格、不合格”：

json复制{
  "type": "list",
  "source": ["待检", "合格", "不合格"],
  "message": "请选择合格状态"
}

理解了这套模型，你就会发现：我们要做的“在Web端还原Excel数据验证”，本质上就是把上面这种JSON规则，绑定到UEditor内部某个具体单元格（td元素）上，然后在用户输入时按规则执行校验。

2.3 为什么不能直接用Excel的“sheet.js”方案把整个表格转来转去

很多做MES的同事一听到“Excel数据验证”，本能反应是：那我把UEditor里的表格转成Excel对象，用SheetJS（xlsx库）校验完后导回去不就行了吗？这个思路听起来优雅，实际操作非常坑。

一方面，UEditor的表格数据转成Excel再转回来，格式必然有损，而且这是一次“全量转换”，用户输入一个数字就要全表序列化一次，性能差。另一方面，MES现场有很多并发编辑场景，频繁转换会让整个编辑器卡顿，操作工体验会非常糟糕。

所以我的推荐路线是：放弃“文件级校验”，改为“DOM级校验”。 让数据验证规则直接作用在UEditor内部渲染出来的td元素上，利用UEditor的交互事件在数据进入编辑器内容的同时完成拦截。这是性能最优解，也是商业软件和自研MES差距最大的地方。

3. MES调用UEditor实现Excel数据验证的整体方案：架构设计与数据流

3.1 分层架构：规则层、绑定层、校验层、反馈层

我的方案不是去改UEditor源码，而是在它之外加一套轻量级插件体系。整体分为四层，每一层职责单一：

第一层，规则层。MES后端的工艺路线、质量规范、设备参数中会产出大量数据验证规则，比如“温度：整数介于60到85”“料号：文本长度10”“速度：整数大于等于0小于等于3000”。这些规则统一通过REST接口下发到前端，前端维护为一个Map结构，key是表格的“区域标识”，value是规则集合。

第二层，绑定层。HTML表格渲染完成后，根据规则中的“行列偏移量”或“单元格ID规则”，将验证规则绑定到对应的td元素上。这一步我会利用UEditor的interact事件或者MutationObserver完成动态绑定。

第三层，校验层。监听UEditor的keyup、blur、paste事件，当用户修改td内容时，读取该td绑定的规则，执行校验。校验通过则放行，不通过则回滚或提示。

第四层，反馈层。UEditor底层用iframe承载可编辑区域，所以反馈提示不能直接调用浏览器原生alert，那会打断编辑体验。我采用的方式是注入一个tooltip浮层，在单元格附近显示红框和错误信息，并在编辑器底部显示一条汇总状态栏。

四层各司其职，层与层之间用事件解耦。下面是完整的数据流：

• MES后端返回规则JSON → 前端规则层加载并索引。
• UEditor渲染表格 → 绑定层扫描table，给td打上规则标记，并写入data-vrule-id。
• 用户在表格内输入 → 校验层捕获输入事件，读取规则JSON，比对数据，返回校验结果。
• 校验失败 → 反馈层展示提示，阻止内容提交到编辑器内部。
• 保存时 → 再执行一次全量校验，防止绕过事件监听的历史数据混入。

3.2 iframe带来的跨文档操作：你必须绕过UEditor的封装

UEditor编辑区是放在iframe里的，很多做集成的人习惯用UE.getEditor('container')获取编辑器实例，但如果你想把外部规则绑定到iframe内的td元素上，直接用外部DOM的document.querySelector是不行的，你必须拿到iframe的contentDocument。

这里比较推荐的做法是：在UEditor的ready回调里，通过实例的iframe属性拿到内部document。注意，UEditor不同版本的属性名略有差异，通常可以用editor.iframe或editor.document来获取，然后在这个document上做事件监听。

有了内部document引用后，绑定表格规则就顺理成章了：

javascript复制const iframeDoc = editor.iframe.contentDocument || editor.document;
const table = iframeDoc.querySelector('table');

3.3 规则如何从MES后端传递到UEditor前端

规则下发有两种方式：静态配置和动态接口。MES项目里通常用动态接口，因为工艺参数会随产品、版本变化。我习惯定义这样一个接口结构：

json复制{
  "templateId": "PROCESS_OP100",
  "rules": [
    {
      "cell": "B2",
      "validation": {
        "type": "integer",
        "operator": "between",
        "min": 60,
        "max": 85,
        "onError": "block",
        "message": "温度超出工艺范围：60~85℃"
      }
    },
    {
      "cell": "C2",
      "validation": {
        "type": "list",
        "source": ["待检", "合格", "不合格"],
        "onError": "warn",
        "message": "请选择正确的质量状态"
      }
    }
  ]
}

其中cell字段用的是Excel风格的单元格地址（B2表示B列第2行），因为MES工艺人员最熟悉的表格地址就是这种格式，后端生成规则也容易。前端拿到规则后，解析成行号和列号，再映射到iframe里table的td元素上。

可能你会问：为什么不直接约定一个规则ID字段，非要转Excel地址？因为MES的工艺模板本身就是从Excel导入到UEditor里的，单元格地址是唯一能够跨系统对齐的“通用语言”，这样后续如果有WPS、网页版本表格软件参与协作，规则映射也不会乱。

4. 代码级实战：如何让UEditor的单元格实现“输入即校验”

4.1 准备MES环境的UEditor基础配置

假设你已经把UEditor集成到MES系统里了，这里不再赘述基础部署。但在做数据验证之前，一定要确保UEditor用的是无刷新提交模式，并且关闭了自动转义和内容过滤，否则你塞进去的JSON规则标记会被编辑器过滤掉。

我实际项目中用的是UEditor 1.4.3版本，初始化配置如下：

javascript复制UE.getEditor('mesEditor', {
  initialFrameHeight: 480,
  autoHeightEnabled: false,
  wordCount: false,
  elementPathEnabled: false,
  filterTxtRules: {
    'td': function (node) {
      // 保留自定义属性
      return node;
    }
  },
  // 关闭自动转义，保留我们注入的HTML
  retainOnlyTags: 'p,br,table,tr,td,th,div,span',
});

retainOnlyTags这行非常关键，在我的项目中，不设置这个字段，编辑器会默认过滤掉我们绑定规则时写入的自定义属性，比如data-vrule-id。如果你用的版本不支持这个字段，建议在ready回调后重新处理一次属性，或者在内容提交时再从数据模型里还原规则。

4.2 规则绑定模块：把后端JSON变成DOM属性

核心思路是：在UEditor内容渲染完成之后，扫描所有table，然后根据我们预设的模板编号，去匹配规则。

先定义一个规则管理者对象：

javascript复制class ValidationRuleManager {
  constructor() {
    this.rulesMap = {};
  }

  // 从后端加载规则
  async loadRules(templateId) {
    const res = await fetch(`/api/mes/validation/${templateId}`);
    const data = await res.json();
    this.rulesMap[templateId] = data.rules;
    return this.rulesMap[templateId];
  }

  // 根据Excel地址返回行列
  parseCellAddress(cell) {
    const match = cell.match(/^([A-Z]+)(\d+)$/);
    if (!match) return null;
    const colStr = match[1];
    const row = parseInt(match[2], 10);
    let col = 0;
    for (let i = 0; i < colStr.length; i++) {
      col = col * 26 + (colStr.charCodeAt(i) - 64);
    }
    return { row: row - 1, col: col - 1 };
  }

  // 绑定某张表格
  bindRulesToTable(tableEl, rules) {
    for (const rule of rules) {
      const { row, col } = this.parseCellAddress(rule.cell);
      const cellEl = tableEl.rows[row]?.cells[col];
      if (!cellEl) continue;
      cellEl.setAttribute('data-vrule-id', rule.validation.type + '_' + row + '_' + col);
      cellEl.dataset.vruleJson = JSON.stringify(rule.validation);
      // 视觉提示，给“受控单元格”一个醒目的标识，方便操作工识别
      cellEl.style.outline = '2px dashed #2E75B6';
    }
  }
}

这段代码有三个细节值得注意。

第一，parseCellAddress把Excel地址从1开始的行列，转换成从0开始的数组索引，必须做减一处理。很多踩坑案例都是因为这个没处理好，导致规则绑到隔壁单元格上。

第二，我用data-vrule-id作为唯一标识，data-vrule-json存储完整规则。这样校验时不需要再查Map，直接从DOM上取规则，性能好，而且规则随内容走，复制粘贴也不会丢。

第三，给受控单元格加上虚线边框，纯粹从车间操作角度考虑。生产环境里，工人不会关心你后台规则怎么设计的，但你给他一个视觉边界，他就知道这个格子“受到约束”，输入时会下意识留意提示。

4.3 核心校验逻辑：三个事件搞定99%的输入场景

绑定完规则后，真正的挑战在事件拦截。我最终实现里监听三个事件：beforepaste、keyup、blur。为什么不监听input？因为input事件在iframe里的兼容性以及中文输入法组合输入状态下会频繁触发，容易误判。

keyup负责逐字符即时反馈；blur负责最终校验兜底，防止用户输完直接切走；beforepaste负责拦截外部粘贴的脏数据。

核心校验函数的思路如下：

javascript复制function validateCell(tdEl) {
  const ruleJson = tdEl.dataset.vruleJson;
  if (!ruleJson) return true;
  const rule = JSON.parse(ruleJson);
  const cellValue = tdEl.innerText.trim();
  if (cellValue === '') return true; // 空值是否允许，可以根据rule里allowBlank字段判断
  
  const result = executeValidation(cellValue, rule);
  return result;
}

function executeValidation(value, rule) {
  const message = rule.message || '输入不合法';
  switch (rule.type) {
    case 'integer': {
      const num = Number(value);
      if (isNaN(num) || !Number.isInteger(num)) {
        showValidationMessage('请输入整数');
        return false;
      }
      if (rule.operator === 'between') {
        if (num < rule.min || num > rule.max) {
          showValidationMessage(message);
          return false;
        }
      }
      return true;
    }
    case 'decimal': {
      const num = Number(value);
      if (isNaN(num)) {
        showValidationMessage('请输入数字');
        return false;
      }
      if (rule.operator === 'between' && (num < rule.min || num > rule.max)) {
        showValidationMessage(message);
        return false;
      }
      return true;
    }
    case 'textLength': {
      if (value.length < rule.min || value.length > rule.max) {
        showValidationMessage(message);
        return false;
      }
      return true;
    }
    case 'list': {
      if (!rule.source.includes(value)) {
        showValidationMessage(message);
        return false;
      }
      return true;
    }
    default:
      return true;
  }
}

这里需要特别强调一下“回滚”策略。在keyup事件中如果校验失败，我们不能直接把用户输入清空，那是极度糟糕的交互。我的做法是：输入内容允许“暂时留下”，但立刻在单元格右下角弹一个红色小箭头，同时在底部状态栏显示错误原因；只有在blur时才真正回滚到上一次合法值。

我用一个lastValidValue变量保存每个受控单元格上一次校验通过的值：

javascript复制tdEl.addEventListener('focus', function () {
  tdEl.dataset.lastValid = tdEl.innerText;
});

tdEl.addEventListener('keyup', function () {
  const valid = validateCell(tdEl);
  if (!valid) {
    markCellInvalid(tdEl);
  } else {
    tdEl.dataset.lastValid = tdEl.innerText;
    clearCellInvalid(tdEl);
  }
});

tdEl.addEventListener('blur', function () {
  const valid = validateCell(tdEl);
  if (!valid) {
    tdEl.innerText = tdEl.dataset.lastValid || '';
    clearCellInvalid(tdEl);
    showValidationMessage('已恢复上次合法值：' + tdEl.dataset.lastValid);
  }
});

这套逻辑的好处是：操作工输入过程中看到红色提示，就知道当前值有问题，但如果他只是临时改一下准备后面修改，也不会被强行打断；一旦离开单元格，系统自动回滚，保证填入数据库的永远是合法数据。

4.4 粘贴事件的拦截：Excel复制到UEditor中的脏数据过滤

生产车间的操作工有一个非常普遍的操作习惯：从Excel里复制一整列参数，直接粘贴到UEditor的表格里。这种情况下，粘贴进来的数据往往是带有换行符、制表符，甚至Excel的单元格样式，一些非法值也会被悄然混入。

UEditor自带粘贴过滤，但不会按我们的验证规则逐单元格校验。我实现的方式是：在beforepaste事件中，手动读取剪贴板纯文本，进行切分后逐格校验，校验不通过的直接拦截整个粘贴操作，并提示用户“第3行数据超出范围”。

javascript复制iframeDoc.addEventListener('beforepaste', function (e) {
  const clipboardData = e.clipboardData || window.clipboardData;
  if (!clipboardData) return;
  const text = clipboardData.getData('text/plain');
  // 按行切分，再按制表符切分
  const rows = text.split(/[\r\n]+/).filter(r => r.trim() !== '');
  // 找到当前选中单元格
  const selectedTd = getSelectedCell(iframeDoc);
  if (!selectedTd) return;
  const startRow = selectedTd.parentNode.rowIndex;
  const startCol = selectedTd.cellIndex;
  
  for (let i = 0; i < rows.length; i++) {
    const cols = rows[i].split('\t');
    for (let j = 0; j < cols.length; j++) {
      const targetRow = startRow + i;
      const targetCol = startCol + j;
      const targetTd = getCellByIndex(table, targetRow, targetCol);
      if (targetTd && targetTd.dataset.vruleJson) {
        const valid = executeValidation(cols[j].trim(), JSON.parse(targetTd.dataset.vruleJson));
        if (!valid) {
          e.preventDefault();
          showValidationMessage(`粘贴数据第${i + 1}行，第${j + 1}列不合法：${cols[j].trim()}`);
          return;
        }
      }
    }
  }
});

注意，getSelectedCell这个函数需要你自己维护，因为UEditor有选区，选中的可能是多行或多列，这里我简化成取选区起始单元格。如果粘贴的面积覆盖多行，并且表格提前有合并单元格，这种处理方式会有点粗糙，但实际MES表格模板里，受控单元格区域一般不会和合并单元格重叠，所以线上使用是稳妥的。

4.5 批量校验与保存前检查

事件监听解决了“输入时校验”，但MES项目的数据安全要求通常更高——即便前面校验全部通过，保存前还必须全表扫描一遍，防止通过编辑器其他入口（比如全选后拖拽）把数据改动带进来。

我在UEditor的save按钮回调里，在getContent()之前执行以下逻辑：

javascript复制function validateAllTable() {
  const iframeDoc = editor.iframe.contentDocument;
  const tables = iframeDoc.querySelectorAll('table');
  let hasError = false;
  for (const table of tables) {
    const rules = getRulesFromTable(table);
    for (const rule of rules) {
      const tdEl = table.rows[rule.row]?.cells[rule.col];
      if (!tdEl) continue;
      const result = validateCell(tdEl);
      if (!result) {
        hasError = true;
        tdEl.style.background = '#FFC7CE';
        tdEl.scrollIntoView({ behavior: 'smooth', block: 'center' });
        break;
      }
    }
  }
  if (hasError) {
    editor.execCommand('alert', '存在未通过数据验证的单元格，已标红，请修正后再保存');
    return false;
  }
  return true;
}

这里标红用的#FFC7CE是Excel“无效数据”提示的默认背景色，车间人员早就习惯了这个颜色语义，不需要额外解释。

要说坑，这里也有一个：UEditor的execCommand('alert')在部分版本里不存在，你需要用编辑器自带的UI反馈机制，或者直接注入一个控制台警告并聚焦到第一个错误单元格。我的替代方案是调用editor.fireEvent('showmessage', {content: '...'})，前提是你的集成环境中有对应的事件扩展。

5. 实战中的踩坑记录：你可能遇到的“验证失效”和“规则错位”

5.1 UEditor过滤自定义属性：规则绑上去了但一刷新就没了

这是我在现场被坑得最惨的一次。最早版本里，我用jQuery往td上写了attr('vrule', '...')，保存后面板内容到数据库，再重新加载时规则全部丢失。排查了大半天，发现是UEditor在getContent时会走内部的HTML过滤规则，不认识的属性和标签统统会被扒掉。

解决方案就是我前面提过的，在初始化配置里设置retainOnlyTags，同时针对自定义属性做保留。UEditor 1.4.x还提供了getContent回调，你可以在返回内容前把td上的data-*属性手动拼接成内联属性，确保输出DOM时不会被格式化步骤清掉。如果是更复杂的内容，我会先把验证规则抽离成非HTML结构，比如在表格末尾塞一个隐藏的<meta data-vrules>节点，保存时解析它，回显时再转化为td属性。

5.2 合并单元格导致的行列错位

MES工艺模板里，表头经常会有“合并单元格”，比如“设备参数”横跨两列。用table.rows[row].cells[col]访问时，合并单元格会占据多个列索引，你按照Excel逻辑数到的第二列可能实际上是第三列的cell。

这里没有一个通用的自动解决方案，我的做法是：规则配置时禁止“受控单元格跨列合并”，前端在绑定规则前做一次行列映射清洗，把跨列的单元格映射回其实际起始列。如果后端下发的规则落到了合并区域内，前端自动忽略并打日志告警。这个方案在项目里稳定运行很久，工艺人员也接受了“被规则控制的格子不能合并”的约定。

5.3 输入法组合输入的误报

操作工里有不少用中文输入法的，他们输入数字时也可能是通过中文输入法按Shift切到半角，这个过程中keyup事件会在输入法组词时也触发。如果在输入法组词阶段就执行校验，你的数字可能还没完整输入就已经被判定非法，导致操作工根本打不进完整数值。

解决办法是：监听compositionstart和compositionend事件，在组合输入期间跳过校验。只有当compositionend触发后才做一次完整校验。

javascript复制let isComposing = false;
tdEl.addEventListener('compositionstart', function () {
  isComposing = true;
});
tdEl.addEventListener('compositionend', function () {
  isComposing = false;
  validateCell(tdEl);
});
// keyup / blur事件中第一行先判断
if (isComposing) return;

这个问题在MES车间特别容易碰到，因为产线上不乏年纪稍大的操作工，拼音输入法使用很频繁。做Web校验时没有兼容输入法，基本上线第一天就会被投诉。

5.4 表格被增删行后规则如何跟随

UEditor里用户可以通过右键菜单插入行、删除行。如果新增了一行，原来绑在第5行的规则要不要自动迁移？在MES场景里，这个问题没有绝对统一的答案。

我的策略是：以模板行号为基准，受控单元格绝对定位。规则绑定到第5行第2列，它就是第5行第2列，新增行不迁移规则；但新增行如果复制了上一行的内容和样式，新行里的td会继承data-vrule-json属性，相当于复制了规则。这个行为需要在上线前跟工艺人员确认清楚，否则会出现“两个格子都弹错，但找不到谁在管”的困惑。

5.5 性能考虑：几百个受控单元格的UEditor会不会卡

MES大型工艺文档中，一张表格可能有上百个受控单元格。如果每个td都绑定单独的keyup事件，性能开销虽然不至于让浏览器崩溃，但刷新时的事件绑定耗时会增加。

更优的做法是事件委托：只在iframe的document上绑定一个keyup监听，通过事件冒泡判断target是不是td，再读取规则执行校验。这样不管多少个单元格，事件监听数量都只有几个。

javascript复制iframeDoc.addEventListener('keyup', function (e) {
  const tdEl = e.target.closest('td');
  if (!tdEl || isComposing) return;
  // 读取规则、校验
  const ruleJson = tdEl.dataset.vruleJson;
  if (!ruleJson) return;
  // ...
});

这类优化在初始版本不用做太早，但当规则数量超过200个之后，你会明显感觉到“输入每个字符都卡一下”。我建议从第一版开始就采用事件委托模式，避免后期重构。

6. 从“能用”到“好用”：数据验证在MES场景中的进阶玩法

6.1 下拉序列在UEditor单元格内的实现

Excel数据验证最常用的功能之一就是下拉选择。在Web表格里，我实现了一个轻量级的下拉选择器：当单元格规则为list类型时，用户点击单元格右侧会出现一个小箭头，点击后弹出候选值列表，选择后填充进td。

这个功能的实现并不复杂，核心是：

javascript复制tdEl.addEventListener('click', function (e) {
  const rule = JSON.parse(tdEl.dataset.vruleJson);
  if (rule.type !== 'list') return;
  // 创建候选浮层
  const dropdown = iframeDoc.createElement('div');
  dropdown.className = 'mes-validation-dropdown';
  rule.source.forEach(item => {
    const option = iframeDoc.createElement('div');
    option.innerText = item;
    option.addEventListener('click', function () {
      tdEl.innerText = item;
      validateCell(tdEl);
      iframeDoc.body.removeChild(dropdown);
    });
    dropdown.appendChild(option);
  });
  // 定位到单元格下方
  const rect = tdEl.getBoundingClientRect();
  dropdown.style.top = rect.bottom + 'px';
  dropdown.style.left = rect.left + 'px';
  iframeDoc.body.appendChild(dropdown);
});

注意，浮层一定要追加到iframe的document里，而不是外部页面，否则定位和点击事件会跟UEditor的编辑区域相互干扰。如果需要支持关闭浮层，在外部document点击时也得做处理，简单方案是给外部window绑定一次点击，如果点击目标不在浮层内就移出浮层。

6.2 跨日期、跨工序的公式验证

懂Excel数据验证的人都知道，规则不一定是固定区间，还可以用公式。比如“当前机台加工速度不能超过该设备额定速度×1.2”，这里的额定速度在另一张表里。

在MES里，我通过扩展规则类型实现formula类型：

json复制{
  "type": "formula",
  "expression": "return $speed <= $ratedSpeed * 1.2;",
  "message": "加工速度超过设备额定速度的120%"
}

前端执行时，$speed就是当前单元格值，$ratedSpeed通过变量替换从页面隐藏域读取。这种实现方式本质上是“受限的JavaScript表达式执行”，需要注意安全性——不能允许任意代码执行，我内部是用了一个极简的表达式解析器，只支持数字、运算符、变量名，不开放函数调用。

实际效果相当不错。MES里的设备参数、工艺参数，很多都是“百分比、系数、偏差值”的组合关系，用固定区间很难完全覆盖，公式验证补齐了这个短板。

6.3 规则验证状态的可视化：状态栏 + 单元格角标

判断一套校验功能好不好用，不能只看拦截率，还要看操作工买不买账。我在第二个MES项目上线时发现，操作工对“被拦截输入”是有抵触心理的，他们会觉得“系统像个傻瓜一样不让我填”。

后来我加了一个软性的可视化反馈机制：校验通过的单元格，右下角显示一个绿色小圆点；校验失败的单元格，显示红色感叹号。底部状态栏实时显示“已通过验证 12/15，还有 3 个未通过”。这样操作工能看到自己的进度，而不是凭空被弹窗打断。这个细节让MES现场验收的满意度提升了不少，一线班长甚至主动要求把色点样式调大一点。

7. 方案落地后的思考与扩展建议

说实话，UEditor这个老编辑器在MES行业里有大量存量部署，短期内替换成新版编辑器不现实。所以我的所有实现，都刻意没有动UEditor的核心源码，全部以外部插件的形式完成。这套方案的架构可以平移到任何富文本编辑器上。

从更长远的角度看，MES系统里的表格数据验证不应该只停留在“编辑器内约束输入”的层面，它应该和MES的“工艺规则引擎”打通：比如某条规则被触发三次以上，系统应该记一条操作异常日志；或者某个操作工多次输入超出范围，应该触发培训提醒。这些数据远比“拦截一次非法输入”有价值。

我在最新的项目里，已经把校验事件统一通过MQTT协议推送到MES的事件中心，和质量追溯系统联动。当某个单元格校验失败又被回滚时，事件中心会记录一条质量事件，后续可以做SPC统计过程控制。如果你所在团队有精力，强烈建议把这层“校验元数据”采集起来，它是智能制造数据中台里非常独特的一类数据源。

另外想说一点关于团队协作的事。这类“编辑器集成”改动的测试，非常依赖真实的车间数据。我第一次上线时只在测试环境跑了几百条Excel数据，感觉没问题，一上线就遇到了粘贴年份日期格式的问题——Excel里复制出来的日期是2025/1/15，而MES要求的是2025-01-15。所以后来我在测试计划里固定加入一条“模拟粘贴”用例，每次发版前必须跑一遍。如果你正在做类似集成，可以把这条经验直接抄走。

这套方案从设计到稳定运行，前前后后改了三版，目前在我们负责的几个MES站点已经跑了两年，累计拦截非法工艺数据上万次。中间踩过的坑不少，但整体收益非常明确：操作工录入速度没有因为校验变慢，数据库质量却提升了一个量级。希望这篇总结能帮你少走几段弯路。