file关键字必须置于文件顶部、using指令后且类型声明前，不可与传统namespace混用，不支持嵌套，多条file namespace互不合并，vs 2022 17.4+才完整支持。
file关键字怎么写才合法
必须放在文件最顶部，且只能出现在 using 指令之后、任何类型声明之前。一旦用了 file，后面所有类/结构/接口默认属于该命名空间，不再需要大括号包裹。
-
file不能和传统命名空间混用在同一文件里（比如既有namespace X { ... }又有file namespace X;） - 不支持嵌套：不能写
file namespace A.B;—— 虽然语法不报错，但编译器会把它当做一个叫A.B的扁平名称，不是嵌套关系 - 多个
file namespace声明是允许的，但它们各自作用域互不重叠，不会合并
为什么缩进没减少？常见写错姿势
很多人写了 file namespace MyLib;，却发现 IDE 还是提示“类型不在命名空间内”或缩进没变——大概率是因为前面漏了 using 或放错了位置。
- 检查是否在
file namespace前写了任意类型声明（包括partial class、record、甚至注释里的// class A { }） - 确认没有隐藏字符或 BOM 导致编译器误判行首位置
- VS 2022 17.4+ 才完整支持
file作用域；旧版本只识别传统语法，写了也无效
和传统 namespace 的行为差异
核心区别在于作用域边界和符号查找规则。这不是“语法糖”，它改变了编译器解析上下文的方式。
- 传统
namespace X { class A {} }中，A的完整名是X.A；而file namespace X;+class A {}下，A的完整名也是X.A，但中间没有嵌套作用域层级 - 如果文件里同时有
file namespace X;和namespace Y { class B {} }，那么B不在X下，也不自动能访问X内部的 internal 成员（除非同程序集） - XML 文档注释、特性（如
[Obsolete]）的行为完全一致，不用额外适配
什么时候不该用 file namespace
不是所有场景都适合。它简化的是单文件小模块，不是大型分层结构。
- 一个文件定义多个逻辑上无关的类型时，强行塞进同一个
file namespace会让意图模糊 - 团队已有命名空间规范（如按文件夹路径映射），改用
file会破坏一致性 - 生成代码（如 Protobuf、Swagger 客户端）通常依赖传统块式 namespace，手动改成
file容易被下次生成覆盖
C# 的 file 作用域命名空间本身很简单，但它的生效前提是整个文件结构干净、工具链支持到位。最容易被忽略的是编译器版本和前后语句顺序——写对了语法，却卡在环境上。
