复杂应用仅使用单个@RestController是否会影响性能

把所有接口逻辑全部塞进单个@RestController的写法，本身不会对应用运行时性能产生可感知的负面影响，性能层面几乎不需要为这个设计有顾虑，但这个反模式的问题全出在工程维护层面，和性能无关。

• Spring MVC的路由注册逻辑和Controller类的拆分粒度无关。应用启动时，Spring会扫描所有被@RestController标记的类，把类中所有带请求映射注解（@GetMapping/@PostMapping等）的方法，统一注册到RequestMappingHandlerMapping的路由映射表中。不管这些接口方法是分散在100个不同的Controller类，还是全部堆在同一个类里，最终生成的路由表结构、请求到来时的路由匹配逻辑完全一致，匹配处理方法的耗时没有任何区别。
• Controller默认是单例Bean，单Controller不会带来额外的运行时开销。不管你是初始化1个Controller Bean还是100个Controller Bean，这类无状态单例的内存占用差异对于Web应用来说可以忽略不计；请求处理过程中的参数解析、业务逻辑调用、响应序列化流程，和Controller类的数量没有任何绑定关系，不会因为类拆得多就变快，也不会因为类少就变慢。
• 唯一可观测的差异只出现在启动阶段：如果单个Controller类的方法数、注解量特别大，Spring启动时做类加载、注解解析的耗时会比拆成多个小类高几毫秒到几十毫秒不等，这个差异只在启动时出现一次，完全不影响上线后的请求处理性能。

它的负面影响基本都集中在工程协作和维护层面：

• 代码维护成本陡增：当成百上千个接口塞在同一个类文件里，代码行数很容易冲到几万甚至十几万行，排查问题、修改逻辑时找代码的成本会非常高，修改某一个接口逻辑时误改其他接口代码的概率也会大幅上升。
• 通用逻辑的管控粒度变粗：如果你要给某一类业务接口加统一的拦截器、日志切面、参数校验规则，拆分Controller时可以直接按类定义切点，配置非常简单；单Controller场景下你只能给每个方法单独打注解，或者写非常复杂的切点匹配规则，很容易出现漏配、错配的问题。
• 团队协作冲突频繁：多个开发同时迭代不同接口时，所有人都要改同一个Controller类，Git代码冲突会是常态，合并代码的沟通成本、出错概率都会高很多。

注意：如果在写单Controller时犯了单例Bean的常见错误——把请求级别的变量（比如当前请求的用户信息、请求参数）定义成Controller的类成员变量，会引发线程安全问题，间接导致接口报错、数据错乱甚至性能故障，但这个问题的根源是错误的单例对象用法，不是“单Controller”这个设计本身，哪怕你拆了多个Controller，只要在类里写了有状态的成员变量，一样会出问题。

内容的提问来源于stack exchange，提问作者Zawada