静态构造函数由CLR保证线程安全，仅执行一次且无需手动加锁；手动lock反而易引发死锁或依赖问题；需线程安全的延迟初始化应使用Lazy等替代方案；静态字段后续读写仍需额外同步。
静态构造函数本身是线程安全的
C# 规范明确要求：每个类型的静态构造函数在整个 AppDomain（或 .NET Core/.NET 5+ 的 AssemblyLoadContext）中**最多执行一次，且由运行时保证线程安全**。CLR 会在首次访问该类型的任何静态成员、或首次创建该类型的实例前，自动触发静态构造函数，并**内部加锁阻塞其他线程**，直到执行完成。
这意味着你不需要、也不应该在 static 构造函数里手动写 lock —— 它不仅多余，还可能引发死锁（比如锁对象尚未初始化，或触发其他类型初始化链）。
为什么在 static 构造函数里用 lock 是危险的
静态构造函数的执行时机由 CLR 控制，且发生在“类型初始化”阶段。此时若手动使用 lock，尤其锁的是外部对象或未完全初始化的静态字段，极易触发不可预测的依赖顺序问题：
-
lock表达式中若引用另一个尚未初始化的类型（如lock (s_someLockObj)，而s_someLockObj是另一个类的静态字段），会强制触发那个类型的静态构造函数，形成隐式依赖链 - 若被锁对象本身在初始化过程中又间接访问当前类型，将导致死锁（CLR 会抛出
TypeInitializationException） - 即使看似安全，
lock也掩盖了本不该存在的并发需求——静态构造函数本就不该承担运行时并发控制职责
需要线程安全的初始化？改用 Lazy 或显式初始化方法
如果你实际要解决的问题是「某个静态资源需延迟初始化且线程安全」，静态构造函数不是最佳选择。更推荐：
- 用
Lazy：它内置线程安全的首次访问初始化逻辑，且支持自定义LazyThreadSafetyMode - 用私有静态字段 + 公共静态只读属性 +
lock（在属性 getter 内）：把同步逻辑放在明确的访问入口，而非类型加载时 - 用
System.Threading.LazyInitializer.EnsureInitialized：适合轻量、无额外分配的场景
private static readonly Lazy_dbConn = new Lazy (() => new DatabaseConnection()); public static DatabaseConnection Db => _dbConn.Value;
唯一需要关心线程安全的地方：静态字段的后续读写
静态构造函数执行完后，所有静态字段都已就绪，但**后续对这些字段的读写操作并不自动线程安全**。例如：
若你在静态构造函数里初始化了一个 static List，之后多个线程调用 s_items.Add() 仍会出错——因为 List 不是线程安全集合。
这时候才需要考虑：
– 改用 ConcurrentBag / ConcurrentDictionary 等线程安全集合
– 在访问处加 lock（锁对象建议是私有静态 readonly object）
– 或用 Interlocked 操作简单值类型
静态构造函数的线程安全性是 CLR 的硬保证，但它的作用范围仅限于“执行一次”这件事本身；一旦执行完毕，剩下的就是你代码里所有静态状态的并发责任——那里才是 lock 和 Concurrent* 真正该出现的地方。
