作为一个 JAVA 开发 ，Spring 是我用的最多的框架。Spring 这个名字起的很好，一语双关，在英文里 spring 是春天的意思，寓意程序员的春天，同时 spring 还有弹簧的意思，它确实是一个有弹性的框架，扩展性很强。

类型约束

提到 spring ，首先想到的就是 ioc 和 aop 了，这些动态技术都是魔法，能自动管理，能增强代码。但是动态技术也带来了新的问题，Java 本来是个静态语言，有很强的类型约束，却被动态技术打破了。

@Cacheable(value = "userCache", key = "#corpId + #id") 
public User findUserByCorpIdAndId(String corpId,String id){}

比如上面的代码，我们可以使用 SpEL（Spring Expression Language）写一些简单的逻辑来构建 key，但是 SpEL 是没有类型约束的，编译没有检查，一般的 IDE 也没有提示（Idea旗舰版有做支持）。Spring 框架在很多地方都是支持 SpEL 的，但是总是手写这些字符串，很危险。我就犯过错误，写错了变量名但是程序仍然可以运行，只是参数拼上去总是 null，导致不同的参数拿到的缓存数据总是相同的。使用 api 的形式可以避免这样的问题，但是便利性就下降了。

复杂度太高

Spring 可以说是很好的践行了面向接口和面向对象编程，以致于继承和依赖关系复杂到让人叹为观止。对于 Spring 的源代码我是不建议去读的，因为复杂看很久没有头绪，方法跳了很久也没有到真正的实现，由于大量应用了动态字节码技术，有很多生成代码的代码，极为繁琐。原理了解下即可，花太多时间去读源码，收益不大。不过对于一个框架来说，要解决复杂问题，自身也必然复杂。但是如果一旦遇到报错要排查，或者调试代码就很头大了。

随着生态的发展，Spring 已经是一个非常庞大的框架，学习曲线比较陡峭，需要一定的学习成本才能熟练使用，要掌握它是非常困难的。也因此发展出了 Spring 八股文，大量的相关面试题攻略出现在互联网上。

资源占用高性能差

Spring 是一个 Bean 容器，可以让我们避免过多的创建对象，由 Spring 来管理，还可以自动注入我们需要的对象实例。但是，Bean 的管理也是需要成本的，在启动阶段就要扫描所有的包或配置文件来读取配置的 Bean，完成 Bean 的实例化再进行依赖注入和初始化，这就导致了规模一大启动时间就会很长，而且一开始就占用大量的内存空间来存储实例。而框架内部大量使用反射，也会降低运行时的性能。

根据我个人的经验，一个中等规模的 Spring Boot 项目至少需要 1G 的内存。部署一个 Spring Boot 实例耗费的内存至少可以部署五六个 vert.x 实例。我负责的部分项目启动时间最长的已经来到了1分半。

不可靠性

Spring 使用了大量的动态技术，动态技术来带来了很多坑，这些坑甚至还成为了经典面试题，比如“spring事务失效的12种场景”。有坑是常见的，大部分时候解决问题的方案也会带来新的问题。但是 spring 的坑有点多，不光是事务，凡是申明式注解，都会有不生效的问题，有时候不生效很难察觉，测试也不容易测出来，比如缓存和校验，没有生效结果也很可能是对的。也因此，有些公司的规范里是禁止使用申明式事务的。你可能会说经验多了就好了，多注意点，老虎也有打盹的时候，何况开发人员工作强度那么大，心中难免会不踏实。

不可否认的是动态技术带来了便利，假如我们想加代码，可以不用修改原来的逻辑，单独写 aop 拦截逻辑就可以了。但是，这样也带来了很多不确定性，一段方法执行了哪些逻辑，我们可能并不知道。aop 技术还是尽量要少用的，写的多了自己也忘记加过什么东西，将来接手项目的人可能要叫苦了。Spring Boot 的自动配置还有可能带来安全问题，依赖的 jar 包如果有恶意代码，是可以通过自动配置直接在启动阶段执行的。

反思

Spring 并不完美，动态字节码技术也许不是好的解决方案，ioc 和容器技术不是必须的，这套方案只是在 Java 中比较流行而已。动态技术提升了静态语言的灵活性，同时又失去了静态语言的严谨，编译期很多错误都检查不出来，只有跑起来了才能知道。

虽然 ioc 降低了耦合性，但是我觉得并不是必须的，现实是我们的代码常常没有多实现，不需要无缝替换，也没有必要热插拨。大项目为了保险起见能跑就行，也不敢切换实现，更高一层的抽象还会导致失去部分原生特性，过渡设计也会增加程序的复杂度，不要总是面向对象和面对接口。

总结

我不反对使用 Spring ，毕竟对于这么有影响力的框架，如果团队达不成一致，用它可以减少争议，大家都服气。但是，我已经不想再用了，探索别的方案对于我来说更有吸引力。

没有必要始终如一的使用一个框架，更没有必要死磕一种语言，Java 确实有很多不便之处，这个我们要承认，但是动态字节码和代理技术不是良药。多了解下其它的语言，开阔下视野很有必要，有时候格局就这样打开了。