随着时间的推移，我们发展了读写逻辑条件的技能，新的语言特性可以为我们提供新的解决方案。但并非所有解决方案都是平等的。让我们快速看一个例子。

设置

假设我们有一个可能存在于多个位置的属性，并且我们希望优先考虑嵌套实例。以下是一些可能的解决方案：

// Option A: Ternaryconst setting = config.user ? config.user.setting : config.setting;// Option B: Optional Chaining and Nullish Coalescingconst setting = config.user?.setting ?? config.setting;// Option C: Destructuring and Nullish Coalescingconst { setting } = config.user ?? config;登录后复制 找出差异

它们在功能上看起来非常相似，但存在细微的差异。根据我们的业务需求或数据设计，其中一些可能会导致错误。

看一下这三个选项，看看您是否能够识别结果会有所不同的不同场景。我们对每个版本做了什么假设？

运营商分析

首先，考虑起作用的特定运算符。

三元 - 使用 truthy 检查来决定使用哪个表达式。可选链接 - 如果对象是nullish，则返回未定义，但如果它只是falsy。，则不返回未定义nullish coalescing - 如果第一个表达式为 nullish.，则使用第二个表达式 不为空

三元运算符在这里脱颖而出。对于大多数实际目的来说，当我们谈论对象时，它的行为方式是相同的。差异归结为当事情不起作用时我们期望的值是什么。

未分配的对象通常是未定义或为空。但是，如果我们的项目使用 false 或“还不是对象！”，则使用三元组做出的假设可能会产生不需要的结果。不过，这是一个不太可能出现的极端情况。

了解意图

如果我们忽略不太可能的“非对象”场景，选项 a 和 c 基本上是相同的。

如果config.user存在，则获取config.user.setting。否则，获取config.setting。

选项 b 做了一些不同的事情。

如果 config.user.setting 存在，请使用它。否则，获取config.setting。

差异很小，但直接关系到需求或技术设计决策：如果缺少用户，还是仅在缺少 user.setting 时，我们会回退到 config.setting？

两者都是有效的可能性，但如果我们做出错误的假设，当我们期望默认值时，我们可能会一无所获，或者当我们期望什么都没有时，我们最终可能会得到一些东西。

结论

除了问目标是什么之外，这里没有“正确答案”。我们需要更多背景信息。对于项目成员来说，要求澄清这些问题可能显得迂腐，但如果我们与期望不一致，这些小细节可能会产生非常微妙的错误。

对于这个项目或整个公司来说可能有一个正确的答案。我们甚至可能在一个项目中使用多个选项；一是聚焦价值；另一个重点是结构。也许没有人考虑过这些差异。也许团队认为他们是一致的，但实际上并非如此。

不问你就不会知道。

以上就是条件逻辑快速摘要：要求和边缘情况的详细内容！