global using 是项目级命名空间管理的显式开关，必须置于 .cs 文件最顶部、任何 namespace 或非 global using 之前；推荐单独建 GlobalUsings.cs 文件，仅含 global using 语句，作用域限本项目。
global using 不是“省几行代码”的小技巧，而是项目级命名空间管理的显式开关——用对了能统一依赖、减少歧义；用错了会拖慢编译、掩盖冲突，甚至让新成员看不懂类型来源。
global using 必须写在哪儿？
它只能出现在 .cs 文件的最顶部，且必须在任何 namespace、class、using（非 global）之前。常见错误是把它塞进 Program.cs 的 namespace 块里，或混在逻辑代码中间，结果编译直接报 CS8773: Feature 'global using' is not available in C# 9.0——哪怕项目是 net8.0，也只是编译器没识别到语境。
- 推荐做法：新建一个独立文件，比如
GlobalUsings.cs，放在项目根目录或Properties/下都行 - 文件内容只能是
global using或global using static语句，不能有空行、注释、变量、方法 - 多个
global using文件可共存，编译器自动合并，无需担心顺序
哪些命名空间适合 global using？
高频、宽泛、项目级通用的才值得放进去。比如 System、System.Collections.Generic、Microsoft.Extensions.DependencyInjection 在 ASP.NET Core 项目里几乎每个文件都用；但 Newtonsoft.Json 只在两个 DTO 文件里解析 JSON，就不该加。
- 适合的：
System、System.Linq、MyApp.Core、Microsoft.AspNetCore.Http - 不适合的：
System.Text.Json.Serialization（太窄）、MyApp.Features.Payment.Models（业务层专用） - 别名也支持：
global using Json = System.Text.Json.JsonSerializer;，但注意别名一旦全局生效，就无法被文件内普通using覆盖
和隐式 using（<implicitusings>enable</implicitusings>）怎么共存？
隐式 using 是 SDK 自动注入的基础命名空间（如 System.IO），而 global using 是你手动写的、可控的补充。两者不冲突，但有优先级关系：文件内普通 using > global using > 隐式 using。
- 如果你开了
<implicitusings>enable</implicitusings>，又写了global using System;，不会报错，但冗余——System已经自动有了 - 想关掉隐式 using？在
.csproj里加<implicitusings>disable</implicitusings> - 想用
.csproj管理 global using？可以：<Using Include="System.Linq" />，效果等同于写global using System.Linq;
为什么改完 GlobalUsings.cs 后 IDE 还不认新类型？
Visual Studio 和 Rider 的语言服务有时不会实时刷新 global using 的语义索引，尤其在快速编辑后。这不是 bug，是缓存行为。
- 最稳的解决方式：执行一次完整重建（
Build → Rebuild Solution），或重启 IDE 的语言服务（VS 中可通过“开发人员命令提示”运行devenv /resetuserdata，Rider 可按Ctrl+Shift+P搜 “Reload project”） - global using 作用域严格限定在当前项目，引用它的类库看不到这些声明——这点常被忽略，导致类库中编译失败却查不到原因
- 如果出现类型歧义（比如两个 global using 都引入了
Logger），编译器不会静默处理，而是直接报错，必须用全限定名或在对应文件里加普通using显式指定
