Lazy 应用于构造开销大且未必访问的场景（如 DbContext、大型缓存），避免用于简单对象或短生命周期对象；线程安全仅保障工厂最多调用一次，不保护其内部逻辑；异常会被缓存并重复抛出；不支持真正异步延迟，应改用 AsyncLazy 或 Func。
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 都重新抛出同一个异常实例（不是新异常），这点容易踩坑。
微软 Outlook 邮箱和日历管理工具（支持世纪互联版 Office 365）。用于查看、发送、搜索邮件，管理日历日程，创建会议，查询忙闲状态。注意：此功能仅支持世纪互联（21Vianet）版 Microsoft 365，使用 login.chinacloudapi.cn。
示例：
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」。
