u8后缀直接生成readonlyspan而非byte[]，是编译期确定的utf-8字节序列，零分配、不可变、无gc压力；而encoding.utf8.getbytes()是运行时堆分配，语义与性能均不同。
u8 后缀不是“生成 byte[] 的快捷方式”，而是直接产生 ReadOnlySpan<byte></byte> —— 这一点不搞清，后续所有用法都会踩坑。
为什么 "hello"u8 不等于 Encoding.UTF8.GetBytes("hello")
两者语义不同："hello"u8 是编译期确定的 UTF-8 字节序列，类型是 ReadOnlySpan<byte></byte>；而 Encoding.UTF8.GetBytes() 是运行时调用，返回堆分配的 byte[]。前者零分配、不可变、无 GC 压力；后者每次调用都新建数组。
常见误用：
- 直接对
"abc"u8调用.ToArray()—— 多余分配，尤其在 hot path 中会放大性能损耗 - 试图把
"abc"u8当作string传给接受string参数的 API（比如Console.WriteLine）—— 编译失败，报错CS9047 - 在非 C# 11+ 项目中启用 u8（即使 TargetFramework 是 .NET 6+），但没在
.csproj中显式设置<langversion>11</langversion>或更高 —— 编译报错CS8985
"header"u8 在 HTTP 协议场景下的正确姿势
网络协议栈里大量出现 ASCII-only 的常量（如 "Content-Length: "、"GET "），这类字符串用 u8 最合适：编译即得字节、无需运行时编码、可直接写入 Socket 或 Stream。
实操建议：
- 优先用
ReadOnlySpan<byte></byte>接收，例如socket.SendAsync("HTTP/1.1 200 OK\r\n"u8)（前提是 API 支持ReadOnlyMemory<byte></byte>） - 避免拼接：
"Content-Length: "u8+length.ToString()u8是非法的 ——ReadOnlySpan<byte></byte>不支持+运算符；应改用stackalloc或MemoryPool<byte>.Shared.Rent()</byte>组合 - 若需动态构造（如插入变量），先转成
string再整体编码更安全，而不是强行拼接多个u8片段
CS9026 错误：哪些字符串不能加 u8
编译器会在无法无歧义转为 UTF-8 时拒绝 u8，典型触发条件：
- 字符串含无效 Unicode 序列（比如损坏的代理对：
"\ud800\ud800"u8）→ 报错CS9026 - 使用了不被 UTF-8 编码支持的字符（实际极少，但某些控制字符或未配对 surrogate 可能导致失败）
- 内插字符串中用了表达式结果不确定编码的情况（如
$"x{someVar}y"u8中someVar是char或ushort）→ 编译器无法静态验证 UTF-8 安全性，直接拒掉 - 原始字符串中混用非 UTF-8 兼容的转义（如
@"\xFF"u8）→ 实际上\xFF不是合法 UTF-8 字节，编译失败
性能敏感代码里，u8 的真实开销在哪
u8 本身没有运行时开销，但它的生命周期和使用方式会引入隐性成本：
-
"abc"u8每次出现都生成新的ReadOnlySpan<byte></byte>实例 —— 虽然不分配内存，但 Span 是 ref-like 类型，频繁传递可能增加 JIT 优化难度 - 如果反复从同一
u8字面量调用.ToArray()，等于重复分配相同内容的byte[]，不如缓存为static readonly byte[] = "abc"u8.ToArray() - 跨方法边界传递
ReadOnlySpan<byte></byte>时，注意不要意外捕获到栈内存（比如从stackalloc返回的 span）——u8是安全的，因为它背后是静态数据区
真正容易被忽略的是：u8 字面量在 IL 中以 ldtoken + call Encoding.UTF8.GetPreamble() 类似机制实现，它依赖运行时已加载并初始化 Encoding.UTF8。极早期启动阶段（如自定义 AOT 初始化逻辑中）若绕过标准框架初始化流程，可能触发罕见的 NullReferenceException。
