当在 java 代码中使用 standardcharsets.utf_8 时出现 “cannot be resolved to a variable” 错误，根本原因是缺少对 java.nio.charset.standardcharsets 类的显式导入——该类虽属 java.nio.charset 包，但并非通过 import java.nio.charset.charset; 自动可见。
当在 java 代码中使用 standardcharsets.utf_8 时出现 “cannot be resolved to a variable” 错误，根本原因是缺少对 java.nio.charset.standardcharsets 类的显式导入——该类虽属 java.nio.charset 包，但并非通过 import java.nio.charset.charset; 自动可见。
StandardCharsets 是 Java 7 引入的工具类（位于 java.nio.charset 包），它提供了一系列预定义的、不可变的 Charset 实例（如 UTF_8、ISO_8859_1、US_ASCII 等），用于替代易出错的字符串编码名称（例如 "UTF-8"），从而提升类型安全性和运行时性能。
然而，StandardCharsets 并非 Charset 的子类或静态内部类，而是一个独立的顶级工具类。因此，仅导入 java.nio.charset.Charset 完全无法访问 StandardCharsets —— 必须单独导入：
import java.nio.charset.StandardCharsets; // ✅ 关键：必须显式导入
修正后的完整代码如下：
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
import java.util.Scanner;
import java.nio.charset.StandardCharsets; // ✅ 新增：必需导入
import java.nio.file.Path;
public class Training {
public static void main(String[] args) {
try (Scanner in = new Scanner(Path.of("text.txt"), StandardCharsets.UTF_8)) {
// 使用 hasNextLine() + nextLine() 逐行读取，而非直接打印 Scanner 对象
while (in.hasNextLine()) {
System.out.println(in.nextLine());
}
} catch (java.io.IOException e) {
System.err.println("文件读取失败：" + e.getMessage());
}
}
}⚠️ 注意事项与最佳实践：
立即学习“Java免费学习笔记（深入）”；
- Scanner 构造器中传入 Path 和 Charset 会自动以 UTF-8 编码打开文件，但Scanner.toString() 仅返回对象描述（如 java.util.Scanner[delimiters=...]），不会输出文件内容——务必使用 nextLine()、next() 或 useDelimiter().next() 等方法实际读取。
- 始终使用 try-with-resources 语句（如示例所示）确保 Scanner 正确关闭，避免资源泄漏。
- 若目标 JDK 版本低于 7（如 Java 6），StandardCharsets 不可用，需改用 Charset.forName("UTF-8")，但会失去编译期检查和零开销优势。
- 不推荐依赖静态导入（如 import static java.nio.charset.StandardCharsets.*），虽可省略类名前缀，但会降低代码可读性，且易引发命名冲突。
总结：StandardCharsets.UTF_8 是现代 Java 文本处理的推荐方式，但其使用前提是显式导入 java.nio.charset.StandardCharsets。这一细节看似微小，却是保障编码安全、代码健壮与 IDE 正常识别的关键一步。
