AddFontResource仅临时注册字体且需SendMessage广播WM_FONTCHANGE，系统级安装必须复制.ttf到C:\Windows\Fonts并以管理员权限运行，字体名不等于文件名，需用FontFamily.Families确认真实名称。
Windows下用C#调用AddFontResource失败，字体没生效
直接调用AddFontResource只是临时注册，仅对当前进程有效，且需配合SendMessage广播WM_FONTCHANGE，否则其他程序（包括你自己后续的GDI绘图）看不到新字体。更关键的是：它不写入系统字体目录，重启后丢失，也不出现在“控制面板→字体”里。
- 必须把
.ttf文件先复制到C:\Windows\Fonts（或Environment.GetFolderPath(Environment.SpecialFolder.Fonts)） - 复制后要调用
AddFontResource+SendMessage(HWND_BROADCAST, WM_FONTCHANGE, 0, 0)，否则当前进程内Graphics.FromImage等仍可能选不到 - 注意权限：写入
Fonts目录需要管理员权限，否则File.Copy会抛UnauthorizedAccessException
C#安装字体时提示“访问被拒绝”或“目标路径不存在”
常见于没检查目标路径是否存在、没请求提升权限、或误用了用户级字体路径。Windows真正的系统级字体安装路径是C:\Windows\Fonts，不是%USERPROFILE%\AppData\Local\Microsoft\Windows\Fonts（那是Win10/11引入的用户级字体目录，行为不一致）。
- 优先走系统路径：
Environment.GetFolderPath(Environment.SpecialFolder.Fonts)在不同系统返回值不同，Win10+可能返回用户目录，要手动拼@"C:\Windows\Fonts" - 安装前用
Directory.Exists(@"C:\Windows\Fonts")确认路径可写，再用File.Exists检查目标文件是否已存在（避免重复拷贝） - 必须以管理员身份运行程序，否则写
C:\Windows\Fonts必然失败；若不想提权，只能退到用户字体目录，但需调用AssociateApplicationWithFonts注册（不通用，部分应用不识别）
安装完字体后，GDI+绘图还是用不了新字体名
字体名（FontFamily.Name）和文件名（xxx.ttf）通常不一致。比如simhei.ttf对应字体名是SimHei，不是simhei。直接用文件名创建FontFamily会抛ArgumentException。
- 不要依赖文件名，用
FontFamily.Families枚举所有已加载字体，打印family.Name确认真实名称 - 安装后需等待几毫秒再查询——有时
FontFamily.Families不会立即刷新，可加Thread.Sleep(50)或重试逻辑 - 如果用
new Font("SimHei", 12)报错，说明字体名没加载成功，先检查是否真的复制到了Fonts目录、是否广播了WM_FONTCHANGE
跨平台或.NET Core/.NET 6+项目里怎么装字体
别试了。AddFontResource和WM_FONTCHANGE是Windows GDI专属API，Linux/macOS根本不支持。.NET Core及以后版本的System.Drawing.Common在非Windows平台默认禁用字体安装能力，即使强制启用也无法写系统字体库。
- Linux上得调用
fc-cache -fv命令并把字体拷到~/.fonts/或/usr/local/share/fonts/，还要处理fontconfig缓存 - macOS需用
cp xxx.ttf ~/Library/Fonts/再执行atsutil databases -remove刷新 - 纯跨平台方案只能放弃“系统级安装”，改用
SkiaSharp或ImageSharp自带字体加载器，把ttf当资源流读取，不依赖系统字体库
真正麻烦的不是代码怎么写，而是Windows字体注册机制本身不提供同步完成通知——你复制完、调完API、发完消息，仍可能有几十毫秒延迟才被GDI识别。生产环境建议加简单轮询+超时，别信“调完就立刻能用”。
