compositeformat 不可预编译，它是 .net 运行时内部解析复合格式字符串（如 "{0:c}"）的 internal 结构体，无公开构造函数，不能实例化或复用；所谓“预编译”实为对字符串插值优化、自定义格式器或第三方缓存机制的误解。
CompositeFormat 不是可预编译的类型，它只是 .NET 运行时内部用于解析格式字符串（如 "{0:C} {1:d4}"）的一个轻量结构体，没有公开构造函数，也不能手动实例化或“预编译”。所谓“预编译格式化”在 C# 中并不存在官方机制——所有复合格式字符串都在运行时由 String.Format、Console.WriteLine 等方法即时解析。
如果你看到“CompositeFormat 预编译”这类说法，大概率是混淆了以下三类概念：
- 把 Roslyn 编译器对字符串插值（
$"..."）的编译期优化误认为“格式预编译” - 把
ICustomFormatter+IFormatProvider的自定义格式化流程当成可缓存/复用的“预编译格式” - 或者误信某些第三方库（如 FastFormat）的缓存式格式化包装逻辑
真正影响性能和安全的关键点，不在“预编译”，而在 格式字符串来源、参数绑定时机、文化敏感性控制。
为什么不能 new CompositeFormat("...")？
CompositeFormat 是 internal 结构体，仅由运行时在调用 string.Format(IFormatProvider, string, params object[]) 等重载时内部构建。你无法显式创建它，也无法把它存为字段或传参复用。
- 试图写
var cf = new CompositeFormat("{0:D4}");→ 编译失败：类型不可访问 - 反射获取构造函数 → 返回 null，无可用 public 构造器
- 反编译
String.Format源码可见：它直接调用FormatHelper.ParseFormatString解析占位符，不暴露中间结构
字符串插值 $"" 在编译期做了什么？
C# 6+ 的 $"Name: {name}, Age: {age:D2}" 确实有编译期处理，但不是“预编译格式”，而是：
- 编译器将插值字符串转为
string.Format(CultureInfo.CurrentCulture, "Name: {0}, Age: {1:D2}", name, age)调用（若未指定文化） - 若含简单表达式（如
${price * 1.08}），会生成临时变量和内联计算，不改变格式解析时机 - 不会提前验证占位符语法：写成
${name:00}（错误，应为name.ToString("00")）仍能编译，但运行时报FormatException
真正值得缓存/复用的是 Format String + IFormatProvider
如果你频繁使用同一套格式（比如日志模板 "[{0:HH:mm:ss}] {1} - {2}"），可做的优化是：
- 把格式字符串声明为
static readonly string LogTemplate = "[{0:HH:mm:ss}] {1} - {2}";，避免重复字符串分配 - 固定文化时显式传
CultureInfo.InvariantCulture，避免每次查线程当前文化 - 对高吞吐场景（如每秒万级日志），改用
Span<char></char>+Utf8Formatter（.NET 6+）或StringBuilder.AppendFormat批量写入 - 不要尝试“缓存 CompositeFormat 实例”——它根本不是设计来复用的对象
容易被忽略的坑：格式字符串来自配置或用户输入
当格式字符串是动态读取的（如 JSON 配置中的 "{0:C} ({1:P1})"），必须严格校验：
- 占位符索引是否越界（
String.Format(fmt, args)中args.Length小于最大索引 →FormatException） - 是否含非法格式说明符（如
{0:Z}）→ 同样抛FormatException，且无法提前发现 - 避免直接拼接用户输入进格式串：
$"Hello {userInput}"安全，但string.Format("{0} " + userInput, data)可能被注入恶意占位符
真正需要关注的，从来不是“怎么预编译 CompositeFormat”，而是：谁控制格式字符串、参数是否可信、文化是否固定、错误是否可捕获。这些点一旦松动，再“预编译”也挡不住运行时崩。
