object.prototype.tostring 不可直接修改，但可通过 symbol.tostringtag 安全定制其返回值；该 symbol 被规范认可，影响 tostring.call 结果，适用于普通对象、类实例及内置对象，需注意兼容性与语义准确性。
Object.prototype.toString 本身不可扩展，但它的行为可通过 Symbol.toStringTag 实现高度定制化——这才是真正实用的“扩展性”所在。
为什么直接修改 toString 不可行
该方法是原生函数，[[Enumerable]] 为 false，且被设为不可写（writable: false）、不可配置（configurable: false）。尝试重新赋值或 Object.defineProperty 覆盖会静默失败（严格模式下报错）。
它设计初衷就不是供覆盖使用，而是作为统一类型检测的底层机制。
Symbol.toStringTag：标准且安全的定制方式
ES6 引入的 Symbol.toStringTag 是唯一被规范认可的、影响 Object.prototype.toString.call(x) 返回值的途径。只要对象自身或原型链上有该 symbol 属性，toString 就会读取并用于构造返回字符串。
- 普通对象：
const obj = { [Symbol.toStringTag]: 'MyClass' }; Object.prototype.toString.call(obj) // "[object MyClass]" - 类实例：可在 class 中定义 getter，动态返回标签
- 内置对象如 Date、RegExp 已预置该 symbol，所以显示为
[object Date]而非[object Object]
注意边界与兼容性
该机制不改变对象实际类型，仅影响字符串表示；它对 null/undefined 无效（toString 在它们上调用会抛错）；IE 完全不支持 Symbol，需 polyfill 或降级处理。
若需兼容老环境，可封装一个 fallback 检测函数：先尝试 toString.call，再退回到 constructor.name 或 typeof 判断。
不要滥用：保持语义清晰
自定义 tag 应真实反映对象语义（如 "URL"、"AsyncIterable"），避免随意设为 "Foo" 却无对应契约。调试时它很直观，但逻辑判断不应依赖它——仍应优先用 instanceof、isXXX() 工具函数或 duck typing。
