Deno标准库中assertEquals对Temporal和URL相关API的对比问题分析

问题背景

在Deno标准库的断言模块中，assertEquals函数在处理某些内置对象时存在比较缺陷。具体表现为当比较Temporal API对象（如PlainDate、Instant等）以及URL相关对象（URLSearchParams、URLPattern等）时，即使这些对象的值不相等，assertEquals也不会抛出错误。

问题本质

这个问题的根源在于assertEquals的实现机制。当前版本主要通过检查对象的自有属性(own properties)来进行比较，而Temporal对象和部分URL相关对象的属性都定义在原型链上而非对象自身上。这种设计导致了比较逻辑的失效。

技术细节分析

对于Temporal对象，所有属性都存储在原型上而非实例上。例如比较两个不同日期的PlainDate对象时：

const date1 = Temporal.PlainDate.from('1999-09-09');
const date2 = Temporal.PlainDate.from('1212-12-12');

这两个对象看起来不同，但由于没有自有属性差异，assertEquals会错误地认为它们相等。

类似的问题也出现在URLSearchParams的比较中。在浏览器环境下，由于URLSearchParams的属性也存储在原型上，比较会失败。而在Deno环境中，由于实现差异（Deno为这些对象添加了特殊的Symbol属性），比较能够正常工作，但这种行为不一致可能带来跨环境问题。

解决方案探讨

针对这个问题，可以考虑以下几种解决方案：

1. 特殊处理内置类型：像处理Date对象一样，为Temporal和URL相关对象添加特殊比较逻辑。这种方法简单直接，但需要维护越来越多的特殊case。

2. 原型链属性比较：修改比较逻辑，不仅比较自有属性，还比较原型链上的属性。这种方法更全面，但可能有性能影响。

3. 使用标准序列化方法：对于有toString或valueOf方法的对象，优先使用这些方法进行比较。这种方法更符合对象设计意图。

最佳实践建议

在实际开发中，如果需要比较这些特殊对象，开发者可以：

1. 对于Temporal对象，先转换为字符串或数值再比较
2. 对于URLSearchParams，使用toString()方法比较查询字符串
3. 考虑编写自定义比较函数来处理特定类型的对象

总结

Deno标准库中的assertEquals函数在处理某些内置对象时存在比较缺陷，这主要是由于这些对象的特殊属性存储方式导致的。理解这一问题的本质有助于开发者在实际项目中避免潜在的bug。未来版本的Deno可能会改进这一行为，但在当前版本中开发者需要注意这一限制并采取适当的应对措施。