需要的，迁移旧应用可以少一些麻烦

不需要，形式大于内容

引导用户从设计上避免循环依赖是有意义的

不需要，都是被惯的，，，
真的没什么卵用

不需要

纯个人看法：首先无论字段注入，构造注入还是 setter 注入都是开发者的个人习惯，建议提供，其次不同框架迁移中需要对初次使用者提供一个过渡期，然后构造注入可以降低耦合度，提高属性的隐匿性和整体性，总体而言，联系提供，具体看开发者个人习惯原则，毕竟多一个选择也不是什么坏事

当必须要用到构造器注入的时候，手写代码可能是更好的选择

多一个选项没什么不好

极左，左，右 ，极右。
极左：守住清净 (缓慢发展)
左：功能优先 (稳健发展)
右：概念与功能同时顾及 （良性发展）
极右：最求最新概念，同时追求前沿的功能 （风险）

不需要，除了会引发问题 带不来啥收益

1、从平台角度考虑，应该都具备；可以不用但是必须要有
2、历史项目的迁移兼容性
建议结合lazy的方式实现，降低影响

不需要

不需要

不需要

网上常见吹spring构造注入哪套，什么提升性能，官方推荐，经常翻spring官网的朋友都知道，没有那么花里胡哨。

实际开发实践中发现，某些业务开发bean注入是存在依赖循环的。构造注入让开发变得不再灵活，要明确bean是注入顺序，否则初始化失败。

以我接手的spring4老项目发现，一路升级到spring5最新版，3年变迁，发现还是弃用的构造注入，因为不灵活，bean太多，一不小心就突然循环依赖，变成手动注入（@PostConstruct、@Init中初始化）。构造注入却变成了后面增加功能埋坑（直接使用已有的bean实现业务逻辑反复调用）。项目成员更替，最后还是@AutoWrited香。

最后，铁打的项目，流水的维护成员。

推荐增加这个功能

不好意思，我突然觉得虽然我用不上，实际开发也不推荐这么玩。但框架有必要增加这个功能，多一个选项。肯定有人相信网上构造注入的哪套，所以构造注入还是得有，大家都这么玩了，你不能没有，这对solon也有好处。哪些依赖循环之类的，应该由开发者自己搞定。