本文重点在于吐槽垃圾设计，基本直只说缺点。
一.没有static关键字
static其实不是很面向对象，但是是很有必要和方便的。
kotlin为了实现java的static功能，必须使用伴生类，一般情况下没啥问题，但是反编译之后的class多了一个伴生类，这个类一旦被加载，几乎无法卸载，浪费性能和内存。
这个在别的比方无所谓，但是如下场景 ，是真的有点操蛋了
class UserBatchDTO : Serializable {/*** uidList*/var uidList: List<Long>? = null/*** 用户状态，0正常，1禁用*/var status: Int? = null/*** 用户介绍*/var introduce: String? = null/*** 审核通过者uid*/var approvedUid: Long? = null/*** 修改时间*/var updateTime: Date? = null/*** 角色id*/var roleIds: List<Long>? = nullcompanion object {@JvmStaticval name:String = ""private const val serialVersionUID = 1L}
}
二.无意义的空值校验
下面的代码是右边代码反编译之后的，参数校验、返回校验，之前听说什么游戏循环几十亿导致性能垃圾，这边请求次数多，无意义的判空多了也是浪费性能
三. 设计思路冲突
这一点和第一点相互关联，或者说是第一点的补充
默认class需要加上open才能被继承，但是做为oop语言，设计理应默认可以被继承，如果想不被继承可以加final，而不是默认final
有人说组合由于继承，但是这不是你默认不能继承的理由。这一点和oop思路冲突
四.代码不一定简洁
1.比如在上文的autowire，kotlin代码还多一点
2.如果写spring，一般还要在class或者方法加open，比一个public单词多一些，因为spring有一些代理，final会导致cglib代理代理失败。open有编译插件，这种魔法无疑不是好的解决方案
3.如果是record对象，kotlin生成了一些无意义的方法，代码膨胀
4.允许为空的字段一定要写默认为null，我建议一个?解决
5.其他隐藏的代码膨胀(class文件)
6.综上能看出为什么服务端用kotlin的意愿不是很强，代码没省略，编译还膨胀，客户端还是可以用用，dsl不错
五.Checked Exception
kotlin去掉了Checked Exception，但是实际上这些异常并不能被忽略，当然有的一窝蜂throwable也是不好
六.这个不全是kotlin的锅
gradle.kts，这个只能喷gradle一坨答辩
基本上80%以上用不上gradle，据目前经验，小项目，没有多平台(比如客户端、游戏)、多语言(c、c++)等混合编译、条件编译等复杂情况，建议不要用了
七 .结束
打完收工，今天喷点结束
