global using是C#10+强制性的项目级命名空间组织方式，必须置于文件最顶部、所有普通using和namespace声明之前，否则报CS8773；仅作用于当前编译单元，不跨项目生效，且需权衡可读性与命名空间污染。
global using 不是“可选技巧”，而是 C# 10+ 项目中强制性的命名空间组织方式——它必须出现在所有普通 using 之前、所有 namespace 和类型声明之前，否则编译直接失败。
global using 必须放在文件最顶部，顺序错一点就报 CS8773
编译器在解析源码时会严格校验 global using 的位置。一旦它出现在任何普通 using 后面，或夹在 namespace 块中间，哪怕只多一个空行，都会触发错误：CS8773: Feature 'global using directive' is not available in C# 9.0（即使你用的是 C# 12）。
✅ 正确顺序只能是：
- 所有
global using（含global using static和global using alias） - 其他
using（包括普通using、using static、using alias） -
namespace或顶层类型声明
❌ 常见错误写法：
using System;<br>global using Microsoft.Extensions.DependencyInjection; // 错！CS8903
namespace MyProject {<br> global using Newtonsoft.Json; // 错！不能在 namespace 块内global using static 和 global using 别名的语法边界
global using static 是安全且高频使用的，比如让整个项目直接调用 Console.WriteLine；但别名写法稍有不慎就会编译失败。
-
global using static System.Console;✅ 合法 -
global using MyList = System.Collections.Generic.List<int>;✅ 合法，MyList全局可用 -
global using MyList<T> = System.Collections.Generic.List<T>;❌ 编译错误CS0246：开放泛型不支持别名 -
using global MyList = ...❌ 语法错误：global必须紧贴using关键字，不能后置
global using 不跨项目生效，类库里的声明对引用方无效
你在类库 A 的 GlobalUsings.cs 里写了 global using Newtonsoft.Json;，主项目 B 引用了 A，B 中依然无法直接用 JObject。
这是因为 global using 只作用于当前编译单元（即当前 .csproj），不会穿透到引用的程序集。
- 若需多项目共享，必须在每个项目中显式包含同一份
GlobalUsings.cs - 推荐做法：新建
GlobalUsings.cs文件，仅放global using语句，并确保其Build Action为Compile - 也可通过
Directory.Build.props或.csproj中的<Compile Include="GlobalUsings.cs" />注入，但这是 MSBuild 层控制，不是语言特性本身
容易被忽略的可读性与维护成本
看似省了几十行 using，但全局导入会让新成员难以判断某个类型来自哪个命名空间，尤其当多个 global using 导入了同名类型（如 List<T> 来自 System.Collections.Generic 和自定义泛型工具类）。
- IDE 跳转和智能提示仍依赖实际导入，但错误定位变模糊
- 重构时，删除某个
global using可能导致数十个文件编译失败，而你根本不知道哪些地方用了它 - 团队协作中，建议把高频、稳定、无歧义的命名空间（如
System系列、Microsoft.Extensions.*）放进global using，避免把业务命名空间或第三方不稳定包放进去
真正麻烦的从来不是怎么写，而是删掉某条 global using 后，编译器不再报错却悄悄用了另一个同名类型——这种隐式覆盖很难被测试覆盖到。
