Java构造函数内使用Scanner获取用户输入是否为不良实践？

这问题问得好！确实很少见有人在构造函数里直接搞控制台输入，虽然Java语法允许，但这里面藏着不少坑，咱们一条条捋清楚：

• 违反单一职责原则：构造函数的核心职责是初始化对象的内部状态，现在把用户输入的IO逻辑硬塞进来，一个方法同时承担了初始化和输入处理两个职责，代码职责边界模糊，后续维护和复用都会变得困难。比如你想在不需要控制台交互的场景（比如批量数据处理、单元测试）复用这个类，根本做不到。

• 单元测试几乎无法开展：单元测试需要可控的测试环境，构造函数里直接绑定了System.in，你没法模拟用户输入——总不能每次跑测试都手动敲键盘吧？这直接导致这个类的自动化测试无从谈起，只能靠人工验证，效率极低。

• 对象创建的可靠性丧失：如果用户输入不符合预期（比如输入了字符串而非整数），sc.nextInt()会抛出InputMismatchException，这时候对象根本创建失败。本来对象初始化应该是一个相对可靠的过程，现在却完全依赖外部用户的输入，很容易导致程序意外崩溃，而且在构造函数里做复杂的异常处理会让代码变得臃肿不堪。

• 耦合度过高，扩展性差：这个类直接和System.in绑定死了，没法替换成其他输入源（比如文件输入、网络请求输入）。如果以后需求变更，要从其他来源获取初始化数据，你不得不重写整个构造函数，完全违背了开闭原则（对扩展开放，对修改关闭）。

• 糟糕的用户体验：想象一下，程序运行到某个地方突然卡住，等着用户输入，但用户根本不知道这是创建对象导致的——什么时候需要输入？要输入什么内容？如果是在循环中创建多个对象，用户还要连续输入多次，这种突兀的交互逻辑完全不符合用户预期，而且这类交互应该放在专门的UI层或控制层，而非对象的构造过程中。

正确的做法 #

把输入逻辑和对象初始化彻底分离：

1. 先在外部获取输入值，再将值作为参数传给构造函数，比如：

Scanner sc = new Scanner(System.in);
int inputA = sc.nextInt();
SomeClass obj = new SomeClass(inputA);

2. 或者通过依赖注入的方式，传入一个通用的输入接口（而非具体的Scanner），让类可以适配不同的输入源，提升灵活性。

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