形参与成员变量同名时未用 this. 会导致成员变量未初始化而保持默认值，引发隐蔽空指针等错误；重载构造器易职责混乱、参数校验缺失，加剧状态不一致风险。

因为形参和成员变量同名时，不加 this. 就会赋值给形参自己，成员变量根本没被修改，对象初始化后仍为默认值（如 null、0、false），编译不报错，运行也不崩溃，错误隐蔽难查。

形参自动遮蔽成员变量

Java 规定：方法或构造器内，局部变量（含形参）与成员变量同名时，局部变量优先可见。写 name = name; 实际是“把参数的值赋给参数自己”，对成员变量毫无影响。成员变量保持初始状态——引用类型为 null，基本类型为 0 或 false。

• 错误写法：filename = filename; → 左右都是形参，字段未赋值
• 正确写法：this.filename = filename; → 明确指向当前对象字段
• IDE 可能提示 “field is never assigned”，但若忽略或关闭检查，问题就潜伏下来

关键字段遗漏初始化

包装类常需持有多个状态（如 File 对象、编码格式、是否只读等），初学者容易只处理部分字段，漏掉其余：

• 声明了 private Charset charset;，却没在构造器中赋值，导致后续 read() 抛 NullPointerException
• 传入 String path 创建了 File file，却忘了同步设置 this.file = new File(path);
• 数组或锁对象误写成局部变量：Lock lock = new ReentrantLock(); → 成员变量 this.lock 仍是 null

重载构造器职责混乱

为支持多种创建方式（路径字符串、File 对象、InputStream），常定义多个构造器。初学者易混淆调用逻辑：

• 误用 new TextFile(new File(path)); 而非 this(new File(path));，造成对象重复创建、字段初始化错乱
• 在带 String 参数的构造器里新建 File，却设错了成员字段（比如赋给了 path 而非 file）
• 不同构造器之间逻辑不一致，有的校验参数，有的直接赋值，状态不统一

跳过参数校验直接赋值

文件或资源类强依赖输入合法性，但初学者常省略基础防护：

• 传入 null 路径却不检查，导致 this.path = null;，后续调用抛空指针
• 接受非法路径（如 "../"）未归一化，构造器照单全收，后续 file.exists() 返回 false 却无提示
• 建议在赋值前用 Objects.requireNonNull(path) 或 Paths.get(path).toRealPath() 做初步校验