整理了一些可能导致系统运行时报错的场景，希望平台的配置功能规避这些问题发生。
- 表单联动规则
配置表单联动规则时，配置条件会监听对应字段的值变化，配置属性时使用赋值的 action 会导致字段的值变化，当出现“规则 1 监听字段 A 的变化修改字段 B，规则 2 监听字段 B 的变化修改字段 A”这种规则之间相互依赖的场景会导致表单输入异常。
另外，联动规则界面也有性能问题，当配置的联动规则数量过多时，超过十条以上，配置界面卡顿验证，影响配置体验。
- 工作流触发
工作流本身可以触发工作流，例如数据新增时触发工作流，工作流节点中触发数据新增，导致循环执行。这种场景需要添加相关限制，官方最新版本的 demo 是已经有循环次数限制：
- SQL 执行
工作流中的 SQL 节点可以直接执行配置的 SQL 语句，灵活性较高，以下几种场景需要添加提醒或者约束：
- 不允许操作其他数据库的表，只能操作当前应用数据库的表。
- 不允许执行数据库表 ‘Create’, ‘Drop’, ‘Grant’, ‘References’, ‘Index’, ‘Alter’ 等高危操作。
- 执行 delete/update 操作时需要有 where 语句限制范围，或者配置确认时添加二次确认，避免错误配置。
- 执行 select 操作时需要有 limit 限制数量，避免大量查询引起性能问题，或者可以通过环境变量配置，默认给 select 语句添加 limit 限制。
- 查询数据节点
每页条数需要添加最大值限制，避免一次查询过多数据。
页码和每页条数需要校验非法输入，避免异常的 SQL 执行。
- JSON节点
复杂的 JSON 数据计算查询可能有一定的耗时，如果循环节点中，或者查询大量数据后进行 JSON 解析，可能会因为大量计算导致出现应用性能问题。
这里可以考虑根据数据来源和查询表达式复杂度，给与一定的提示。
- 计算节点
类似 JSON 节点，复杂计算耗时可能会导致应用性能问题。
工作流中这种计算节点，是否可以考虑单个节点添加超时限制，避免因为单个节点执行占用过多计算资源。
- 公式字段
使用数据源配置中的公式字段时，也有类似计算节点的问题，如果大量新增数据或更新数据，会导致公式字段进行大量的计算，如果单次计算耗时较高就可能导致出现应用性能问题。
