必须用StandardCharsets.UTF_8而非"UTF-8"字符串，因其编译期校验、IDE可导航、实例唯一；US_ASCII限0x00–0x7F，超范围静默替为?；ISO_8859_1非万能解码器，误用致乱码。
Java 中的 Charset 是表示字符编码规则的核心抽象类，而 StandardCharsets 不是工具类，也不是枚举，它是 JDK 7+ 提供的一组线程安全、编译期可校验的静态常量集合。用好它，能避开乱码、异常和代码质量警告。
为什么必须用 StandardCharsets.UTF_8，而不是 "UTF-8"
字符串形式的编码名（如 "UTF-8"）存在三类硬伤：
- 运行时才检查：拼错成
"UTf-8"或"UTF_8"，编译不报错，但执行时抛UnsupportedEncodingException - 无 IDE 导航支持：无法 Ctrl+点击跳转到定义，不利于阅读和维护
- 实例不唯一：多次调用
Charset.forName("UTF-8")可能返回不同对象，==判断失效，影响缓存或配置比对逻辑
StandardCharsets.UTF_8 是单例静态 final 字段，编译期绑定，IDE 可直达源码，且 == 和 .equals() 均稳定可靠。
三个最常用常量的实际边界与误用风险
别只背名字，要清楚每个常量“能做什么”和“不能做什么”：
-
StandardCharsets.UTF_8：通用首选，覆盖全部 Unicode 字符；但协议头（如 HTTP
Content-Type）、系统文件名等场景要求纯 ASCII 子集，此时不能直接用 -
StandardCharsets.US_ASCII：严格限定 0x00–0x7F；超范围字符（如中文、é、€）会被静默替换为
?；适合 HTTP 头、URL 安全化、POSIX 兼容路径生成 - StandardCharsets.ISO_8859_1：单字节映射 0x00–0xFF → U+0000–U+00FF；它不是万能兜底解码器——对 GBK 或 UTF-8 编码的中文，它只会输出 Latin-1 范围内的乱码字符，而非还原原文
String.getBytes() 和 new String(byte[], Charset) 的典型陷阱
这两个 API 表面简单，实则极易出错：
- 不传 Charset 调用
str.getBytes()：依赖系统默认编码（Windows 是 GBK，Linux/macOS 是 UTF-8），同一份代码在不同环境行为不一致 - 用
new String(bytes, StandardCharsets.UTF_8)解码时：若bytes实际是 GBK 编码，结果必然是乱码；该构造函数不会报错，而是静默替换非法序列（如孤立的 0xC0）为 - 调试建议：先用
Arrays.toString(bytes)打印原始字节，对照 UTF-8 编码规则（如中文通常为 3 字节序列以 0xE 开头）判断是否匹配
兼容性与特殊编码注意事项
落地项目需关注实际运行环境约束：
- Android 4.4 以下版本不完整支持
StandardCharsets全部常量（如ISO_8859_1可能为 null），需降级使用Charset.forName("ISO-8859-1")并加 try-catch - 避免直接使用
StandardCharsets.UTF_16：它未指定字节序（BOM）和大小端，易导致跨平台解析失败；应明确选用UTF_16BE或UTF_16LE -
Charset.availableCharsets()返回的是 JVM 支持的所有编码，含大量冷门/测试用编码（如X-SJIS），生产环境只应使用StandardCharsets明确列出的那几个
