Lazy 什么时候该用，什么时候不该用
延迟初始化只在值构造开销大、且不保证一定会被访问时才有意义。比如一个
DbContext实例、大型缓存对象、或需要 IO 初始化的配置类。如果只是
new List<string>()</string>或简单字符串，用
Lazy<t></t>反而增加间接层和内存占用，得不偿失。
常见误用场景：
• 把所有字段都套上
Lazy<t></t>当“性能优化”
• 在单线程短生命周期对象里滥用（如 ASP.NET Core 的 transient service）
• 用它替代构造函数参数注入——这混淆了职责
默认构造 vs 自定义工厂函数：线程安全差异在哪
Lazy<t></t>的线程安全性取决于构造方式：
•
new Lazy<t>()</t>（无参）：使用默认构造函数，线程安全，首次
Value访问时最多执行一次构造
•
new Lazy<t>(func)</t>（带工厂）：同样线程安全，但要注意
func内部是否含非线程安全操作（比如静态字典写入）
•
new Lazy<t>(func, isThreadSafe: false)</t>：显式关闭同步，仅适用于已知单线程上下文，否则可能重复执行工厂函数
关键点：
• 线程安全 ≠ 工厂函数内部安全；
Lazy<t></t>保证的是“工厂最多调用一次”，不保护你写的
func里的逻辑
• 如果工厂里要写共享状态，仍需自己加锁或用
ConcurrentDictionary等
Value 属性触发时机和异常传播规则
Value第一次被读取时才执行初始化，后续读取直接返回缓存值。但如果初始化过程抛出异常，
Lazy<t></t>会缓存该异常，之后每次访问
Value都重新抛出同一个异常实例（不是新异常），这点容易踩坑。
示例：
var lazy = new Lazy<string>(() => { throw new InvalidOperationException("Boom"); });
try
{
var s = lazy.Value; // 第一次：抛 InvalidOperationException
}
catch (InvalidOperationException)
{
// 处理
}
try
{
var s2 = lazy.Value; // 第二次：仍抛同一个 InvalidOperationException 实例
}
catch (InvalidOperationException)
{
// 这里也会进
}
规避方法：
• 初始化前用
IsValueCreated判断是否已尝试创建（但无法区分是成功还是失败）
• 更稳妥的是封装一层，捕获并重置
Lazy<t></t>（需重建实例）
• 或改用手动双检锁 +
volatile字段，完全掌控异常行为
与 async/await 不兼容：为什么不能 Lazy>
Lazy<t></t>是同步机制，
T必须是具体类型。写成
Lazy<task>></task>看似可行，但实际是“延迟创建 Task 对象”，而非“延迟执行异步操作”——Task 构造极快，起不到延迟效果，还掩盖了真正的 await 需求。
正确做法：
• 用
AsyncLazy<t></t>（需自行实现或引用
Microsoft.Bcl.AsyncInterfaces中的类型）
• 或封装为
Func<task>></task>+ 手动缓存
Task<t></t>实例（注意 Task 完成后不可重用）
• ASP.NET Core 中更推荐用
IServiceScopeFactory延迟解析服务，而非在字段级做异步延迟
一句话记住：
Lazy<t></t>解决的是「要不要 new」，不是「要不要 await」。
