Description
群友：
”除非提供非常大的便利，才能单独建立一种新的技术体系。“
作者：
对，至少要提升 1 倍，才能覆盖 学习成本(约 10%，看文档、跑 Demo 等) + 迁移成本(约 30%，改用新的库 API、工具链、开发流程等) + 风险成本(约 60%，万一不行还得再迁回去重新用以前的方式去做)。
为了对比方便，以下
APIJSONBoot 指 Spring+SpringBoot+APIJSON，
SSM 指 Spring+SpringBoot+Mybatis(且允许配套 PageHelper 等简化 分页 和简单 CRUD 的插件以及生成代码工具)，
SSH 指 Spring+SpringBoot+Hibernate/JPA 等 ORM 库，
SSMH 指 SSM + SSH。
(注：业内 SSM, SSH 通常分别指 Spring+SpringMVC+Mybatis, Spring+Struts+Hibernate，
但 SpringMVC 和 Struts 目前在大部分场景都已被 SpringBoot 包含或取代)
假设表数量为 T， 字段数量为 C，不考虑业务逻辑处理(业务逻辑代码处理基本一致，两者用时相当)，
APIJSONBoot 在 适用场景 的项目中一般都是 20 倍以上的开发效率提升：
平均 2 分钟配置好一张表的增删改查权限，即可实现各种条件( C! x 每个字段 28 种条件功能 x @combine 与或非 3 种 x 2^C 组合数 的 单表单记录 + 单表多记录 + 结合已配置过权限的其它表各种排列组合 ( T! 个) 总共 C! x 28 x 3 x 2^C x T! 个 细粒度 RESTful 查询接口，
再花 3x1xC 分钟配置增删改校验规则，即可相当于实现了 单表单记录+单表多记录 总共 2xT 个 RESTful 增删改接口，总共用了 2xT + 3xC 分钟开发，然后花最多 5 分钟调热更新接口来热重载配置即可部署生效；
假设一个开发很熟练地同样实现 APIJSONBoot 总共 2xT + 3xC 分钟实现的各种增删改查功能，用 SSMH 实现 RESTful API，并且还不做任何权限及参数校验，那么
查询需要 平均每表 30 分钟完成单表不带查询条件的 Controller, Service, Mapper, DTO/VO/BO …，加每个字段 28 个功能 x C， 60 分钟完成一个多表关联查询接口，总共 30xT + 28xCxT + 60x2^T 分钟)，
增删改(假设用了 PageHelper, Mybatis-Plus 等免写 SQL 封装工具) 需要 每张表在写查询接口实现过的 Controller, Service 中新增对应的 3x2 个方法，约 5 分钟，总共 5xT 分钟，然后假设没冲突且不出错的情况下 推送、合并代码，再顺利重启服务部署到开发/测试环境，一般最快也要 10 分钟。
总结下，只是完成接口开发和自测，不算部署时间，
APIJSONBoot(按慢估计) 相比 SSMH(按快估计) 这种传统方式开发总时间对比为：
(2xT + 3xCxT) : (30xT + 28xCxT + 60x2^T + 5xT)
简化为：
(2xT + 3xCxT) : (35xT + 28xCxT + 60x2^T)
假设需要对 1 张表(3 个字段)开发接口，即 T = 1, C = 3 ，那么总时间对比为
11 min(约十分钟) : 239 min(3.98 小时，约一上午)，速度提升 20.73 倍！
假设需要对 5 张表(平均每张表 4 个字段)开发接口，即 T = 5，C = 4，那么总时间对比为
70 min(约一小时) : 44.25 hour(朝九晚六 5.53 天，约一星期)，速度提升 36.93 倍！
假设需要对 10 张表(平均每张表 10 个字段)开发接口，即 T = 10，C = 10，那么总时间对比为
320 min(约一上午) : 44.85 day(996 工作 3.45 月，约一季度)，速度提升 200.84 倍！
假设需要对 20 张表开发接口(平均每张表 15 个字段)，即 T = 20，C = 15，那么总时间对比为
940 min(约上班两天) : 1456.57 month(全年无休 11117 工作 239.44 年，接近美国建国至今 243 年！)，速度提升 66,939.06(约 7 万) 倍！
假设需要对 50 张表开发接口(平均每张表 20 个字段)，即 T = 50，C = 20，那么总时间对比为
3100 min(约上班一周) : 128527386625.93 year(时刻工作、一秒不停也要 1285 亿年，超过宇宙年龄 138.2 亿年！)，速度提升 21791611100189(21 万亿) 倍！
为什么表数量越多，开发总时间差距会指数暴增呢？
因为 APIJSONBoot 支持任意表关联组合查询，把 SSMH 随表数量指数暴增的 RESTful API 开发时间 降到了线性稳定增长！
为什么后面 SSMH 开发 20 张表 CRUD 接口的时间需要几百年，50 张表甚至超过宇宙年龄了，实际上也就几个月开发完了啊？
因为实际上需求并不会覆盖 表的所有 CRUD、 表的所有排列组合、字段的所有条件、字段的所有组合。
因为主要是表排列组合导致了指数暴增，所以我们再根据实际情况，把 表的所有排列组合 减少至常规的 两两 排列组合，
那就只有 T! / (T - 2 )! 种情况，SSMH 开发 RESTful API 的公式变为：
(35xT + 28xCxT + 60xT! / (T - 2 )! )
而 APIJSONBoot 的公式不变，所以对比为：
T = 1 时：11 : 179
T > 1 时：(2xT + 3xCxT) : (35xT + 28xCxT + 60xTx(T - 1) )
简化为：
T = 1 时：11 : 179
T > 1 时：Tx(3xC + 2) : Tx(60xT + 28xC - 25)
按照一般互联网中小型项目情况可得出以下对比表格：
| 表数量 T | 平均每表字段数 C | SSMH 按快估计 | APIJSONBoot 按慢估计 | APIJSONBoot 提速倍数 |
|---|---|---|---|---|
| 1 | 3 | 179 min(约一上午) | 11 min(约十分钟) | 15.27 |
| 5 | 4 | 1935 min(约朝九晚六一周) | 70 min(约一小时) | 26.64 |
| 10 | 10 | 8550 min(大小周超半个月) | 320 min(约一下午) | 25.72 |
| 20 | 15 | 31900 min(约 996 两个月) | 940 min(约上班两天) | 32.94 |
| 50 | 20 | 176750 min(11117 超半年) | 3100 min(约上班一周) | 56.02 |
这还是在 APIJSONBoot 实现了权限和参数校验、SSMH 不做权限和参数校验的情况下！
如果 APIJSONBoot 也不做权限和参数校验(全局关闭)，那么根本不用花任何时间，总时长总是 0 ！