应优先使用standardcharsets.utf_8等静态常量，避免charset.forname传字符串；因别名匹配不严格、jvm实现差异大、版本兼容性差，且"utf-8"最稳，"utf8""utf8"等非标准形式易失败。
Charset.forName 能用，但别无脑传字符串——别名匹配不严格、JVM 实现差异大、部分别名在不同 JDK 版本里会静默失败或返回不同实例。
为什么 Charset.forName("UTF-8") 有时返回 null 或抛 UnsupportedCharsetException
不是所有字符串都能被识别为合法别名；JVM 只加载了基础字符集（如 UTF-8、ISO-8859-1、US-ASCII），而像 "utf8"、"UTF8"、"utf_8" 这类非标准拼写，在 OpenJDK 和某些 Android Runtime 中可能直接报错。
-
"UTF-8"是 IANA 注册名，最稳，所有 JDK 都支持 -
"utf-8"（小写）在 JDK 8+ 多数情况能 fallback 成功，但不保证 —— 某些精简版 JRE 会拒绝 -
"UTF8"在 Oracle JDK 8 曾可工作，但在 JDK 11+ 中已被明确移除支持，抛UnsupportedCharsetException - 别名大小写敏感：Java 规范只要求匹配注册名（如
UTF-8），不强制兼容变体
替代方案：用 StandardCharsets 静态常量更安全
如果你只是需要常见编码，根本不需要走字符串解析路径——StandardCharsets 是 JDK 7+ 提供的不可变常量池，零反射、零异常、零别名歧义。
-
StandardCharsets.UTF_8比Charset.forName("UTF-8")快一个数量级（无字符串查找+映射开销） - 编译期校验：拼错字段名会直接报错，而不是运行时报
UnsupportedCharsetException - 不依赖 JVM 字符集注册表，Android、GraalVM Native Image 等环境行为完全一致
- 仅限标准集：覆盖
UTF_8、ISO_8859_1、US_ASCII、UTF_16、UTF_16BE、UTF_16LE
真要动态加载别名？先查再用，别硬试
如果业务必须接受用户输入的编码名（比如 HTTP Content-Type 的 charset=xxx），不能直接丢给 Charset.forName —— 得先过滤/标准化，再兜底。
立即学习“Java免费学习笔记（深入）”；
- 统一转成
US-ASCII兼容格式：用正则替换掉空格、下划线、多余连字符，再转小写（例："utf_8"→"utf8"→ 改成"UTF-8"） - 白名单校验比 try-catch 更可靠：
Charset.availableCharsets().keySet()返回所有已注册名，但注意它不包含别名，只含规范名 - 别依赖
Charset.isSupported("xxx")做判断——它和forName底层走同一套逻辑，同样会因别名不标准而返回false - 生产环境建议加日志：对首次出现的非常规别名记录 warn，避免黑盒 fallback
容易被忽略的陷阱：同一个别名在不同 JDK 版本返回不同 Charset 实例
Charset 是抽象类，子类实现由 JVM 提供。OpenJDK 和 Zulu 对 GBK 的处理就不同：前者返回 sun.nio.cs.ext.GBK，后者可能返回自定义实现——这会影响 instanceof 判断、序列化兼容性、甚至 Charset.equals() 结果。
-
Charset.forName("GBK") == Charset.forName("GBK")不一定为true（虽然内容相同，但实例可能不同） - 不要用
==比较字符集，始终用.equals()或.name().equals() - 跨服务传输字符集名时，只传规范名（如
"GBK"），不要传实例，避免反序列化失败 - JDK 17+ 开始限制部分扩展字符集（如
Big5-HKSCS），默认不加载，需手动--add-modules java.base或配置系统属性
别名这事，表面是字符串匹配，实际牵扯到 JVM 实现、IANA 注册规则、模块系统加载策略三层逻辑。越想“灵活”，越容易掉进静默不一致的坑里。
