fluentresults 旨在替代 try/catch 和手动状态码组装，而非仅替换 bool+out；result 表示无值状态，result 才携带返回值并保障泛型推导安全；bind 需严格匹配 func 或 func，异步必须显式声明 task；toactionresult() 默认仅按 issuccess 返回 200/500，需用 metadata 或类型映射区分 400；result.try 默认丢失异常堆栈，须用 causedby 保留；metadata 默认不序列化，需注册 metadatajsonconverter。
FluentResults 不是“返回 bool + out”的替代品，而是要彻底替换 try/catch 和手动状态码组装逻辑——用错姿势，反而让错误路径更难追踪。
Result 和 Result 的区别在哪？
根本不是“有没有返回值”的问题，而是编译期约束和链式调用安全性的分水岭。
-
Result表示纯状态（成功/失败），不带值；Result<t></t>才能携带T类型的合法输出，Bind 后续操作时类型推导才可靠 - 写
Result.Try(() => 123)得到的是Result<int></int>，但写Result.Fail("oops")默认是Result；若你后续想.Bind(x => ...)，x 就会报错：无法从Result推出泛型参数 - 别依赖隐式转换——
Result.Ok(42)和Result.Ok<int>(42)</int>看似一样，但后者在复杂泛型嵌套或 LINQ 场景下更稳定
Bind 链里 async/await 怎么写才不出错？
Bind 方法本身不感知 async，它只接受 Func<t result>></t> 或 Func<t task>>></t> ——漏掉 Task 声明，就会同步执行异步委托，结果永远是 Result<task>></task>。
- ✅ 正确：
.Bind(async user => await GetUserOrdersAsync(user.Id))→ 返回Task<result>></result> - ❌ 错误：
.Bind(user => GetUserOrdersAsync(user.Id))→ 返回Result<task>></task>，后续 .Value 是个未 await 的 Task 对象 - 如果被 Bind 的方法本身返回
ValueTask<result>></result>，必须显式await并包装成Task，否则 Bind 不识别
为什么 ToActionResult() 在控制器里返回 500 而不是 400？
不是 FluentResults 的锅，是 ASP.NET Core 的错误转换策略默认把所有 Result.Errors 当作服务器错误（500），除非你明确分类。
-
FluentResults.Extensions.AspNetCore的ToActionResult()只按IsSuccess切分 200/500，不解析错误类型 - 要区分客户端错误（400）和系统错误（500），得用
WithMetadata("HttpStatusCode", 400)给错误打标，再自定义一个ResultToActionResultTransformer - 或者改用
result.ToActionResult(new Dictionary<type int> { [typeof(ValidationError)] = 400 })</type>，靠错误类型映射状态码
Try 捕获异常后，原异常堆栈丢了吗？
默认丢——Result.Try 内部用 catch (Exception ex) 吞掉异常，只保留 ex.Message 和 ex.GetType().Name。
- 若需完整堆栈，必须传入自定义 handler：
Result.Try(op, ex => new Error(ex.ToString()).CausedBy(ex)) -
CausedBy(ex)会把原始异常存进Error.InnerExceptions，日志中间件可读取并格式化输出 - 注意：
CausedBy不会自动 re-throw，也不会影响 HTTP 状态码，只是补全上下文
最常被跳过的其实是 Metadata 的序列化行为——默认 JSON 输出里 Metadata 是空对象，除非你显式配置 JsonSerializerOptions.Converters.Add(new MetadataJsonConverter())。
