Workerd项目中FormData对象的toString行为差异分析

在JavaScript生态系统中，Object.prototype.toString方法是判断对象类型的基础手段之一。根据ECMAScript规范，该方法应返回格式为[object Type]的字符串，其中Type由对象的Symbol.toStringTag属性决定。然而在Workerd运行时环境中，开发者发现了与标准不一致的行为表现。

问题现象

当在Workerd环境中执行Object.prototype.toString.call(new FormData())时，预期应返回[object FormData]，但实际上却返回了[object Object]。这种现象同样存在于URL、Blob和URLSearchParams等Web API对象中。

技术背景

现代JavaScript通过Symbol.toStringTag这个知名符号(well-known symbol)来实现自定义类型标签。规范要求内置对象如FormData等都应定义此属性：

class FormData {
  get [Symbol.toStringTag]() { return 'FormData' }
}

当调用Object.prototype.toString时，引擎会优先查找该符号属性作为类型标识。若未定义，则默认返回[object Object]。

解决方案

Workerd团队已通过两种方式解决此兼容性问题：

1. 兼容性标记：使用set_tostring_tag兼容性标志可启用正确的toString行为
2. 日期标记：将兼容日期(compat date)设置为2024-09-26或更新版本

影响范围

该问题会影响依赖类型判断的库函数，例如：

• 对象序列化工具
• 类型检查工具
• 跨环境兼容层

开发者在使用这些Web API对象时应注意运行环境的差异，特别是在Serverless和边缘计算场景下。

最佳实践

对于需要严格类型判断的场景，建议：

1. 明确设置Workerd的兼容性配置
2. 考虑使用instanceof检查作为补充手段
3. 在库开发中增加环境检测逻辑

通过理解这些底层机制，开发者可以更好地编写跨环境稳定的JavaScript代码。