初学者编写文件包装类构造器时易因形参遮蔽成员变量（如 filename = filename）、遗漏关键字段初始化（如 charset 未赋值）、混淆构造器重载职责（误用 new 而非 this(...)）、忽略参数校验（如 null 或非法路径）导致运行时异常。
初学者在编写文件包装类（如 FileWrapper、TextFile 等自定义类）的构造器时，常因形参名与成员变量名相同却未正确区分，导致赋值失效、字段始终为 null 或默认值，进而引发空指针异常或逻辑错误。这不是语法报错，而是**运行时行为异常**，但根源在构造器初始化阶段就已埋下。
形参遮蔽成员变量（Shadowing）
当构造器参数名和成员变量名完全一致时，Java 默认使用的是形参，而非当前对象的成员变量。若不加 this. 显式指定，赋值操作实际只作用于局部变量，成员变量并未被初始化。
- 错误写法：
filename = filename;→ 左右都是形参，成员变量未被赋值 - 正确写法：
this.filename = filename;→ 明确将形参值赋给当前对象的成员变量
忘记初始化关键字段
文件包装类通常需持有 File 对象、路径字符串、编码格式、是否只读等状态。初学者易只关注“能编译通过”，而忽略某些字段未在构造器中赋值：
- 例如：声明了
private Charset charset;，但构造器里只处理了path和file，漏掉charset = StandardCharsets.UTF_8; - 结果：后续调用
read()时因charset为null抛出NullPointerException
混淆重载构造器之间的职责边界
为支持多种创建方式（如传路径字符串、传 File 对象、传 InputStream），常会定义多个构造器。初学者容易：
- 在带
String参数的构造器里新建File，却忘了同步设置file成员变量（或设错了字段） - 在调用另一个构造器时误用
new而非this(...)，造成对象创建两次、字段初始化混乱 - 例如：
this(new File(path));是正确的委托；而new TextFile(new File(path));是错误的嵌套实例化
未校验参数有效性就直接赋值
文件操作强依赖输入合法性，但初学者常跳过校验步骤：
- 传入
null路径却不检查，导致this.path = null;，后续Objects.requireNonNull(path)失败 - 传入非法路径（如
"../"未归一化），构造器照单全收，后续file.exists()返回false却无提示 - 建议：在赋值前用
Objects.requireNonNull()或Paths.get().toRealPath()做基础防护
