我是搞电子政务方面的，广州这边很多电子政务都是低代码处理了，除了比较复杂的表单需要自定义代码逻辑外，甚至还支持文书类型。不过目前定制化程度较高的，还是不能脱离代码，但是按照目前的发展情况，后续能不能完全替代说不准了。我是想过 AI+低代码的一个项目，能不能通过与 AI 图文沟通直接搭建项目出来，虽然目前有点异想天开，但是往后这个方向应该还是会有不少人做

@JasonLaw 不想走反射的话，如果业务量就是那么少，if else 是没问题的，如果后续可能要拓展成多种情况，可以考虑定义一个抽象类和相关的一个入口方法以及钩子方法，以及针对不同类型定义相关的策略对象类，这些策略类可以直接继承上面提到的抽象类并实现钩子方法，然后在抽象类的入口方法里面做一个判断处理最终调用

@Alphones 忘了补充上面反射的用法，具体参考如下
Method put = DataContainer.class.getMethod("put", testCase[0].getClass(), testCase[1].getClass());
put.invoke(container,k,v);

方法名字没必要区分 putStr 或者 putInt ，都叫 put

public void put(String k, String v) {
map.put(k, v);
}

public void put(String k, Integer v) {
this.put(k,String.valueOf(v));
}

标记一下

@roseduan 好的 我看看

就是因为这样所以才讨厌改需求，所以实际设计数据库过程，都会考虑增加备用字段，如果是有类似于经常改动的需求，就用非关系型数据库完事