Windows文件系统对Emoji的支持取决于NTFS和应用程序层
NTFS本身支持UTF-16编码的文件名，因此能存储Emoji（如 ?✨.txt），但实际能否创建、读取、显示，取决于：调用API的.NET版本、是否启用Unicode感知、资源管理器或终端是否支持渲染。.NET Framework 4.8默认使用ANSI API桥接，容易在File.Exists或Directory.GetFiles中静默失败或返回乱码；.NET 5+ 默认启用UTF-8/UTF-16全路径支持，但仍需避免部分老旧API。
用System.IO操作Emoji文件名必须启用Unicode路径支持
.NET Core 3.0+ 和 .NET 5+ 默认启用，但若项目目标是netcoreapp3.0以下或运行在旧版Windows（如Win7 SP1未打补丁），需确认：
– 进程启动前已设置环境变量 DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false（否则ICU不加载，部分Unicode归一化失效）
– 不使用已废弃的Encoding.Default处理路径字符串
– 避免通过Console.WriteLine直接输出含Emoji的路径（旧版cmd.exe不支持，改用Windows Terminal或PowerShell）
– 推荐显式使用Path.GetFullPath预处理路径，它会触发.NET内部的Unicode规范化（NFC）
File.WriteAllText写入含Emoji的文件名时需注意编码与API选择
问题常出现在“文件创建成功但后续File.OpenRead报FileNotFoundException”——这往往不是编码问题，而是路径被意外截断或归一化不一致。例如："?文档?.md"在macOS传入Windows时可能以NFD形式到达，而NTFS只认NFC。
- 始终用
string.Normalize(NormalizationForm.FormC)标准化文件名再拼入路径 - 不要用
Path.Combine("dir", "?.log")后直接传给File.Create——先Normalize()再Combine - 检查
Path.GetInvalidFileNameChars()，它**不包含Emoji**，所以不能靠它过滤——Emoji是合法文件名字符 - 若需兼容极老系统（如WinXP），应主动替换Emoji为ASCII替代符（如
emojiRegex.Replace(name, "_emoji_")），而非依赖运行时降级
调试Emoji文件名问题优先检查资源管理器和Shell渲染能力
常见假阳性：代码执行成功，但资源管理器不显示图标、文件名显示为方块或问号。这不是.NET问题，而是：
– 当前用户字体不支持该Emoji（如Segoe UI Emoji未启用）
– 资源管理器启用了“快速访问”缓存，旧缓存未刷新（可尝试ie4uinit.exe -ClearIconCache）
– PowerShell 5.1默认使用Lucida Console，不支持Emoji；升级到PowerShell 7+或改用Windows Terminal
– 某些杀毒软件（如McAfee）会拦截含非ASCII路径的API调用，日志中出现STATUS_OBJECT_NAME_INVALID即属此类
真正难处理的是跨平台场景：Linux ext4虽支持UTF-8路径，但若挂载时指定iocharset=iso8859-1，Emoji会变乱码；macOS APFS对Emoji支持最好，但SMB共享到Windows时可能丢失归一化信息。这些不在C#控制范围内，只能在部署环节约束挂载参数和共享协议版本。
