Java中u转义序列仅在编译期生效，用于源码中固定Unicode字符；运行时无法动态构造，须用Character.toChars()或String.valueOf()处理码点。
Java里用u开头的转义序列插入Unicode字符，只在编译期生效
Java源码中写u0041会被编译器直接替换成字符A，不是运行时解析——这意味着你不能拼接、不能从变量或输入里动态构造u序列。
- 常见错误现象：
String s = "u" + "0041";编译失败，因为u必须后跟4位十六进制数字，且必须在源码里完整写出 - 使用场景：定义固定字符串常量，比如带中文、数学符号、emoji（需UTF-16代理对）的字面量
- 参数差异：
u只支持4位，超出要用uD83DuDE00这类代理对；而U（如Python）在Java里根本不存在 - 性能影响：零成本，纯编译期替换，不生成额外字节码
运行时插入Unicode字符只能靠Character.toChars()或String.valueOf()
想根据数值动态生成字符？别碰u，它不接受变量。得用API把码点转成char数组或String。
- 常见错误现象：
String s = "u" + Integer.toHexString(0x1F600);—— 这不会得到笑脸，只会报错或输出字面字符串 - 正确做法：用
Character.toChars(int codePoint)处理BMP外字符（如emoji），再转new String(charArray) - 简化路径：单个BMP字符（U+0000–U+FFFF）可用
String.valueOf((char)0x0041)；超范围必须用toChars() - 兼容性注意：Java 5+才完全支持代理对，旧版本可能显示为
文件编码和IDE设置不匹配会导致u序列被误读
源文件存为GBK但声明UTF-8，或者IDE编码设错，u4F60可能变成乱码甚至编译失败。
- 常见错误现象：
String s = "你好";在控制台打印成，但"u4F60u597D"却正常——说明源码编码和编译器预期不一致 - 检查顺序：先看文件实际编码（用notepad++或
file -i），再确认javac -encoding UTF-8参数，最后核对IDE（IntelliJ/VS Code）的文件编码设置 - 路径依赖：
javac默认用系统编码，Linux/macOS通常是UTF-8，Windows是GBK，不显式指定-encoding极易翻车
正则表达式和JSON字符串里不能直接用u序列
u是Java字符串字面量语法，进了正则或JSON就失效了——它们各自有转义规则。
立即学习“Java免费学习笔记（深入）”；
- 常见错误现象：写
Pattern.compile("u4F60")本意匹配“你”，结果匹配失败；因为正则引擎看到的是已解码的字符，而某些正则方法（如Matcher.quoteReplacement()）反而需要原始u写法 - JSON场景：
"u4F60"在JSON字符串里合法，但Java里写成"\u4F60"才能让最终JSON含u4F60；少一个反斜杠就变成字面字符“你” - 关键区别：Java字符串字面量 → 编译期解码；JSON/正则 → 运行时按各自规范解析；二者混用时反斜杠数量极易出错
真正麻烦的从来不是记不住u怎么写，而是分不清它在哪一层起作用——编译器？JVM？正则引擎？还是HTTP响应体？多一层上下文，就得换一套转义逻辑。
