file修饰符是独立访问修饰符，必须单独置于类型关键字前，不可与public/internal/private等混用，否则报cs0106或cs8904；其作用是在编译期彻底隔离类型，使跨文件引用时因类型根本不存在而报cs0246。
file 修饰符不是“更私有的 internal”，而是完全脱离程序集作用域模型的编译期隔离机制——它让类型在语义分析阶段就不出现在其他文件的符号表里，连“不可访问”都算不上，是“根本不存在”。
为什么 file class 会报 CS0106 或 CS8904？
这两个错误本质是语法冲突，不是可见性问题。
-
file是独立访问修饰符，不能和public、internal、private、protected任意组合；写public file class X直接语法不合法 -
file必须紧贴在类型关键字前，且是唯一访问修饰符；static file class X合法，但file static class X在部分旧 SDK 下可能触发 CS8904（顺序敏感） - 如果文件顶部有
#nullable enable或using指令，确保file声明不在它们之前——C# 编译器要求类型声明必须在所有指令之后、实际代码之前
file 类型跨文件引用时为何报 CS0246 而非 CS0122？
CS0246 是“找不到类型”，CS0122 是“不可访问”。这说明 file 不是访问控制，而是作用域剪裁。
- 编译器在解析另一文件时，压根不会把
file类型导入当前编译单元的命名空间或程序集符号表 - 即使两个文件同属一个
namespace、同一项目、甚至物理上相邻，IntelliSense 也不会补全该类型名 -
Assembly.GetTypes()返回结果里绝对不含任何file类型——它们不生成公开元数据，反射也看不见 - 别指望用
dynamic绕过：运行时仍会抛RuntimeBinderException，因为类型根本没被 JIT 加载进类型系统
如何安全地从 public API 间接暴露 file 类型？
可以“藏”，但不能“露”。关键在于签名中不出现具体 file 类型名。
- 返回
object、interface或基类（需该基类本身是public或internal） - 参数类型不能是
file类型，否则调用方无法构造实参；可改用工厂方法 +Func<t></t>或Action<t></t> - 属性类型同理：避免
public FileScopedConfig Config { get; }，应改为public IConfig Config => _config; - 扩展方法必须与
file类型定义在同一文件——public static void DoX(this FileScopedHelper h)若写在别处，编译直接失败
file namespace 和 file 类型混用要注意什么？
两者无关，但共存时容易误判作用域边界。
-
file namespace X;只影响后续类型声明的隐式命名空间归属，不改变file class的作用域——后者仍只限本文件 - 若文件同时有
file namespace X;和namespace Y { class B {} }，则B属于Y，和X完全无关，也不能自动访问X下的internal成员 - 最易踩坑的是生成代码：Protobuf/NSwag 等工具默认生成块式
namespace，手动改成file namespace后，若模板又重生成，会覆盖并破坏file类型的上下文 - .NET 6+ SDK 默认支持，但 CI 环境若用旧版
Microsoft.NET.Sdk（如 .NET 5 SDK），可能静默忽略file关键字，导致意外泄露——务必检查构建日志是否含CSC : warning CS8903
真正难处理的不是语法，而是团队对“类型生命周期”的认知惯性：file 类型一旦写进文件，就等于签了编译期封印——它既不能被继承（除非派生也在同文件），也不能被序列化框架（如 System.Text.Json）直接处理（因无公开类型信息），更不能出现在任何跨文件契约中。用之前先想清楚：这个类型，是不是真的永远不需要走出这扇门。
